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

[Reinhard Tartler]

forwarded 435754 openal-devel at opensource.creative.com 
tag 435754 upstream
thanks for you report.

Hello OpenAL developers. 

The following bugreport has been received at the debian bug tracking
system regarding the openal package. We ship the latest openal SI
release, which is version 0.0.8 downloaded from
http://openal.org/downloads.html (with a small patch to make it build on
GNU/kFreeBSD systems). Can you please take a look at the report and
share your opinion with us?  Please retain the CCs.

Btw, does the SI of openal have a bug tracking system, or do you prefer
bugreports via email, like this one?

Thanks in advance!

Michalis Kamburelis <michalis.kambi at gmail.com> writes:

> 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

-- 
Gruesse/greetings,
Reinhard Tartler, KeyID 945348A4