Closed Bug 524109 Opened 15 years ago Closed 8 years ago

Support 24-bit (and 32-bit?) PCM WAV files (not just 8- and 16-bit) in <audio> tag

Categories

(Core :: Audio/Video: Playback, enhancement)

enhancement
Not set
normal

Tracking

()

RESOLVED FIXED
mozilla46
Tracking Status
firefox46 --- fixed

People

(Reporter: danstowell+bugzilla, Assigned: lchristie, Mentored)

References

Details

(Whiteboard: [parity-chrome])

Attachments

(1 file, 2 obsolete files)

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: 

As discussed in bug 523837: 24-bit PCM WAV files are quite common but only 8-bit and 16-bit are currently supported in the <audio> tag. (Observed in Firefox 3.5.3 and 3.6.)

The original 1991 WAV specification actually specifies arbitrary bit depths (12 and 20 are mentioned as examples - http://www-mmsp.ece.mcgill.ca/Documents/AudioFormats/WAVE/Docs/riffmci.pdf pages 59&60). Note that I'm not talking about the later "extended" WAV specs. I don't believe that arbitrary bit depths are common but I work with audio and routinely encounter 24-bit integer PCM WAVs, so I would request that those be supported. 32-bit may also be worth adding at the same time (although theoretically 24-bit is sufficient to cover the dynamic range that we hear, 32-bit is encountered too).

In bug 523837 comment 4 MG suggests 32-bit float may also be worth supporting. (He also points out that the HTML 5 draft doesn't quite make clear what the baseline supported format for audio should be, if any.)


Reproducible: Always
Status: UNCONFIRMED → NEW
Ever confirmed: true
Also see about adding the legacy a-log, u-log, float-32, and float-64 if possible.

I wrote a WAV file decoder+player in javascript that handles and plays the major wav types, not just PCM: http://www.grantgalitz.org/wav_player/ , so a future patch be tested against for reproduction quality.

Some notes on a-log and u-log: They're 8-bit, but just have the 8-bit data run through specific lookup tables (a-log and u-log tables each are 256 entries, obviously.). Said lookup tables are in http://www.grantgalitz.org/wav_player/WAVDecoder.js as well as the other codec processing.
Also a future patch should consider the non-byte aligned bit rates (Like 7, 30, 4, etc.). They are still valid, but require a separate path in code if it's going to be optimized or hacked in (Normalization and bit clears need to be added possibly).
Even possibly support the big-endian version of WAVE, that has the RIFX/FFIR master ID instead of RIFF.
Moved some stuff around with the WAV decoder, so the a-law and u-law lookup tables are now in http://www.grantgalitz.org/wav_player/decode.js .

Got bored added AIFF and AIFF-C support to the javascript audio binary decoder & player as well: http://www.grantgalitz.org/wav_player/AIFFDecoder.js
Is there any update on supporting 24-bit or better PCM WAV files?
(In reply to somelinguist from comment #6)
> Is there any update on supporting 24-bit or better PCM WAV files?

I'm not aware of anyone working on this. We mostly use WAV support for testing; because of the bandwidth use it's not popular for sites. It's also a simple format to parse in javascript, as discussed above.

If this feature is important to you, I can suggest:

- patches and test cases always help
- test other current browsers and report how broad support for particular PCM wav variants is.
(In reply to Ralph Giles (:rillian) from comment #7)

I agree that WAV generally isn't that useful in a browser because of bandwidth. 

I'm writing a language-learning program in HTML5/Javascript that will run in XULRunner (possibly with a web-based port eventually), and it would be ideal to be able to play a wider variety of WAV audio formats. The program plays audio referenced in XML-based dictionaries exported from other programs. The other programs do support higher quality WAV formats, so it would be nice not to need to have users convert them if they've already used higher quality files.

I looked at the Javascript decoder above, but I couldn't figure out how to use it. Would it be possible to use such a decoder in conjunction with the audio tag so that other formats would still be supported natively? Or if I go the Javascript decoding route, do I need to dump the audio tag and decode other formats, too?

It's my understanding that in the future Firefox will support MP3 (etc) if a third-party decoder is installed on the system. Will this also work for other formats such as the unsupported WAV formats?

Regarding browser support: Chrome will also play signed 24-bit and 32-bit float PCM WAV files. IE 10 doesn't. I don't have Opera or Safari to test.

Thanks for your help.
(In reply to somelinguist from comment #8)
> It's my understanding that in the future Firefox will support MP3 (etc) if a
> third-party decoder is installed on the system. Will this also work for
> other formats such as the unsupported WAV formats?

No.

Our intention is to be very strict with what formats we enable in platform decoders, as we want to limit codec fragmentation on the web and we also have limited ability prevent or work around bugs found in platform decoders.
(In reply to somelinguist from comment #8)

> I looked at the Javascript decoder above, but I couldn't figure out how to
> use it. Would it be possible to use such a decoder in conjunction with the
> audio tag so that other formats would still be supported natively?

Yes. For example you can go through the document at load time and replace all <audio> elements referencing wav files with the javascript decoder.

> Regarding browser support: Chrome will also play signed 24-bit and 32-bit
> float PCM WAV files. IE 10 doesn't. I don't have Opera or Safari to test.

Thanks for testing. If you put up a public page with test files for the formats you want to support I can test Safari and Opera.
Whiteboard: [parity-chrome]
Thanks for the tip about replacing audio tags. I'll try it out when I get a chance. 

I don't have a place I can put the files I have publicly, but I was able to test them in Opera 12.14 and Safari for Windows (the latest version (5.1.7) I could find was from last May). I was able to load and play:
Signed 16-bit PCM
Signed 24-bit PCM
Signed 32-bit PCM
32-bit float
64-bit float

Additionally, Safari for Windows would play U-Law and A-Law files.

It would be great to see similar native support in Firefox!
Blocks: 851530
The same arguments that have brought about support in Chrome likely apply: http://code.google.com/p/chromium/issues/detail?id=217772

mu-law and a-law wav files are small enough to be used on the web and are used by telephone companies for voicemail messages and call recordings.
It seems the request for a test page is still open so here goes:
http://daniemon.com/test/wav/

Results as of Sep 2014 are as follows:
16-bit, 24-bit and 32-bit work in WebKit (tested in Midori)

16-bit and 24-bit work in Blink (tested in Chromium and Opera)

Only 16-bit works in Mozilla (tested in Firefox)

For what it's worth, old Opera (Presto) plays all three files.
Now that the Web Audio API starts to get used a lot, this is becoming a lot more important. It's very common in the music production world to use 24bits files, and it would be great to have support for them in Firefox.
Mentor: padenot
Component: Audio/Video → Audio/Video: Playback
Assignee: nobody → lchristie
Attached patch bug-524109-fix.patch (obsolete) — Splinter Review
Attachment #8690595 - Flags: review?(cpearce)
Comment on attachment 8690595 [details] [diff] [review]
bug-524109-fix.patch

Review of attachment 8690595 [details] [diff] [review]:
-----------------------------------------------------------------

You also need to run dom/media/test/make-headers.sh and `hg add dom/media/test/wavedata_s24.wav^headers^`.

You also need a commit message of the form "Bug XXX - What change your patch makes. r=cpearce".

r=cpearce, with the changes made.

::: dom/media/wave/WaveReader.cpp
@@ +194,5 @@
>  
> +template <> inline float
> +Signed24bIntToAudioSample<float>(int32_t aValue)
> +{
> +  return aValue / 8388608.0f;

Windows calculator tells me that 0x7fffff is 8388607, not 8388608.

So shouldn't you be dividing by 8388607?

@@ +483,4 @@
>    } else {
>      mSampleFormat = FORMAT_S16;
>    }
> +

Looks like you're adding trailing whitespace to the line here. Don't.
Attachment #8690595 - Flags: review?(cpearce) → review+
Fixed comments 1,2, and 4. The division is by 0x800000 not 0x7fffff because there is one more negative number than positive, so changing this could result in a float (just) outside the expected [-1.0, 1.0] range.
Attached patch bug-524109-fix.patch (obsolete) — Splinter Review
Attachment #8690595 - Attachment is obsolete: true
Attachment #8697299 - Flags: review?(cpearce)
Attachment #8697299 - Flags: review?(cpearce) → review+
Keywords: checkin-needed
sorry failed to apply:

patching file dom/media/wave/WaveReader.cpp
Hunk #2 FAILED at 162
1 out of 5 hunks FAILED -- saving rejects to file dom/media/wave/WaveReader.cpp.rej
patch failed, unable to continue (try -v)
patch failed, rejects left in working directory
errors during apply, please fix and qrefresh bug-524109-fix.patch
Flags: needinfo?(lchristie)
Keywords: checkin-needed
Attachment #8697299 - Attachment is obsolete: true
Flags: needinfo?(lchristie)
Keywords: checkin-needed
sorry had to back this out seems this or the other change caused test failures like https://treeherder.mozilla.org/logviewer.html#?job_id=18535643&repo=mozilla-inbound
Keywords: checkin-needed
https://hg.mozilla.org/mozilla-central/rev/14b8a98aff19
Status: NEW → RESOLVED
Closed: 8 years ago
Resolution: --- → FIXED
Target Milestone: --- → mozilla46
No longer blocks: 851530
You need to log in before you can comment on or make changes to this bug.