Bug 174080

Created attachment 121445 [details]
audiofile-framecount.patch

Created attachment 121446 [details]
laser.wav

Hello,

First off, the WAV file is corrupt, or at least nonstandard.  I'm interested to
know where you found it (or what produced it).

The second half of the included patch (ignore the fact chunk in uncompressed
data) looks safe enough.  The first part, however, is certainly incorrect (and
irrelevant to your prolem AFAICT) however I'm interested to know what the
rationale behind it is.  As far as I know, the only 'fact' chunk format
libaudiofile has a chance of supporting is the 'single word contents indicating
uncompressed file size as le32', which is the way it is pre-patch.  I'm unaware
of any other documented possibilities.

The second worry is that libaudiofile (or perhaps some of the Evo code using it)
is simply dealing badly with a wav file that's a different length than it
declares; this is not an uncommon occurence and if that too crashes Evo, it's
not libaudiofile's fault.

Summry:  Patch part two is good; patch part one is not, but I'd like to know
what it's trying to accomplish before acting.  There is also concern that this
fix will simply mask the real problem in the code using the library.

Monty

Reposting response to comment 11 (it was lost in the BZ outage):
---

These wav files are included with OpenOffice
(/usr/lib/ooo-1.1/share/gallery/sounds/).  I do not believe they are corrupt,
rather, they use an optional Fact chunk.  Since libaudiofile isn't checking for
a fact chunk, it's reading garbage for the frame count, which confuses anyone
trying to play the file.

I think fixing the wav files would be masking the problem, because any
uncompressed waveform is allowed to have a fact chunk.  We have to allow for it
instead of interpreting it as part of the next field, which happens to be
totalFrames.

Here's where I got info on the fact chunk:
http://www.sonicspot.com/guide/wavefiles.html#fact

I've tested this patch on wav files with and without a fact chunk, and the
results were good.  Frame count read was always valid, plus you can hear the
difference - When the frame count is garbage, esdplay /usr/lib/.../laser.wav 
(which uses libaudiofile) plays incorrectly.

[reconstructing a response that was lost in the Bugzilla crash:]

The refecerence you site for the FACT chunk is correct and agrees both with the
original audiofile code and with the conclusion that the OOo WAV files are
corrupt.  I'm not sure why you've come to the opposite conclusion.

The patch you provided worked in your tests because you didn't try any
compressed files that have a FACT chunk, only uncompressed files.  The patch,
as-is, breaks the compressed case.

In any case, the second half of the patch is both reasonable and 'fixes' the
behavior with the WAVs you've pointed out.  I've applied it. *This does not
change the fact that those WAV files are corrupt.*

An advisory has been issued which should help the problem
described in this bug report. This report is therefore being
closed with a resolution of ERRATA. For more information
on the solution and/or where to find the updated files,
please follow the link below. You may reopen this bug report
if the solution does not work for you.

http://rhn.redhat.com/errata/RHBA-2006-0583.html