994561 - currentTime does not position audio correctly (mp3)

Status: RESOLVED WORKSFORME

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

Description

[colin]

Attachment: audio-currentTime.html

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.

Comment 1

[colin]

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

Comment 2

[YF (Yang)]

bug 587465?

Comment 3

[GavinBrelstaff]

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

[Art McBain]

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.

Comment 5

[Chris Pearce [:cpearce (Not reading bugmail)]]

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

[moxudo]

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

Comment 7

[moxudo]

Thank you for working on this :-)

Comment 9

[Dima Sokol]

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

[ripper5555]

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

[ripper5555]

Or the complete SDK for it i just found...

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

Comment 12

[Mike Speciner]

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

[Mike Speciner]

(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.

Comment 14

[Anthony Jones (:ajones, :kentuckyfriedtakahe, :k17e)]

Is the issue reproducible in nightly?

Comment 15

[Dima Sokol]

(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.

Comment 16

[Anthony Jones (:ajones, :kentuckyfriedtakahe, :k17e)]

I'm guessing that this would be fixed by bug 1168435 which is the parser that Android L uses.

Comment 17

[Jan Henning [:JanH]]

The original file is no longer accessible, however it is quite probable that this was fixed by bug 1163667.

Comment 18

[Eugen Sawin [:esawin]]

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.