4 ms·

There are many degrees of VBR MP3 seeking support, and it's often surprisingly bad. In the case of Firefox's <audio> element, it was very poor (nearly unusable

by pierrec 10y ago

There are many degrees of VBR MP3 seeking support, and it's often surprisingly bad. In the case of Firefox's <audio> element, it was very poor (nearly unusable in my testing) until a few months ago: https://bugzilla.mozilla.org/show_bug.cgi?id=994561 https://bugzilla.mozilla.org/show_bug.cgi?id=994561 https://bugzilla.mozilla.org/show_bug.cgi?id=1163667 https://bugzilla.mozilla.org/show_bug.cgi?id=1163667 I had a fun time testing different js audio players, and going though their many confused bug reports, issues and threads all stemming from this. Even if Apple fixes their stuff, I still wouldn't use VBR MP3 for anything that's going to get streamed. There's always going to be some platforms that screw it up, and even a future browser introducing poor seeking seems very possible.

eamsen 10y ago
You're correct about that there are different degrees of seeking support. Seeking VBR MP3 with perfect accuracy is trivial by forward-reading. However, this is obviously highly inefficient on long duration seeks. For instant seeking support, you need to (partly) depend on the optional VBR headers. This comes with its own set of issues, e.g., the most commonly used Xing header contains only 100 seek table entries, which may not provide enough resolution for large files. I'm still surprised about the complete lack of support for those headers in AVFoundation, since I would consider it a low-hanging fruit in terms of improving usability for the majority of use cases (excluding pod casts). Disclaimer: I've worked on MP3TrackDemuxer for Gecko/Firefox.
- Analemma_ 10y ago
  > However, this is obviously highly inefficient on long duration seeks. Is it that bad? On the podcast, Marco claimed that seeking forward through an MP3 to find the correct time is pretty efficient, and that the reason for all this trouble is that streaming (specifically, requesting the correct byte offset from the server, if you want to jump to a specific time on the stream) is the problem he's trying to tackle here. He said that if it weren't for the streaming use case, he'd be fine with forward-reading.
  - MBCook 10y ago
    He did say it wasn't an issue for downloaded files. For streaming I believe he said you only get eight bits, which over a two hour podcast is about 30 seconds of precision. Then of course the podcast sometimes goes longer, not to mention how long Gruber's podcast goes. Sounds like Matco is right it would work well for a 3 minute song but not s multi-hour podcast.

by pierrec 10y ago

eamsen 10y ago

You're correct about that there are different degrees of seeking support. Seeking VBR MP3 with perfect accuracy is trivial by forward-reading. However, this is obviously highly inefficient on long duration seeks. For instant seeking support, you need to (partly) depend on the optional VBR headers. This comes with its own set of issues, e.g., the most commonly used Xing header contains only 100 seek table entries, which may not provide enough resolution for large files. I'm still surprised about the complete lack of support for those headers in AVFoundation, since I would consider it a low-hanging fruit in terms of improving usability for the majority of use cases (excluding pod casts). Disclaimer: I've worked on MP3TrackDemuxer for Gecko/Firefox.

Analemma_ 10y ago
> However, this is obviously highly inefficient on long duration seeks. Is it that bad? On the podcast, Marco claimed that seeking forward through an MP3 to find the correct time is pretty efficient, and that the reason for all this trouble is that streaming (specifically, requesting the correct byte offset from the server, if you want to jump to a specific time on the stream) is the problem he's trying to tackle here. He said that if it weren't for the streaming use case, he'd be fine with forward-reading.
- MBCook 10y ago
  He did say it wasn't an issue for downloaded files. For streaming I believe he said you only get eight bits, which over a two hour podcast is about 30 seconds of precision. Then of course the podcast sometimes goes longer, not to mention how long Gruber's podcast goes. Sounds like Matco is right it would work well for a 3 minute song but not s multi-hour podcast.