Bug#435754: libopenal0a: WAV file generated by waveout device is invalid

[Michalis Kamburelis]

Package: libopenal0a
Version: 1:0.0.8-5
Severity: normal

A sample WAV file generated by tremulous (when ~/.openalrc
contained "( define devices '(waveout) )") is on
http://www.camelot.homedns.org/~michalis/tmp/openal-1.wav

This is not a correct WAV file. Trying to play it with gstreamer:

$ gst-launch filesrc location=openal-1.wav ! wavparse ! audioconvert ! audioresample ! alsasink
Setting pipeline to PAUSED ...
Pipeline is PREROLLING ...
ERROR: from element /pipeline0/wavparse0: GStreamer encountered a general stream error.
Additional debug info:
gstwavparse.c(1346): gst_wavparse_stream_headers (): /pipeline0/wavparse0:
Stream claims av_bsp = 22050, which is more than 0 - invalid data
ERROR: pipeline doesn't want to preroll.
Setting pipeline to NULL ...
FREEING pipeline ...

Consequently, trying to play it with totem crashes totem.

Some programs are able to handle it, e.g. sox.
Converting it through sox like
  sox openal-1.wav newopenal-1.wav
produces valid WAV file (playable by everything).

Investigating WAV file with my own WAV file reader, I see that the
WAV file is invaild because ChunkSize recorded in file header is
too large: ChunkSize recorded in main RIFF chunk should not include
the 8 bytes needed for ChunkId and ChunkSize itself. Practically
speaking, for all WAV files, ChunkSize should always be the size
of the WAV file minus 8 bytes. See e.g.
[http://ccrma.stanford.edu/courses/422/projects/WaveFormat/]
for description of WAV file format.

But in WAV files generated by OpenAL waveout device, ChunkSize
is always exactly equal to the size of the file. So the WAV file
is invalid, although some programs don't notice it: if you read
WAV file without paying attention to ChunkSize recoded in RIFF chunk,
or if you just stop reading after "data" chunk, you will not notice
the problem. But if your program tries to read all chunks within
WAV file, then it will notice that the WAV file ends unexpectedly,
since ChunkSize indicates that 8 more bytes should be available.

That's my analysis... But I didn't find in OpenAL code where this
should be fixed.

-- System Information:
Debian Release: lenny/sid
  APT prefers testing
  APT policy: (990, 'testing'), (500, 'stable')
Architecture: i386 (i686)

Kernel: Linux 2.6.18-4-k7 (SMP w/1 CPU core)
Locale: LANG=pl_PL, LC_CTYPE=pl_PL (charmap=ISO-8859-2)
Shell: /bin/sh linked to /bin/bash

Versions of packages libopenal0a depends on:
ii  libc6                         2.6-2      GNU C Library: Shared libraries

libopenal0a recommends no packages.

-- no debconf information