Closed Bug 1130611 Opened 10 years ago Closed 10 years ago

gstreamer audio decoders produce AudioBuffer longer than original file

Categories

(Core :: Web Audio, defect)

37 Branch
x86_64
Linux
defect
Not set
normal

Tracking

()

RESOLVED INVALID

People

(Reporter: aykevanlaethem, Unassigned)

Details

Attachments

(1 file)

Attached audio sine.m4a
User Agent: Mozilla/5.0 (X11; Linux x86_64; rv:37.0) Gecko/20100101 Firefox/37.0 Iceweasel/37.0a2 Build ID: 20150201004024 Steps to reproduce: 1. Load the page http://jsfiddle.net/nqg226wf/ (a test page I put together). 2. Select the audio file attached to this bug report. The .m4a file was converted from a .wav file using neroAacEnc. The .wav file was created using Audacity (Generate > Tone with default settings apart from the length which is 44101 samples). Actual results: The shown audio file has 46080 audio samples. An MP3 of the same original WAV file encoded using LAME produces an AudioBuffer with 47232 samples. Expected results: It should have a length of 44101 audio samples. As all other codecs work correctly (apart from the Opus codec - bug #1129355) I suspect the problem lies somewhere in gstreamer. I have not tested Windows or OS X.
Forgot to mention: I tested this on Iceweasel from Debian (the aurora version of Debian testing, which is 37.0a2). This build uses gstreamer 1.0.
See http://mozilla.debian.net/. I used that build as I couldn't manage to build Firefox with gstreamer support (I added the build flag and it failed to build until I installed the required -dev packages, but still the build didn't decode MP3 or AAC).
Can you test to decode your file using gstreamer directly, and check the number of frames? It might just be gstreamer acting up, in which case we can't do much.
Flags: needinfo?(aykevanlaethem)
With a command like: $ gst-launch-1.0 filesrc location=sounds/test/sine.m4a ! decodebin ! audioconvert ! 'audio/x-raw,format=S16LE' ! wavenc ! filesink location=extracted.wav I get the same number of frames as Firefox reports, so it's a GStreamer issue, but... http://sourceforge.net/p/gstreamer/mailman/message/26763211/ It appears like it may be possible to implement it, but googling around a bit it looks like GStreamer (still?) has many bugs in it's gapless playback implementation.
Flags: needinfo?(aykevanlaethem)
I'll close as invalid, then, thanks for putting the extra work and verify it's not Firefox's fault, much appreciated !
Status: UNCONFIRMED → RESOLVED
Closed: 10 years ago
Resolution: --- → INVALID
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Creator:
Created:
Updated:
Size: