User Agent: Mozilla/5.0 (X11; Linux x86_64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/75.0.3770.100 Safari/537.36

Steps to reproduce:

decodeAudioData produces different results in Firefox compared to Chrome and Safari for MP3 audio that contains information frames. There's a demo page at [1], which compares the output from decodeAudioData with a command line waveform visualisation tool that I have written [2].

The waveform is rendered in a canvas, using data from waveform-data.js, a library that downsamples the audio to produce a visual representation [3].

A blog post [4] goes into more detail on the information frames issue.

We have an audio visualisation library [5] where this issue causes a slight visible difference between the playhead position you see and the audio you hear.

[1] https://waveform.prototyping.bbc.co.uk/waveform-data-issue-63/
[2] https://github.com/bbc/audiowaveform
[3] https://github.com/bbc/waveform-data.js
[4] https://thebreakfastpost.com/2016/11/26/mp3-decoding-with-the-mad-library-weve-all-been-doing-it-wrong/
[5] https://github.com/bbc/peaks.js

Actual results:

In Firefox, the output from decodeAudioData agrees with Ex. 1, where the audiowaveform command line tool does not skip information frames.

Expected results:

I expect the output from decodeAudioData to be the same as Ex. 2 in the web page, i.e., the decoder should skip information frames.

I believe that the right call here would be to just triage this issue right away, without attempting to reproduce it: IMO it has enough information to be actionable. Please NI if there is need for QA to attempt to confirm this issue.

This is what I have on Firefox Nightly (71), on Mac, a bit between Ex. 1 and Ex. 2. On what platform are you testing this?

We're going to change mp3 decoders soon however, so this might well be fixed.

I'm testing on Firefox 69.0 on Ubuntu 16.04 (see firefox-69-linux.png), where as I believe the right output should be as in chrome-76-linux.png.

I should add, the fix I made to audiowaveform involves reading encoding delay and padding data from a Xing or Info header, and skipping samples: https://github.com/bbc/audiowaveform/commit/59bc5d6a73c8e5c60cc5d9cad38d22ab373f7027#diff-91c0d8b3c188ac213c9de60687f1907eR623

And here's the output from Firefox 69.0.1 on Windows 10.

In bug 1582271, we're switching to use FFMpeg's mp3 decoder for all platform. When this is done (all the patches have been accepted), we'll have consistent result on all platform. At this stage, if the result is not correct, we'll fix it so that it skips the right number of samples.

I see that bug 1582271 is resolved. Here's what I get now in Firefox 71 nightly (2019-10-07) on Windows 7, so this still differs from audiowaveform and Chrome.

Note from the 1628072 dupe: this affects looping by introducing an audible gap between loops.
Other browsers can playback looping audio seamlessly.
It did not happen before Firefox 71 so should be treated as a regression.

I agree. It's time to do the right thing now, we have landed our mp3 decoder based on ffmpeg, so we can have a single code path for all platforms.

This doesn't work, it's never != 0

Depends on D85585

Per https://thebreakfastpost.com/2016/11/26/mp3-decoding-with-the-mad-library-weve-all-been-doing-it-wrong/, http://all-day-breakfast.com/m/ticks.mp3 is a file that has a noise burst at the very beginning and very end of the file, when decoded properly with the right skips/padding.

Attached is a web page that draws the very beginning and very end of the decoded file.

Depends on D91769

Depends on D91770

Depends on D91771

Depends on D91772

Depends on D91773

Backed outfor bustage at FFmpegAudioDecoder.cpp.

Backout link: https://hg.mozilla.org/integration/autoland/rev/2bab3d86ea9088464be445c357570d71478ca62f

Push with failures: https://treeherder.mozilla.org/#/jobs?repo=autoland&group_state=expanded&selectedTaskRun=P5e1kjRsQrOqHzcMEQgIRg.0&resultStatus=testfailed%2Cbusted%2Cexception&revision=116644341a76ed411944db5acbe88867ac92ba66

Failure log: https://treeherder.mozilla.org/logviewer.html#/jobs?job_id=317314379&repo=autoland&lineNumber=47060
https://treeherder.mozilla.org/logviewer.html#/jobs?job_id=317310347&repo=autoland&lineNumber=74834

I'll reland this after https://bugzilla.mozilla.org/show_bug.cgi?id=1668824.

Backed out 7 changesets (Bug 1566389) for causing bustages in FFmpegAudioDecoder.cpp

Push with failures: https://treeherder.mozilla.org/#/jobs?repo=autoland&resultStatus=testfailed%2Cbusted%2Cexception&revision=748e0d854d86610243b5a6e85e0c9e0f76f22f50&searchStr=inux%2Cx64%2Cdebug%2Cbuild-linux64-base-toolchains%2Fdebug%2CBb

Failure log: https://treeherder.mozilla.org/logviewer.html#/jobs?job_id=317618626&repo=autoland&lineNumber=74859

Backout: https://hg.mozilla.org/integration/autoland/rev/793b88bf8032e27c54714b66e550c7d923b52a34

https://hg.mozilla.org/mozilla-central/rev/253cdc0024a1
https://hg.mozilla.org/mozilla-central/rev/7ac585ebb2c1
https://hg.mozilla.org/mozilla-central/rev/6fdb8b5c6ae8
https://hg.mozilla.org/mozilla-central/rev/7a4200237fb1
https://hg.mozilla.org/mozilla-central/rev/6ad90ab742bf
https://hg.mozilla.org/mozilla-central/rev/bc144d4e01d0
https://hg.mozilla.org/mozilla-central/rev/ac99b200090e

Reproduced the initial issue using old Nightly without this fix. verified that using Firefox 83.0b3 the output from decodeAudioData is the same as Ex. 2 in the web page across platforms (Windows 10 64bit, macOS 11 and Ubuntu 18.04).