Hacker News Reader

Comment by pierrec | Hacker News Reader

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=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.

View on HN

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.

> 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.

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.

Reply on news.ycombinator.com