gstreamer audio decoders produce AudioBuffer longer than original file

RESOLVED INVALID

Status

()

Core
Web Audio
RESOLVED INVALID
2 years ago
2 years ago

People

(Reporter: aykevanlaethem, Unassigned)

Tracking

37 Branch
x86_64
Linux
Points:
---

Firefox Tracking Flags

(Not tracked)

Details

Attachments

(1 attachment)

(Reporter)

Description

2 years ago
Created attachment 8560717 [details]
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.
(Reporter)

Comment 1

2 years ago
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.
(Reporter)

Comment 2

2 years ago
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)
(Reporter)

Comment 4

2 years ago
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
Last Resolved: 2 years ago
Resolution: --- → INVALID
You need to log in before you can comment on or make changes to this bug.