currentTime does not position audio correctly (mp3)

RESOLVED WORKSFORME

Status

()

defect
RESOLVED WORKSFORME
5 years ago
3 years ago

People

(Reporter: colin, Unassigned)

Tracking

28 Branch
x86_64
Windows 8.1
Points:
---

Firefox Tracking Flags

(Not tracked)

Details

Attachments

(1 attachment)

Reporter

Description

5 years ago
User Agent: Mozilla/5.0 (Windows NT 6.3; WOW64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/33.0.1750.154 Safari/537.36

Steps to reproduce:

load an mp3 in an audio tag.  Use "currentTime" to set the playback position to 10 secs. testcase attached.


Actual results:

playback starts at around 12 seconds.  Player still displays 10 seconds.


Expected results:

playback starts at 10 seconds.
Reporter

Comment 1

5 years ago
This happens on the release stream (28.0) and on Nightly (31.0a1 (2014-04-09))

Comment 2

5 years ago
bug 587465?
Component: Untriaged → Video/Audio
Product: Firefox → Core

Comment 3

5 years ago
This is likely a problem with audio that is encoded at Variable Bitrate.
The demo problem on stackoverflow [1] goes away if you convert the mp3 source
from VBR to fixed bitrate encoding.

[1] http://stackoverflow.com/questions/22911175/html5-audio-starts-from-the-wrong-position-in-firefox

Comment 4

5 years ago
I don't wish to be a "me too", but I would like to add that I don't feel GavinBrelstaff 's solution is a proper one. Many various desktop audio players can handle seeking in to variable bitrate MP3 files and end up at the correct location as indicated by the progress bar. If they can do this is because they have the entire file at their disposal, I would like to note that at least on the desktop (as opposed to mobile), the entire file is usually fetched at once if the preload property on the audio element is left alone, set to auto, or any JS code manually calls load().

On top of that, there are many web apps or libraries out there for playing back audio. I seems likely more than a few would be designed for deployment by anyone using audio the author of the code has no control over. I'm even writing one such library. It would be quite onerous on those potential users to indicate in the README they first need to convert all their audio to a constant bitrate or otherwise ensure none of it has a variable bitrate. I wouldn't doubt many would either disregard the warning entirely or go find another app or library doing the same thing but which doesn't require this of them, even if it's broken in the same way underneath and doesn't tell them.


At any rate, I can add some details to this:
--------------------------------------------

* Despite the user agent from the original post seeming to be from Chrome, this does occur in Firefox 29 (tested on Windows 7). "Mozilla/5.0 (Windows NT 6.1; WOW64; rv:29.0) Gecko/20100101 Firefox/29.0"

* The duration property value of a variable bitrate track is correct on all VBR files I tested.

* Though I can't determine where it actually resumes playing after a seek (setting the "currentTime" property), it never seems nearly as far as requested. When the audio resumes, it continues to play out the remainder of the song after the point from which it actually resumed. This means when playback reaches the duration calculated when the file was first loaded, it will continue to increase the duration by the amount it plays. This new duration sticks around even if you seek back to a previous point in the file.

Ex: If a song 60s long was told to seek to 30s but instead actually resumed playback 10s in, then the duration would eventual increase to 70s after playback (currentTime) reached 60s, counting up every time currentTime updates.
We could probably parse the MP3 data as it comes in over the network and figure out how many frames are in each packet and index the file to improve our seek accuracy.

Comment 6

5 years ago
Just a little note about another use case affected by this issue: https://github.com/podlove/podlove-publisher/issues/291

Comment 7

5 years ago
Thank you for working on this :-)

Updated

5 years ago
Duplicate of this bug: 1043765

Comment 9

4 years ago
Just a post to confirm that this bug is present on current version of FF 39.0.3 under Windows 7 and Windows 10. Also to say that Chrome and even Edge (IE) successfully seeks to correct position and does not have this bug.

Comment 10

4 years ago
MP3's that have been encoded with VBR usually have a 'Xing / VBRI' header.
Most have a TOC in them useful for seeking.

I'm not a programmer here, but i have found these pages that may help.

http://www.codeproject.com/Articles/8295/MPEG-Audio-Frame-Header#XINGHeader
https://github.com/gypified/libmp3lame/blob/master/libmp3lame/VbrTag.h

Comment 11

4 years ago
Or the complete SDK for it i just found...

http://www.mp3-tech.org/programmer/sources/vbrheadersdk.zip

Comment 12

4 years ago
I'm using ffmpeg to adjust audio pitch, e.g.
ffmpeg -i foo.mp3 -af aresample=44100,asetrate=66150,atempo=.66667 -aq 6 -ar 44100 bar.mp3
While the original file works fine in firefox as far as seeking using currenttime is concerned, the repitched file fails quite miserably to seek correctly, although it works fine if just played from beginning to end. Chrome seems to have no problem with either file. I'm running the latest version of firefox on Windows 10. Also, the same ffmpeg command applied to ogg files works fine in both chrome and firefox. For what it's worth, I'm running ffmpeg 2.7.2 with libmp3lame 3.99.5

Comment 13

4 years ago
(In reply to Mike Speciner from comment #12)
> I'm using ffmpeg to adjust audio pitch, e.g.
> ffmpeg -i foo.mp3 -af aresample=44100,asetrate=66150,atempo=.66667 -aq 6 -ar
> 44100 bar.mp3
> While the original file works fine in firefox as far as seeking using
> currenttime is concerned, the repitched file fails quite miserably to seek
> correctly, although it works fine if just played from beginning to end.
> Chrome seems to have no problem with either file. I'm running the latest
> version of firefox on Windows 10. Also, the same ffmpeg command applied to
> ogg files works fine in both chrome and firefox. For what it's worth, I'm
> running ffmpeg 2.7.2 with libmp3lame 3.99.5

I should also mention that when the seek fails to go to the right place, currenttime continues to be reported incorrectly as the audio plays.
Is the issue reproducible in nightly?

Comment 15

4 years ago
(In reply to Anthony Jones (:kentuckyfriedtakahe, :k17e) from comment #14)
> Is the issue reproducible in nightly?

Yep, 42.0a2 (2015-08-20) has this problem.
I'm guessing that this would be fixed by bug 1168435 which is the parser that Android L uses.
See Also: → 1168435
Component: Audio/Video → Audio/Video: Playback
The original file is no longer accessible, however it is quite probable that this was fixed by bug 1163667.
This is a pre-MP3TrackDemuxer bug and is no longer valid (verified on http://zahlensender.net/). Marking it as a duplicate of bug 1163667 might be misleading (older bug), so I'm marking it as wfm.
Status: UNCONFIRMED → RESOLVED
Closed: 3 years ago
Resolution: --- → WORKSFORME
You need to log in before you can comment on or make changes to this bug.