Invalid HTML5 audio attribute - currentTime?

Question

I will play a bit with the HTML5 <audio> , and I noticed some strange behavior related to the currentTime attribute.

I wanted the local audio file to play and the timeupdate event to timeupdate detected when it ends by comparing the currentTime attribute with the duration attribute.

It really works very well if I let the song play from beginning to end - the end of the song is determined correctly.

However, manually modifying currentTime (either directly using JavaScript or using browser-based controls) causes the API to no longer return the correct currentTime value, but seems to set it a few seconds ahead of the position that is actually playing.

(These "few seconds" ahead are based on Chrome, Firefox seems to be completely crazy, which leads to the discrepancy becoming larger.)

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

Can someone tell me why this is happening - or I just didn't understand what the API should do?

PS: I just noticed that this only happens with MP3-encoded files, OGG files completely succeed.

Answer 1

Firstly, I cannot reproduce your problem on my machine, but at the moment I only have a small MP3 file, so this can be a problem. In any case, I think I can explain what is happening.

MP3 files (MPEG) are very simple streams and do not contain absolute positional data in them. It is not possible to read the first part of the file to find out at what byte offset some arbitrary frame begins. The media player searches in the needle file. That is, he knows the size of the entire track and approximately how far in the track is your time offset. He guesses and starts to decode, rising as soon as he synchronizes with the header of the next frame. This is an inaccurate process.

Ogg is a more robust container and has time offsets built into its frame headers. Searching an Ogg file is much simpler.

Another problem is that most browsers that support MP3 do this only because the codec is already available on your system. Playback Ogg Vorbis and MP3s are usually completely different libraries with different APIs. While web standards do a lot to provide a common abstraction, the small implementation details cause the quirks you see.

Answer 2

After several hours of struggle with this mysterious problem, I believe that I understand what is happening here. This is not about .ogg vs .mp3, it is a question of a variable compared to the constant encoding of the bitrate in mp3 (and, possibly, in other types of files).

I cannot take responsibility for detecting this, just to clear the gaps. Terrill Thompson, a gentleman and scientist, wrote a detailed article about this issue on February 1, 2015.

I write this for everyone who is faced with this synchronization problem (which makes it impossible to accurately synchronize audio and text), because if you do this, it is a real nightmare to find out what is happening.

My next step is to do a few more tests and finally figure out an efficient way to convert all my .mp3s to a constant bit rate. I think FFMPEG might help, but I'm exploring this in a different thread. Thanks also to Loilo for the initial post about this issue and to Brad for the information he provided.