Re: [SoX-users] Reading a broken WAV file?

[Chris B. <ch...@cn...>]

On Sun, May 23, 2010 at 07:08:05PM +0000, Michael Chapman wrote:
>
> [...]
>
> > perpetuates the error.
> > Not SoX's fault (I suspect the flavour of WAV it writes is limited to
> > 4GB).
> >
> > IT WOULD BE NICE if SoX did 'WARN' when doing this though,
> > i.e. "I cannot write a proper header to the output file because
> > it is >4GB".
>
> Maybe something like the attached should be applied? Not sure if this
> covers all eventualities, still getting acquainted with the source code.
>
> [...]
>
>
I was about to submit this patch but think I may have detect a logic error
in existing code.  Thor (or anyone), do you think you could help me debug?

Bottom line is if a WAV length of a single chunk is beyond the size that can
be represented in the 32-bit length field of WAV files then issues will
occur with certain applications that depend on valid lengths.  Some
applications understand the basic issue and will go into special modes if it
see maximum chunk length value of 0xffffffff and thats what SoX is
attempting to do in these cases.

So I'm not sure if original issue is because the application used doesn't
understand special case of 0xffffffff length or if SoX is not writing this
special value correctly.

Thor, was there a special reason you used lsx_filelength() instead of
looking at numSamples with your warning patch?  I ask because file length !=
wav chunk length.

I suspect SoX has some logic error here and is not writing special length
value of 0xffffffff into header.  Code reviews of this area appreciated and
patches especially welcomed.

A two second glance makes me think:

    if ((!second_header && !ft->signal.length) ||
        wav->numSamples > 0xffffffff) {

should be closer to:

    if ((!second_header && !ft->signal.length) ||
        wav->numSamples > (0xffffffff / wBlockAlign)) {

or else we'll have a 32-bit overflow when it calcs dwDataLength.  And that
above probably only works for standard PCM case... and doesn't account for
possible overflow from rounding up to even chunk lengths and additional RIFF
overhead.

Chris