[Bug]: Timing in web player is way off

[Fieldmouse88]

What happened?

When I switched from my iphone app to the web player, it continued at the same time code, but the audio was not at the same place in time.
Further investigation and looking at a single chapter, the text says both are the same length, but if i go to say 15m on phone app, windows media player and the audibooks web player, the phone and windows media player will be synced, but the web player will be waay off.
Instead, these to 2 timecodes play the same audio.

Im only using windows media player here for trouble shooting.

What did you expect to happen?

I would expect the same time code on all 3 players to play the same audio.
But they dont.

Steps to reproduce the issue

1. Not really sure if this is limited to only some files, but I could of course get you a sample of this current book if required.
   Simply try playing it at some random time code on the web player and then on the iphone or probably any other player. The audio will not be synced what so ever.

Audiobookshelf version

v2.13.4

How are you running audiobookshelf?

Debian/PPA

What OS is your Audiobookshelf server hosted from?

Linux

If the issue is being seen in the UI, what browsers are you seeing the problem on?

Chrome

Logs

No response

Additional Notes

No response

[advplyr]

Is this an m4b or an mp3 file?
You'll have to provide the file, there is not enough info to make any guesses.

[Fieldmouse88]

Its an MP3, heres the file, not the entire book but the chapter I happened to be on an experimented with.
https://www.dropbox.com/scl/fi/gcskatwxxre351yh9nwqd/19-Prey.mp3?rlkey=3ceg7layy0ofsr3vzbp8hnbx5&st=7z396cl2&dl=0
Let me know if there is anything else I can provide that would be helpful!

[advplyr]

The issue is that the audio file is encoded with Variable Bit Rate (VBR). It is recommended to use Constant Bit Rate (CBR).

Seeking isn't going to work properly with VBR mp3s. Some audio players like VLC media player will do a better job at it but the built-in browser audio player isn't going to do well.

On the android app a setting was added to enable index seeking but I don't think it works well either and it slows down playback. It is explained here https://developer.android.com/media/media3/exoplayer/troubleshooting#why-is-seeking-inaccurate-in-some-mp3-files
advplyr/audiobookshelf-app#638

I would suggest re-encoding any VBR mp3 files you have. I was able to fix that file you sent with this ffmpeg command.

ffmpeg -i '.\19 - Prey.mp3' fixed_audio.mp3

[Fieldmouse88]

Oh I see! Thank you for the quick response. While I know do understand the underlying issue with VBR, wouldnt it make for ALOT better solution if seeking was done with the same method on all platform players? I mean it doesnt really matter if the timing is off from the actual time stamp, all that matters is that its the same on all devices using audiobookshelf.
Re-encoding isnt really an option for me, and I imagine that applies to most users.
I would still call this a bug, even though there is a technical explanation for it, from a user perspective its not expected behaviour. And it seems to me like it would be resolved if seeking was done using the same method on all devices.

But hey, its still great, free and Im so glad it exists! Thankful to you advplyr, who I assume is the creator, and everyone else who has contributed in some way! =)

[advplyr]

What do you mean seeking is done the same? When playing audio in the browser you have to use the browsers audio player. That audio player isn't going to be able to seek with VBR audio files. There is not really a solution as far as I can tell unless you have some more thoughts.

I'm not sure where you are getting VBR mp3 files but it is only problematic with no benefit. I'm not sure why re-encoding wouldn't be an option. If for some reason you have many of these files you can write a few line script to loop through and fix them.