Josh Coalson
2004-Sep-10 16:45 UTC
[Flac-dev] ERROR: mismatch in decoded data, verify FAILED!
> > There have been reports of -9 using huge amounts of memory. -9 is > > really > > theoretical, but people always seem to want to try the max setting. > > Anyway, > > that's not an excuse but figuring out why -9 is using so much > > memory is lower > > on my list than other stuff. -8 should get within 0.01% of -9 and > > is pretty > > reliable. > > I am able to reliably reproduce the -9 memory problem with one of my > WAV files. > I split it in two repeatedly, doing a binary search to find the > smallest chunk > that would trigger the problem, and I got it down to 28224 samples > (this is a > 44.1/16bit/stereo file, so about 0.5 seconds). I have put the file > up at > <http://people.debian.org/~mdz/flac-test-case-1.wav>. Here is a gdb > backtrace > at the point where it is allocating gobs of memory:I think I see the problem just from the trace but I will grab the file and check it out.> Also, Kai has been kind enough to send me a copy of his file which > has a > problem only on -8, which I'll be looking into soon.Matt, if you whittle this file down can you make it available also? One more thing I forgot to mention about debugging. The first point of suspicion is the assembly in the decoder. That you can try with 'configure --disable-asm-optimizations' The second is arithmetic overflow in the linear predictor. You can test that by 'configure --enable-debug' which does overflow checking. Josh __________________________________________________ Do You Yahoo!? Get personalized email addresses from Yahoo! Mail http://personal.mail.yahoo.com/
Josh Coalson
2004-Sep-10 16:45 UTC
[Flac-dev] ERROR: mismatch in decoded data, verify FAILED!
> > > Also, Kai has been kind enough to send me a copy of his file > > > which > > > has a > > > problem only on -8, which I'll be looking into soon. > > > > Matt, if you whittle this file down can you make it > > available also? > > Kai indicated that even if he only trimmed a small amount off of each > end of > the file, the problem did not happen. I'll give it a shot, though.Yeah, he mentioned he got OK results even trimming off just the first second. In this case 44100 samples is not an integral multiple of the blocksize (4608 at -8) so the starting sample for the frame near the 'bad spot' would change. This could affect the encoding enough to not trigger the bug. Josh __________________________________________________ Do You Yahoo!? Get personalized email addresses from Yahoo! Mail http://personal.mail.yahoo.com/
Matt Zimmerman
2004-Sep-10 16:45 UTC
[Flac-dev] ERROR: mismatch in decoded data, verify FAILED!
On Mon, Jun 25, 2001 at 10:54:09AM -0700, Josh Coalson wrote:> > Also, Kai has been kind enough to send me a copy of his file which > > has a > > problem only on -8, which I'll be looking into soon. > > Matt, if you whittle this file down can you make it > available also?Kai indicated that even if he only trimmed a small amount off of each end of the file, the problem did not happen. I'll give it a shot, though.> One more thing I forgot to mention about debugging. The first point of > suspicion is the assembly in the decoder. That you can try with 'configure > --disable-asm-optimizations' The second is arithmetic overflow in the linear > predictor. You can test that by 'configure --enable-debug' which does > overflow checking.I did most of my testing with a normal flac binary, then after I had reduced the sample as much as possible, I ran it through one compiled with --enable-debug, running under gdb, to generate the trace. So in that case, at least, the problem occurred both with and without the extra checks. -- - mdz