Closed Bug 523837 Opened 15 years ago Closed 15 years ago

24-bit WAV file never plays using <audio> tag (though 16-bit WAV, Ogg work fine)

Categories

(Core :: Audio/Video, defect)

defect
Not set
normal

Tracking

()

RESOLVED DUPLICATE of bug 481057

People

(Reporter: danstowell+bugzilla, Unassigned)

References

()

Details

User-Agent:       Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.4; en-US; rv:1.9.1.3) Gecko/20090824 Firefox/3.5.3
Build Identifier: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.4; en-US; rv:1.9.1.3) Gecko/20090824 Firefox/3.5.3

Exact same phenomenon seen on: Mac 10.4.11, ubuntu 9.04 64-bit, and opensolaris snv 125 32-bit x86. (Above, I've given the build ID from the Mac.)

Playing a 16-bit WAV, or an Ogg Vorbis, works fine. Playing an apparently standard-compliant 24-bit WAV fails: visually the player buffers forever, no sound is heard.

Reproducible: Always

Steps to Reproduce:
1. Visit the URL given above - the controls appear (pause, play etc)
2. Click the play button
3. Wait - "buffering" icon appears - expect audio to start playing (wait for 60 seconds?)
Actual Results:  
The "buffering" icon appears (a kind of spinning thing) but no sound. Waited for quite a while.


Expected Results:  
Audio should start playing.

(I was originally testing on localhost, and I do wait for at least a minute but still no sound; with a similar test using an Ogg file or 16-bit WAV, playback is instantaneous.)

The WAV file definitely exists (clicking the link in FF's source code view shows the wav file contents) and the mime-type seems correct, as shown: 

curl --head http://www.mcld.co.uk/test/audiotag/3kits_testrec_kit2_patt0_dly0.wav
HTTP/1.1 200 OK
Date: Thu, 22 Oct 2009 15:26:22 GMT
Server: Apache
Last-Modified: Thu, 22 Oct 2009 15:21:14 GMT
ETag: "ab226b9e-10268c-a55f6e80"
Accept-Ranges: bytes
Content-Length: 1058444
Vary: User-Agent
Content-Type: audio/x-wav


We have also tested it using the mime types "audio/wav" and "audio/wave". In both cases we edited /private/etc/httpd/users/me.conf then ran "apachectl configtest" and "apachectl restart", then used "curl --head" (as above) to verify the new mime type was in use. Exact same behaviour.


and I believe the file is a compliant WAVE file - here's the output from libsndfile's "sfinfo":

sfinfo wavs/3kits_testrec_kit2_patt0_dly0.wav
File Name      wavs/3kits_testrec_kit2_patt0_dly0.wav
File Format    Microsoft RIFF WAVE Format (wave)
Data Format    24-bit integer (2's complement, little endian)
Audio Data     1058400 bytes begins at offset 44 (2c hex)
               1 channel, 352800 frames
Sampling Rate  44100.00 Hz
Duration       8.000 seconds
Related to bug 491410?
Firefox doesn't support this format right now--it supports the basic PCM formats supported by WAVEFORMATEX/the original Waveform spec, and none of those that require WAVEFORMATEXTENSIBLE/later Microsoft extensions to the spec.  This means we support 8 and 16-bit PCM with 1 or 2 channels.

If there was a lot of demand and existing compatibility with other browser implementations, we could add support for other PCM formats.

In the case of an unsupported format, we will fire an error event and the controls will indicate an error.  This occurs in Firefox 3.6 betas and trunk builds, as the functionality was implemented in bug 481057 fairly recently.
Status: UNCONFIRMED → RESOLVED
Closed: 15 years ago
Resolution: --- → DUPLICATE
Hi - thanks for your reply. 

I can't find a specification that only specifies 8 or 16 bit. Could you point me towards it please? I see that the WAVEFORMATEX only supports those bit depths but the actual spec should presumably be the point of reference. My understanding is that the 1991 spec is the original one and 1994 introduced some extensions. The 1991 spec <http://www-mmsp.ece.mcgill.ca/Documents/AudioFormats/WAVE/Docs/riffmci.pdf> (p56-65) gives 8 and 16 bit as two examples (top of p59, top of p60) but explicitly allows a range of bit depths and discusses other depths as further examples (12 bits near bottom of p59, 20 bits near middle of p60).

Anyway, thanks again for your response - I would suggest that 24 and 32 bit depths are rather common and seemingly compliant with the original spec, so should I file a feature request to support these?
Originally the video/audio section of the HTML 5 draft included mandatory Waveform support, with the following text:

  User agents must support the WAVE container format with audio
  encoded using the 16 bit PCM (LE) codec, at sampling frequencies of
  11.025kHz, 22.050kHz, and 44.100kHz, and for both mono and
  stereo.

That's what I was referring to, sorry I was unclear earlier.  This section has since been removed (but is still present in the source as a comment), so there's no clear documentation of what support can be expected across browser implementations, which I think is rather unfortunate.  I protested this change and got the following response: http://lists.whatwg.org/htdig.cgi/whatwg-whatwg.org/2009-June/020623.html

We can consider adding support for 24-bit PCM samples, it's not a lot of work, and I would like to have support for 32-bit float PCM samples to make sound generation via Javascript easier anyway.

Please do file a feature request for this and CC me.
Thanks. Feature request filed as bug 524109
You need to log in before you can comment on or make changes to this bug.