[Flac] Re: Odd number of samples in a stereo wave file

[Brian Willoughby]

This topic is possibly more appropriate on the flac-dev list, since  
most flac users are not going to be interested in the details of WAVE  
format errors.  Assuming it's ok to keep talking about it here...

Ben, you've stumbled upon one of the common shortcomings of  
specifications.  There are often assumptions which are not spelled  
out, or there are pieces which are vague.  In some cases, the various  
resulting symptoms may appear the same to the end user, but they  
actually have quite different causes when examined in detail.

There are a couple of issues which fall under the generic category of  
"odd" sizes in RIFF/WAVE files.  The first is one that I tried to  
describe in detail, but turns out not to be an issue with the file in  
question, although it is a common error.  The second issue could  
probably be described more clearly.

1) At the most basic level of the specification, all RIFF/WAVE chunks  
must be an even number of bytes.  At the time RIFF was designed, there  
was some efficiency to accessing files on word boundaries instead of  
byte boundaries - or at least they copied this requirement from AIFF.   
This has nothing to do with the size of the sample, but there is an  
interaction.  With 16-bit files (e.g. CD) and any number of channels,  
there will never be a chance of an odd number of bytes.  Also, with  
stereo files, no matter how many bytes per sample, there's no chance  
of an odd number of bytes.  This leaves mono 8-bit and mono 24-bit  
files as potential problems, if the programmer doesn't understand the  
specification (which clearly states the requirement that odd-byte- 
sized chunks must be padded, even if they're the last chunk in the  
file).

2) Another assumption common to all sampled files is the "frame."  For  
any multichannel file, there must be one sample per channel to form a  
complete frame.  It really doesn't make sense to create a file, call  
it stereo, and then leave one channel missing on the last frame.  I'm  
not sure whether the specifications spell out what should happen when  
a frame is incomplete, but there is a strong implication that frames  
should always be complete.  I can't even imagine what kind of  
programmer would write code which creates partial frames.

It would actually be punitive to expect the flac code to expect and  
adapt to nonsensical WAVE files.

If the problem is common, then report the bug to the makers of the  
programs which produce the bad WAVE files, tell your customers to  
switch to compliant programs, and/or write your own software which  
processes WAVE files looking for these kinds of errors and repairs  
them.  If you receive the files via uploads, it would probably be  
possible to have this step run automatically.

Brian Willoughby
Sound Consulting


On Nov 15, 2007, at 10:37 AM, <ben at yarwood.com> <ben at yarwood.com> wrote:

I'm new to the mailing list but am interested in picking up a thread  
from earlier in the month but which I thought had become confusing so  
I am starting again.  I should admit from the beginning that I am a  
colleague of Alex Brims who started the original thread.

The thread in question related to a wav file with an extra two bytes  
at the end causing a partial sample error in the reference flac  
encoder.  There seemed to be confusion over what was actually wrong  
with the file but as Brian Willoughby deduced correctly, the file had  
an odd number of samples in the data chunk and as it was a stereo  
file, this was incorrect.

What I am asking is does this make the file invalid as far as the RIFF 
\WAVE specification goes? The file had a valid "RIFF", "fmt " and  
"data" chunks as far as chunk Id's and lengths where concerned and the  
overall file length is correct. The only issue is that the "data"  
chunk started and ended with a sample from the same channel.  I have  
read through some of the documentation provided at http://www.ambisonia.com/Members/mleese/file-formats/ 
  and especially the McGill university WAVE specification and the  
Microsoft/IBM documentation and can't find anywhere that it says that  
there needs to be an even number of samples, just that they need to be  
interleaved.  I may have missed something along the way in which case  
the simple answer to the original question is "yes the file is  
invalid." That's fine with me.

The main reason to bring this up is to point out that these files  
exist and in our experience are quite common, of the hundreds of new  
wav files we receive a day around 1% seem to have this problem.   We  
receive them from many different suppliers and they seem to becoming  
more common, which is a bit of a pain and probably down to an update  
to a particular piece of software.  Fixing them is also not  
particularly complicated, either add a sample or remove the last one  
and update the relevant chunk information.  On the other hand it seems  
a little punitive to error on a file in this situation.

Anyway your thoughts or opinions would be appreciated.  If I have  
totally misunderstood something in putting this mail together then I  
apologize in advance.

Ben