Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Why don’t podcasts use VBR MP3s? Because iOS and macOS don’t accurately seek them

marco.org

Post reply on HN
Print view View original

41–50 of 90 posts

Re: Why don’t podcasts use VBR MP3s? Because iOS and macOS don’t accurately seek them

#41

Post by [deleted] »

archagon wrote: post #28
mwfunk wrote: post #27

Earlier quoted context omitted.

It sounds like he got into it because it piqued his interest so he did a deep dive on the subject. Nothing wrong with that. I will get frustrated with people sometimes for not doing things that they ought to be doing, but I would never sh*t on someone for following their bliss and spending their hobby time on things I personally am not interested in. If this pisses you off then I can't imagine what sort of vitriol yo…

When your solution to an incredibly minor and easily-solvable problem is to ask people to bug Apple engineers about adding new features to a decade-old encoder, maybe you're on the wrong track. I'm frustrated by Marco's extreme fussiness, not his curiosity. (And there's no doubt his curiosity often leads to interesting places. I learned some great tidbits about MP3 encoding in the last few episodes!)

[deleted]

Re: Why don’t podcasts use VBR MP3s? Because iOS and macOS don’t accurately seek them

#43

Post by GavinMcG »

aianus wrote: post #26
drzaiusapelord wrote: post #17

Earlier quoted context omitted.

VBR have been the red-headed step-child of MP3 since the beginning. I have no idea why, maybe it was difficult to write good encoders and decoders for it for back in the day. The few times I used them, I found trivial space savings compared to a CBR and to be honest I thought I could hear a difference (maybe its not humanly possible if the implementation of the encoder/decoder is good but what if the implementation i…

iPhone storage and cellular bandwidth are still extremely expensive. Over $100 for a measly 16gb of storage or 4gb of LTE.

Is 16GB really that measly when it comes to podcasts? Even at, say, 128MB per hour (!) you've got over 100 hours of capacity there. Enough for a full waking week, nonstop.

Re: Why don’t podcasts use VBR MP3s? Because iOS and macOS don’t accurately seek them

#44

Post by eamsen »

pierrec wrote: post #29

There are many degrees of VBR MP3 seeking support, and it's often surprisingly bad. In the case of Firefox's 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 al…

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.

Re: Why don’t podcasts use VBR MP3s? Because iOS and macOS don’t accurately seek them

#45

Post by jsmthrowaway »

skrause wrote: post #30
jsmthrowaway wrote: post #5

Earlier quoted context omitted.

The solution is AAC, regarding which a number of prominent podcasters introduced FUD several years ago and now the podcasting industry is reluctant to give up MP3 -- unlike pretty much every other audio-related industry in the world. Seriously, MP3 was on its way out the year the Backstreet Boys released that song, and it surprises me that people still stick to it despite the VBR thing being a shitty problem in softw…

The problem with AAC is in the container format, as Marco explains in his podcast: While some important metadata like chapter marks which a podcast player might want to display are within the first KB in an MP3 file, this same information is interleaved somewhere in the stream in AAC. Which means that you can't have all features when streaming an AAC file, in a time when streaming podcasts is getting more popular eve…

Those are all problems with a specific, objectively crappy container, as you've noted. There are many alternative containers and no reason the podcasting community couldn't come up with its own, such as by extending Matroska. This obviously creates separate problems, but I'd like to see the podcasting community start to shape its own destiny a bit rather than expect others to innovate for them or kludge older formats to do things they weren't supposed to do.

Why not a podcasting specific container that handles streaming and fixed cases, includes support for all the novel stuff podcasters want to do, and so on? Container development is one of the easier parts of multimedia, and there's too much thinking around a specific codec being tied to a specific container (just like your comment). Legacy support is of course the big elephant in the room, but I'd venture a well-founded guess that the average podcast listener is listening on a device that supports apps. (Maybe I'm wrong.)

I can't think of a single good container format. They're all rubbish. Even Matroska is arcane and very poorly documented, and suffers from the end goals and types of media it is used for being encoded in the design. Containers are a giant space in which to innovate and have been that way for years. Unfortunately, open source multimedia development is largely tied up by a certain group of people with a certain background and very specific use cases in mind.

That context from the podcast would have been awesome in this piece. Why wasn't it there?

Re: Why don’t podcasts use VBR MP3s? Because iOS and macOS don’t accurately seek them

#46

Post by thecosas »

derefr wrote: post #23
raverbashing wrote: post #11

Earlier quoted context omitted.

I like podcasts, but they're unnerving to me. It's too much time wasted to get to the point. And as opposed to music, I can't program properly when listening to them Not to mention a lot of podcasters act in a radio way (which make sense for radio), with repetitions, talking slowly, endless introductions, chit chat, etc

The "radio stuff" isn't nearly as much of an irritant if you're listening to a podcast while commuting. It's still kind of grating when you listen to a whole bunch of episodes of something in a row, though. There needs to be markers in the files and software that can cut off the intro/ending of the "internal" episodes in a playlist. Like a much more drastic version of gapless playback.

Chapter markers are a potential solution IF podcast producers use them and mark them accurately and IF your podcast player of choice supports Chapter markers.

Re: Why don’t podcasts use VBR MP3s? Because iOS and macOS don’t accurately seek them

#47

Post by coob »

Apreche wrote: post #7

That's not the only reason. We have been podcasting for over 10 years, and early on we tried to use VBR MP3s because we are teach people who know about that sort of thing. As it turns out, not everyone is listening using a modern device. When we tried VBR a significant number of people could not listen because their MP3 playing hardware/software of choice did not support VBR files properly. They didn't realize this w…

Marco and the others mentioned this on the example podcast episode (linked from he article).

Hardware support for VBR is pretty decent now.

Re: Why don’t podcasts use VBR MP3s? Because iOS and macOS don’t accurately seek them

#48

Post by pbreit »

Apreche wrote: post #7

That's not the only reason. We have been podcasting for over 10 years, and early on we tried to use VBR MP3s because we are teach people who know about that sort of thing. As it turns out, not everyone is listening using a modern device. When we tried VBR a significant number of people could not listen because their MP3 playing hardware/software of choice did not support VBR files properly. They didn't realize this w…

And audio data is relatively small that the savings aren't that valuable.

Re: Why don’t podcasts use VBR MP3s? Because iOS and macOS don’t accurately seek them

#49

Post by tombert »

I actually didn't know that MP3s had a VBR option...I guess this shows how uncommon it is.

I use VBR Ogg whenever I can, and I always thought it was weird that MP3 didn't have support for that feature. I guess I was (as always) a bit ignorant :D.

Re: Why don’t podcasts use VBR MP3s? Because iOS and macOS don’t accurately seek them

#50

Post by TD-Linux »

jsmthrowaway wrote: post #45
skrause wrote: post #30

Earlier quoted context omitted.

The problem with AAC is in the container format, as Marco explains in his podcast: While some important metadata like chapter marks which a podcast player might want to display are within the first KB in an MP3 file, this same information is interleaved somewhere in the stream in AAC. Which means that you can't have all features when streaming an AAC file, in a time when streaming podcasts is getting more popular eve…

Those are all problems with a specific, objectively crappy container, as you've noted. There are many alternative containers and no reason the podcasting community couldn't come up with its own, such as by extending Matroska. This obviously creates separate problems, but I'd like to see the podcasting community start to shape its own destiny a bit rather than expect others to innovate for them or kludge older formats…

One of the OP's requirements is that this work in iTunes, which precludes making a new container format.

I also think existing containers would meet the requirements - for example, Ogg meets the requirement of both being storable and easily streamable. Also, the Matroska spec is being updated to a new version, and being standardized in the IETF CELLAR working group. I'd highly suggest participating if you'd like to help improve both the format and the specification.

Post reply on HN