Janne Hyvärinen wrote:
> The previous patch was bugged. The output file wasn't truncated to
> correct size and was a bit off from rounding the WAVE/AIFF header to
> smallest sector size. And RAW output didn't benefit from the change. And
> the existing functions didn't need changes as outputfil
The previous patch was bugged. The output file wasn't truncated to
correct size and was a bit off from rounding the WAVE/AIFF header to
smallest sector size. And RAW output didn't benefit from the change. And
the existing functions didn't need changes as outputfilename was already
known. Attach
On 27.9.2014 8:54, Erik de Castro Lopo wrote:
> Janne Hyvärinen wrote:
>
>> Removed buffer size increase. Only tells the filesize to Windows now.
> Would it not be possible to do the same when encoding? Of course we
> don't know the exact size of the output file, but guessing at 70% of
> 80% of the
Janne Hyvärinen wrote:
> Removed buffer size increase. Only tells the filesize to Windows now.
Would it not be possible to do the same when encoding? Of course we
don't know the exact size of the output file, but guessing at 70% of
80% of the input file size would be correct in most cases? Are th
Janne Hyvärinen wrote:
> I find these Linux user comments about not suffering from fragmentation
> curious. I just tested decoding a flac in Fedora 20 and filefrag command
> reports the decoded file is in 8 extents. Different name but same thing.
Oh, Linux may well fragment filesystems, but the
Removed buffer size increase. Only tells the filesize to Windows now.
On 26.9.2014 14:08, Erik de Castro Lopo wrote:
Martijn van Beurden wrote:
Can you please wrap the setvbuf in _WIN32 IFDEFs too? Currently
memory usage of FLAC decoding is about 1MB, so this patch is
increasing memory usage t
I find these Linux user comments about not suffering from fragmentation
curious. I just tested decoding a flac in Fedora 20 and filefrag command
reports the decoded file is in 8 extents. Different name but same thing.
On 26.9.2014 14:08, Erik de Castro Lopo wrote:
> Martijn van Beurden wrote:
>
Martijn van Beurden wrote:
> Can you please wrap the setvbuf in _WIN32 IFDEFs too? Currently
> memory usage of FLAC decoding is about 1MB, so this patch is
> increasing memory usage tenfold, also for platforms that do not
> need this. It is a non-problem on my system anyway.
+1
Will apply pat
Can you please wrap the setvbuf in _WIN32 IFDEFs too? Currently
memory usage of FLAC decoding is about 1MB, so this patch is
increasing memory usage tenfold, also for platforms that do not
need this. It is a non-problem on my system anyway.
Op 26-09-14 om 10:36 schreef Janne Hyvärinen:
I made
I made some changes to the previous patch. I don't know why I originally
didn't put the output buffering to piped output too but that is now
moved to cover both file and pipe output.
Additionally this patch informs the Windows filesystem in advance about
the decoded size to eliminate NTFS fragme
Decoding flac files is also prone to producing fragmented files. NTFS
has the ability to completely avoid fragmentation if it is told the file
size before hand, but that would require using special Windows-only
functions. Increasing the write buffer from the default 512 bytes to 10
MB already r
11 matches
Mail list logo