CODEWITHSUNDEEP
javascripthtmlaudiosafari
Jaakko Karhu
Jaakko Karhu

Reputation: 2386

What causes desktop Safari html audio currentTime inaccuracy?

I am working in a project, where I need to create accurate audio editor.

I noticed, that Safari has some quirky behaviour when setting currentTime on audio. It seems that, depending on the currentTime where the jump happens and where to, the actual point in time can be off 2-3 seconds even.

I made a JS fiddle to demonstrate the issue.

The relevant parts of the code are these:

jump.addEventListener('click', function () {
  audio.currentTime = jumpToVal;
});

jump2.addEventListener('click', function () {
  audio.currentTime = Number.parseInt(jumpToVal) + Number.parseInt(jumpBufferVal);
  audio.volume = 0;
  setTimeout(function () {
    audio.volume = 1;
    audio.currentTime = jumpToVal;
  }, jumpDelayVal)
});

So basically what happens in this sample is that if trying to jump to 8s in audio after the point has been passed, the audio is started some seconds before that point. If setting the currentTime to, for example, 8 seconds less of that point and after a delay jumping to the point, it plays somewhat from the right position.

I would like to emphasise, that most likely this is just a coincidence, since the behaviour changes depending from where and to what point in time the currentTime is set. The issue is just clearest with this setting.

Compare for example to Chrome to hear the difference.

What is peculiar is that audio returns the same currentTime, no matter what is the end result. So in other terms, audio seems to "think" it is in the right position even when it is clearly not.

My questions are why is Safari so inaccurate with currentTime and if there is a workaround to this issue?

Safari version 12.0 (14606.1.36.1.9).

Upvotes: 5

Views: 1244

Answers (2)

pseudosavant
pseudosavant

Reputation: 7244

I can't access that MP3 file to be certain, but I'm pretty sure the issue is due to VBR MP3.

Apple's MP3 playback pipeline has had issues with accurate seeking within VBR (Variable Bit Rate, most MP3s) MP3s for a long time. It affects anything on Mac OS or iOS that uses the native MP3 decoder. Most podcasts are CBR MP3 for this reason - the Podcasts app uses the native decoder too.

There are a few options to work around this issue:

  1. Mux the MP3 audio stream from the MPEG-1 container (MP3 = MPEG-1 Layer 3) into an MPEG-4/MP4 container (e.g. ffmpeg -i myFile.mp3 -c copy myFile.m4a). This is a quick lossless process and the files will work in any browser.
  2. Encode the audio file as AAC/m4a. This also uses the MPEG-4 container and will play anywhere. Re-encoding an MP3 as AAC will always reduce the sound quality.
  3. If it must be MP3, (re)encode using CBR (Constant Bit Rate, less efficient) encoding. Re-encoding the MP3 will always reduce the sound quality.

Upvotes: 0

Sanyam Jain
Sanyam Jain

Reputation: 3025

Media format causes the issues.

Seek/currentTime updation doesn't work reliably on safari when media is flac(maybe other formats also).

But, When I switched the media format to mp3, it was as reliable as chrome!

Upvotes: 2

Related Questions