Red Hat Bugzilla – Bug 174080
Applications crash playing a .wav file
Last modified: 2013-10-20 18:41:07 EDT
audiofile-0.2.6-1 audiofile crashes playing the attached .wav file (and it would crash Evolution if that file was used as an alert for example). Patch attached. patch from Brad Hinson <bhinson@redhat.com>
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