search for: wootang

...line. Can you supply the output of flac's analyse > function (option -a on the command line) to give us some more > information on what the resulting file looks like? Certainly -- I've uploaded the analysis files for both the -6 and -7 encodes, in case you wanted to compare: http://wootangent.net/~lsd/blah/6.ana http://wootangent.net/~lsd/blah/7.ana The encode seems to proceed normally until 59% of the way through the file, but then it takes a couple of minutes to proceed through to 61% of the way through -- it's during this period that the file inflates up to 9GB in size. Th...

On 16/07/13 8:10 PM, Erik de Castro Lopo wrote: > Leigh Dyer wrote: > >> Certainly -- I've uploaded the analysis files for both the -6 and -7 >> encodes, in case you wanted to compare: >> >> http://wootangent.net/~lsd/blah/6.ana >> http://wootangent.net/~lsd/blah/7.ana >> >> The encode seems to proceed normally until 59% of the way through the >> file, but then it takes a couple of minutes to proceed through to 61% of >> the way through -- it's during this period tha...

Erik de Castro Lopo wrote: > > http://wootangent.net/~lsd/blah/snippet6.wav > > Great, thanks! Confirmed the problem here. Will look at it ASAP. Same problem with flac 1.2.1. Interesting! Erik -- ---------------------------------------------------------------------- Erik de Castro Lopo http://www.mega-nerd.com/

Hi, On a particular input file, FLAC (testing with current git) greatly inflates its output if I encode at level 7, which enables --exhaustive-model-search. The source is a 24-bit WAV file of about 60MB; flac -6 encodes this to a 43MB FLAC file, but flac -7 produces a 9.1GB (!) file. The enormous file does seem to be perfectly valid, FWIW -- it (eventually) decodes to a WAV that's

...> The first time I tried, the resulting file encoded just fine, but after > trying a few more times, cutting at slightly different points, I was > able to get a snippet of that section that exhibits the problem. This is > short enough that I think I can link to it here: > > http://wootangent.net/~lsd/blah/snippet6.wav > > This results in a 4.1GB file when encoded with -7. Have you notices that there are a few damaged areas in this file? For example at 4.854 seconds, 6.700s, 6.828s, 7.618s. It looks to me like damage accumulated during some process after mastering, somewhere...

Erik de Castro Lopo wrote: >> It slightly improves the performance with standard encoding levels and >> 16-bit files as the 17-bit side channel can still be processed with the >> 32-bit accumulator and correctly selects the 64-bit accumulator with >> very large 16-bit partitions. >> >> This is related to commits 6f7ec60c and 187e596e. > > Sorry I