Menu
▾
▴
#190 incorrect wav header size confuses flac
Flac was recently observed to archive a 1.9 GB WAV file
as a 0 byte WAV file. A warning was issued when the
archive was created but the return code from flac was 0
and the archive verified okay with -V (during creation)
and with -t.
WAV file header information can sometimes be incomplete
if audio recording devices or programs terminate
abnormally.
The problem file in question was created with ecasound.
The sequence of events can be basically reproduced by
running ecasound in a wav file copy mode :
ecasound -i any.wav -o badheader.wav
sleep 1
killall -9 ecasound
An example problem wav file is attached.
Thank you!
wav file with invalid header from ecasound
Logged In: YES
user_id=78173
I see the problem here, it's that both the RIFF size and data subchunk
size are zero. flac ignores the RIFF size and tries to make the best it
can of the data subschunk size. as far as it can tell there is a 0 size
data chunk (legal) followed by some other stuff it can't recognize.
but there is a bug in the part that skips the 'unknown' chunk (which in
this case is actually audio data) which should have caused the
encoding to end with an error and return nonzero. I'll fix that.
maybe there should also be a warning/error for zero-size data
sub-chunks.
Josh
Logged In: YES
user_id=78173
fixed in CVS
Logged In: YES
user_id=14161
Originator: YES
Just tested this again on 1.1.4 and the bug is still present, apparently exactly as originally reported. I appreciate that it was possibly fixed in cvs but I'm wondering why it didn't make it into 1.1.4?
Flac 1.1.4 still omits any "extra" audio data gives me a return code of 0, even if most of the audio was not archived.
It is a very serious bug for me. I record live audio and have terabytes of masters. This bug means it is very risky to use flac for anything involving original audio or backups of original audio. Ultimately, I've learned my lesson - the space savings isn't worth the risk (even once the bug gets fixed).
I'd like to see this fixed to reduce the chance of others getting burned and also so I don't have to keep explaining it to folks who may be tempted to archive masters in flac.
tested again in flac 1.2.1:
$ flac problem.wav
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.
problem.wav: WARNING: legacy WAVE file has format type 1 but bits-per-sample=24
problem.wav: ERROR: 'data' subchunk has size of 0
$ flac --ignore-chunk-sizes problem.wav
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.
INFO: Make sure you know what you're doing when using --ignore-chunk-sizes.
Improper use can cause flac to encode non-audio data as audio.
problem.wav: WARNING: legacy WAVE file has format type 1 but bits-per-sample=24
(No runtime statistics possible; please wait for encoding to finish...)
problem.wav: ERROR: got partial sample
the bug here is in ecasound. firstly it doesn't go back and clean up the wav headers with the proper length, but leaves 0 length in the chunks. ok, many programs make invalid wave files this way so I added the --ignore-chunk-sizes option.
but it's even worse, it doesn't even align the output buffer to a sample frame. this is so ambiguous that it's impossible for flac to tell if the file is unaligned or corrupt, so it errors out even with --ignore-chunk-sizes.
this is what I would expect an archiver to do with such files.
p.s. maybe it's not really a bug with ecasound, I see you used sigkill instead of another signal that it might have been able to catch (like sigint) and recover from.