[Flac] Re: Welcome to the "Flac" mailing list

[Brian Willoughby]

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" <alex.brims at gmail.com> 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.