[Flac-dev] ERROR: mismatch in decoded data, verify FAILED!

Matt Zimmerman
Fri, 10 Sep 2004 16:45:27 -0000

On Sun, Jun 24, 2001 at 02:30:56PM -0700, Josh Coalson wrote:

> 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:

(gdb) bt
#0  0x400ba565 in memset () from /lib/libc.so.6
#1  0x805f782 in bitbuffer_resize_ (bb=0x4085c800, new_capacity=134479872)
    at bitbuffer.c:62
#2  0x805f8ec in bitbuffer_grow_ (bb=0x4085c800, min_bytes_to_add=33554433)
    at bitbuffer.c:86
#3  0x805f976 in bitbuffer_ensure_size_ (bb=0x4085c800, bits_to_add=268435453)
    at bitbuffer.c:94
#4  0x8060226 in FLAC__bitbuffer_write_zeroes (bb=0x4085c800, bits=268435453)
    at bitbuffer.c:254
#5  0x8061153 in FLAC__bitbuffer_write_rice_signed (bb=0x4085c800,
    val=-2147483630, parameter=4) at bitbuffer.c:658
#6  0x8056603 in subframe_add_residual_partitioned_rice_ (bb=0x4085c800,
    residual=0x8361200, residual_samples=4580, predictor_order=28,
    rice_parameters=0x407dc520, raw_bits=0x407fc520, partition_order=0)
    at encoder_framing.c:366
#7  0x80563eb in FLAC__subframe_add_lpc (subframe=0x407dc518,
    residual_samples=4580, subframe_bps=17, wasted_bits=0, bb=0x4085c800)
    at encoder_framing.c:310
#8  0x80544c8 in encoder_add_subframe_ (encoder=0x8314758,
    frame_header=0xbfffe5ac, subframe_bps=17, subframe=0x407dc514,
    frame=0x4085c800) at encoder.c:1030
#9  0x8053b48 in encoder_process_subframes_ (encoder=0x8314758,
    is_last_frame=0) at encoder.c:863
#10 0x8052f50 in encoder_process_frame_ (encoder=0x8314758, is_last_frame=0)
    at encoder.c:632
#11 0x8052a46 in FLAC__encoder_process (encoder=0x8314758, buf=0x83080e0,
    samples=2048) at encoder.c:536
#12 0x804bb31 in flac__encode_wav (infile=0x8314478,
    infilename=0xbffffa09 "/tmp/test-9.wav",
    outfilename=0xbfffe7d8 "/tmp/test-9.flac", verbose=1, skip=0,
verify=1,
    lax=0, do_mid_side=1, loose_mid_side=0, do_exhaustive_model_search=1,
    do_qlp_coeff_prec_search=1, min_residual_partition_order=0,
    max_residual_partition_order=16, rice_parameter_search_dist=0,
    max_lpc_order=32, blocksize=4608, qlp_coeff_precision=0, padding=0,
    requested_seek_points=0x8308120 "100x",
num_requested_seek_points=-1)
    at encode.c:292
#13 0x8050aa4 in encode_file (infilename=0xbffffa09 "/tmp/test-9.wav",
    forced_outfilename=0xbfffe7d8 "/tmp/test-9.flac") at main.c:581
#14 0x804fd34 in main (argc=4, argv=0xbffff884) at main.c:377
#15 0x4006038b in __libc_start_main () from /lib/libc.so.6

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.

--
 - mdz