[vorbis-dev] oggenc broken for some types of WAV files

[Chris Wolf]

>Your patch is incorrect (will cause crashes if used). 

Well, mine doesn't crash regardless of whether the data input is an old
WAV, or a new WAV.  Can you send me a sample WAV where 
this is crashing for you?  I attached the full "audio.c", just
in case.  BTW, I have version 1.0beta4.  My environment is
MSDEV on W2K, what is yours?  

To quote from the Microsoft spec:

>  cbSize 
>Size, in bytes, of extra format information appended to the end of the
>WAVEFORMATEX structure. This information can be used by non-PCM formats to
>store extra attributes for the wFormatTag. If no extra information is
>required by the wFormatTag, this member must be set to zero. Note that for
>WAVE_FORMAT_PCM formats (and only WAVE_FORMAT_PCM formats), this member is
>ignored. 
>

My patch ignores this structure member (cbSize) becuase the data I have has a wFormatTag value
of WAVE_FORMAT_PCM, which is a defined constant "1".  (See attached mmreg.h)

Microsoft superceeded the original WAVEFORMAT structure (16 bytes) with WAVEFORMATEX
which adds the extra two bytes "cbSize".  
See the attached spec pages, or go to: 
http://msdn.microsoft.com/library/default.asp?url=/library/en-us/multimed/hh/multimed/mmstr_625u.asp
http://msdn.microsoft.com/library/default.asp?url=/library/en-us/multimed/hh/multimed/mmstr_625u.asp

The bottom line is that there will be WAV files with 16 byte format tags, and 18 byte format tags, possibly
with abitrarily long numbers of addtional bytes following the format tag.

Even if the WAV file in question was not exactly conforming to the spec, I believe in a design
philosophy of software being able to tolerate, within reason, input which is not 
exactly to-spec, *especially* if your competition's software does.  (The WAV file in question works
with Winamp, Microsoft media player, and serveral MP3 encoders.)

For example, most HTML documents are not strictly conforming to spec, but most browsers will
display the content anyway.  

>There's already a
>special case for allowing the "fmt " chunk to be of length 18 - this is
>incorrect according to every wav spec I've been able to find, but is 
>common. 

It's not incorrect, see above.

>However, allowing arbitrarily long fmt chunks is definately not
>a good idea, 
>so I won't be changing this behaviour unless you can show
>me an official wav spec that says this is allowed. 

It is allowed, the official spec is attached.

>
>The application that is creating these files is presumably buggy.
>
No.  It conforms to the spec, why presume it's someone else?

        -Chris


<HR NOSHADE>
<UL>
<LI>application/x-zip-compressed attachment: wavspec.zip
</UL>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: wavspec.zip
Type: application/octet-stream
Size: 35690 bytes
Desc: not available
Url : http://lists.xiph.org/pipermail/vorbis-dev/attachments/20010728/f071c3c3/wavspec.obj
-------------- next part --------------
A non-text attachment was scrubbed...
Name: audio.c.zip
Type: application/octet-stream
Size: 3836 bytes
Desc: not available
Url : http://lists.xiph.org/pipermail/vorbis-dev/attachments/20010728/f071c3c3/audio.c.obj