There is no such thing as "harmless extra bytes" in a .wav file.
RIFF/WAVE is defined as a series of chunks, and there is no header at
the beginning which indicates how many chunks to expect. A program
reading a .wav will see these 2 extra bytes as a "Chunk Type" and
that's why the confusion results. The program has no way of knowing
that it should stop before the "extra" data.
What people generally refer to in the literature as a .wav "header"
is really not a header at all. It is just another chunk, one which
can legally occur at more than one place in a WAV file, and it does
not even have a count of chunks. There are a great number of
programmers out there - even at prominent audio companies - who do
not understand the finer points of file format design, and the
situation is not helped by the poor availability of documentation on
RIFF/WAVE. As a result, there are too many programs out there which
create bad WAV files. The solution is to fix the bad programs and
not bloat the good programs.
If you really want to dig down deep into the details of RIFF/WAVE,
there is actually a meta-chunk at the very beginning of the file
which marks it as a RIFF file of subtype "WAVE" and this chunk length
usually includes the rest of the file chunks. All remaining chunks
are "inside" this meta-chunk. However, whether the extra two bytes
are within this first meta-chunk, or beyond the end of the meta-
chunk, it is still perfectly legal in each case for a chunk to
follow. In other words, the meta-chunk must be precisely filled with
whole chunks, not partials, and the meta-chunk must be followed by
whole chunks until the end of the file.
As Josh points out, adding extra code to FLAC to recover gracefully
when a chunk starts with bad data would just add needlessly to the
complexity of the code, and there would probably be a never-ending
list of ways in which bad WAV files could go wrong. It's quite
enough that FLAC supports the entire legal range of RIFF/WAVE files,
there's no need to take on the larger task of also support illegal
files. If you get a bad WAV file, use another program to fix it
first, then FLAC will be ready to support it. Actually, FLAC does
recover gracefully from these errors, it simply does not accept the
WAV as valid, because that would be a very dangerous assumption to
make in the face of an illegally-formatted file.
Brian Willoughby
Sound Consulting
On Nov 1, 2007, at 15:38, Martin Leese wrote:
"Alex Brims" <[EMAIL PROTECTED]> wrote:
Ok, we actually worked this out - there were 2 extra bytes doing
nothing at
the end of the files. Opening the file in SoundForge and saving it
(without
changing it) took off the extra bytes and allowed the file to
convert to
FLAC.
Thanks to everyone who emailed me suggestions.
Is there a decent program for linux that could automatically take
these
bytes off, without running the risk of removing good data? Or is
there a
way to get the flac converter to ignore this error and create the
file? I'm
running flac 1.2.1 on Red Hat Enterprise Linux ES release 4.
I am butting in here, but if these extra bytes
are harmless then shouldn't this be a warning,
not an error?
I had a similar problem years ago with acoustic
data. The data files were mounted from a
computer running VMS using NFS. When
viewed on a UNIX machine, the files had extra
data after the (UNIX) logical end-of-file.
_______________________________________________
Flac mailing list
[email protected]
http://lists.xiph.org/mailman/listinfo/flac
