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

[Firelight Multimedia]

That's correct, any wav loader should use something like below (alloc or
seek past, whatever) to get the format chunk and not assume it is the
size of the structure.. 

format = (WAVE_FORMAT *)calloc(chunk.size < sizeof(WAVE_FORMAT) ?
sizeof(WAVE_FORMAT) : chunk.size);

i even have wav files with 2 data chunks in them which can crash some
loaders :)

> -----Original Message-----
> From: owner-vorbis-dev at xiph.org [mailto:owner-vorbis-dev at xiph.org] On
> Behalf Of Chris Wolf
> Sent: Saturday, 28 July 2001 8:05 PM
> To: vorbis-dev at xiph.org
> Subject: Re: [vorbis-dev] oggenc broken for some types of WAV files
> 
> >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

--- >8 ----
List archives:  http://www.xiph.org/archives/
Ogg project homepage: http://www.xiph.org/ogg/
To unsubscribe from this list, send a message to 'vorbis-dev-request at xiph.org'
containing only the word 'unsubscribe' in the body.  No subject is needed.
Unsubscribe messages sent to the list will be ignored/filtered.