HTML5 audio - currentTime attribute inaccurate?

Question

I'm playing around a bit with the HTML5 <audio> tag and I noticed some strange behaviour that has to do with the currentTime attribute.

I wanted to have a local audio file played and let the timeupdate event detect when it finishes by comparing the currentTime attribute to the duration attribute.

This actually works pretty fine if I let the song play from the beginning to the end - the end of the song is determined correctly.

However, changing the currentTime manually (either directly through JavaScript or by using the browser-based audio controls) results in the API not giving back the correct value of the currentTime anymore but seems to set it some seconds ahead of the position that's actually playing.

(These "some seconds" ahead are based on Chrome, Firefox seems to completely going crazy which results in the discrepancy being way bigger.)

A little jsFiddle example about the problem: http://jsfiddle.net/yp3o8cyw/2/

Can anybody tell me why this happens - or did I just not getting right what the API should do?

P.S.: I just noticed this actually only happens with MP3-encoded files, OGG files are totally doing fine.

Answer 1

After hours of battling this mysterious issue, I believe I have figured out what is going on here. This is not a question of .ogg vs .mp3, this is a question of variable vs. constant bitrate encoding on mp3s (and perhaps other file types).

I cannot take the credit for discovering this, only for scouring the interwebs. Terrill Thompson, a gentlemen and scholar, wrote a detailed article about this problem back on February 1st, 2015, which includes the following excerpt:

Variable Bit Rate (VBR) uses an algorithm to efficiently compress the media, varying between low and high bitrates depending on the complexity of the data at a given moment. Constant Bit Rate (CBR), in contrast, compresses the file using the same bit rate throughout. VBR is more efficient than CBR, and can therefore deliver content of comparable quality in a smaller file size, which sounds attractive, yes?

Unfortunately, there’s a tradeoff if the media is being streamed (including progressive download), especially if timed text is involved. As I’ve learned, VBR-encoded MP3 files do not play back with dependable timing if the user scrubs ahead or back.

I'm writing this for anyone else who runs into this syncing problem (which makes precise syncing of audio and text impossible), because if you do, it's a real nightmare to figure out what is going on.

My next step is to do some more testing, and finally to figure out an efficient way to convert all my .mp3s to constant bit rate. I'm thinking FFMPEG may be able to help, but I'll explore that in another thread. Thanks also to Loilo for originally posting about this issue and Brad for the information he shared.

Answer 2

First off, I'm not actually able to reproduce your problem on my machine, but I only have a short MP3 file handy at the moment, so that might be the issue. In any case, I think I can explain what's going on.

MP3 files (MPEG) are very simple streams and do not have absolute positional data within them. It isn't possible from reading the first part of the file to know at what byte offset some arbitrary frame begins. The media player seeks in the file by needle dropping. That is, it knows the size of the entire track and roughly how far into the track your time offset is. It guesses and begins decoding, picking up as soon as it synchronizes to the next frame header. This is an imprecise process.

Ogg is a more robust container and has time offsets built into its frame headers. Seeking in an Ogg file is much more straightforward.

The other issue is that most browsers that support MP3 do so only because the codec is already available on your system. Playing Ogg Vorbis and MP3 are usually completely different libraries with different APIs. While the web standards do a lot to provide a common abstraction, minor implementation details cause quirks like you are seeing.