audiobookshelf
audiobookshelf copied to clipboard
[Enhancement]: Warning when Audio seeking may be incorrect
Describe the feature/enhancement
(Note: I'm limited in audio understanding)
Some mp3 files don't have a VBR header (doing mp3val file.mp3 -f will tell you ) so this affects seeking. I had this problem and for the life of me couldn't udnerstand why I couldn't jump around in my audio book correctly and thought it might be audiobookshelf being "beta" when really it was that the mp3 files were messed up.
I fixed this by converting all the files to m4a, but this was after two weeks of struggling with seeking through the audio files.
It would be great if audiobookshelf could detect this problem with files so users can be notified and go try and fix the files.
I'm not sure if this is related, but when I did ffprobe file.mp3 it also revealed: [mp3 @ 0x560fc5315400] Estimating duration from bitrate, this may be inaccurate.
This issue has come up for others as well and were a pain to troubleshoot. I think that ffprobe warning is because the audio duration wasn't specified in the metadata like it should be so it is estimating it.
I'm also limited in my understanding of audio encoding and so detecting bad encodes is probably not something I'll be getting into for now at least. Maybe someone else with more experience can pick this one up.
Ah I see. The application I used to find the problem was pretty small, would it be possibly to compile it to web assembly and then use on the server? It's called mp3val.
I don't see myself putting time into this but if it's theoretically possible to do something that simple I can look into it maybe when I'm on break in a few months if I have nothing else going on.
Maybe that's possible but I doubt it would be simple. That would also only allow us to use it on the front-end when we might want to do this check on the server side. We already have Ffmpeg/Ffprobe which is probably enough to do this check. How do you know the seeking issue was due to the VBR header?
We are moving away from ffmpeg on scans and only pulling the metadata so we won't have a way to detect this. Will not support this for now