#349 .wav encode produces .flac that decodes != .wav

Josh Coalson
Leigh Clayton

Using flac 1.2.1 (built myself) under Linux (Fedora Core 6), the .wav file I am working with does not generate
the correct decoded file. --verify correctly notices this. The two wav files are different only in 4 bytes; here is the
output of "cmp" for them:
5 4 64
6 310 321
41 340 20
42 307 321
My encoding options were the following:
{path to flac} --best --verify --no-utf8-convert --keep-foreign-metadata -T "TITLE=$iptt" -T "ARTIST=$ipta" -T "ALBUM=$iptl" \ -T "DATE=$ipty" -T "DESCRIPTION=$iptc" -o "10_track10_flac_retry.flac" TRK10.wav

NOTE PLEASE that I tried this *without* the keep-foreign-metadata and got a slightly different flac file, but with the same problem.

Here's the output:

flac 1.2.1, Copyright (C) 2000,2001,2002,2003,2004,2005,2006,2007 Josh Coalson
flac comes with ABSOLUTELY NO WARRANTY. This is free software, and you are
welcome to redistribute it under certain conditions. Type `flac' for details.

TRK10.wav: 100% complete, ratio=0.588TRK10.wav: WARNING: unexpected EOF; expected 17806404 samples, got 17805312 samples
TRK10.wav: 100% complete, ratio=0.586

Since the .wav file is 70 megabytes, I haven't tried to attach it, but I will upload it somewhere if anyone wants to look into
this problem. (For completeness I should mention that I *do* use LD_LIBRARY_PATH in my script, and have rebuilt a few libs on my
system at one point or another, but I have only seen this problem with this one file out of several dozen I've played with so far.)


  • Leigh Clayton
    Leigh Clayton

    I did a bit more digging (seemed only fair), and I see that the two fields that are being decoded differently are the file/data length fields "ChunkSize" and "Subchunk2Size". Also, I see that the original file has numbers in these fields that are larger than the actual file size (by a small amount). I infer that the output from the decode is in fact strictly more correct than the input, and I guess that the error message (unexpected EOF) received during the encode was probably the only action I could have hoped for.

    I still have a feeling I might have preferred flac to tuck my incorrect header information away somewhere, so that what it considered to be a successful encode could be completely reversed. Either the compression *can* exactly reproduce the WAV file or it can't, and I *did* tell it to keep any foreign metadata, after all. But at this point I think my ire should more properly be aimed at "bchunk" for creating a bad .wav file.

    I am leaving this open in the hope that someone might at least think about this (although as I re-read it it sounds pretty flaky to even me). Please, whoever does read it feel free to close it with my blessing. And thanks for listening (and for the software).

  • Josh Coalson
    Josh Coalson

    I see... but the intent of flac is not to silently preserve invalid wav files, at that point someone could later come back with a decoded file that was bad, say it was flac that caused, and there would be no way to tell.

    at some point the program has to take a stand about what input to accept.

  • Josh Coalson
    Josh Coalson

    • assigned_to: nobody --> jcoalson
    • status: open --> closed-invalid