
Why don’t podcasts use VBR MP3s? Because iOS and macOS don’t accurately seek them - okket
https://marco.org/2016/08/15/vbr-mp3-plea
======
Apreche
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 was the problem. They just complained that the file was
corrupted while it was working fine for everyone else.

Also, lots of encoders, including Adobe Audition/Adobe Media Encoder, don't
write the headers on VBR files properly. This also causes a lot of players to
fail at playing them properly.

[https://forums.adobe.com/thread/1072786](https://forums.adobe.com/thread/1072786)

When you make a podcast, maximum compatibility is the priority over audio
quality and file size. So standard old MP3 it is.

~~~
rincebrain
My favorite bug about this was on an _ancient_ MP3 player I had (an EigerMan
F20), which supported VBR MP3s...incompletely. It didn't support decoding
regions with certain bitrates, so it would just silently skip them, leading to
extreme confusion on my part.

~~~
cmdrfred
I had a similar problem and never considered that...

------
Analemma_
If you want more context to this, there's a lot more in the most recent ATP
podcast (with timestamp link included in the article).

Which kind of highlights a problem that I think is only going to grow over
time - the general greatness of podcasts has one big black spot in that
they're tough to share. I've seen so many discussions recently where there was
awesome additional context or info in a recent podcast, but it was tough to
share it with people in a format where they'd actually consume it. Whereas, if
it had been in a blog, sharing would've been easy. Marco has the right idea
with these timestamp links, but even that isn't perfect. A lot of people,
especially technical people, won't even click on a non-text source, for better
or worse.

It's a shame that a lot of good information is becoming harder to share due to
this. It's not even that podcasts are "locked down" or behind a paywall or
anything, it's just that people often don't have the time or motivation to
listen to them. I don't have a great solution to this; some kind of automatic
transcription maybe?

~~~
archagon
I just don't understand why Marco has bitten so hard into this problem. It
doesn't matter _at all_. Everybody skips the ATP theme song anyway, and VBR
will only negligibly improve quality of the rest of the show ( _as Marco
himself has pointed out_ ). And it's not like the theme song sounds bad in its
current state! I have never noticed any artifacts or flaws in the recording at
all. This is almost literally only something the ATP crew would notice.

Assuming Apple fixes this VBR problem — unlikely — it would still be a far
better idea to switch to something like AAC instead of using VBR and massively
inconveniencing a) your entire audience on older iOS versions, and b) a large
swath of your audience that uses players with equally poor VBR support. This
whole brouhaha makes absolutely no sense.

~~~
cjensen
The ATP theme song by Johnathan Mann is unexpectedly awesome, and I never ever
skip it. And as Marco pointed out in the ATP episode, this also affects any
musical interludes or short musical samples within any podcast.

~~~
archagon
Yeah, I'm sure lots of people listen to it all the way through. I did for a
while myself. But it's not worth inconveniencing so many of your listeners
just to make your theme song (or very occasional clips) sound a tiny bit
better — _especially_ considering the fact that most people listen to podcasts
in their car or even through the iPhone speaker, as Marco himself discovered
from his analytics. Others have already noted that the easy solution to this
problem exists in the form of AAC, which is supported ubiquitously at this
point. Another solution is to just use 128kbps CBR; a 1.3x size increase is
really not that big of a big deal, and 128 is transparent for many use cases.

Marco's solution is way, way out of proportion to the actual "problem". You'd
think the guy who so often kvetches about Apple prioritizing design over
function would know better than to make the same mistake!

Also: I know you don't air your dirty laundry in front of your audience, but
I'm a bit disappointed that a careful and analytical engineer like Siracusa
didn't call Marco out on this nonsense. (Especially after the
.marcosweirdformat discussion, which was downright comical given the
inconsequential nature of the problem in the first place.)

~~~
scarface74
What nonsense? He explicitly said in the episode that he studied some options
and they were all bad ideas. He made a few million from the sale of Tumblr to
Yahoo, has FU money in the bank and he is just scratching an itch and
exploring his hobby. I don't see anything wrong with that.

~~~
archagon
The nonsense is that this is a solution looking for a problem. It's scratching
an itch by trying to move a mountain. I am certain that nobody in the history
of the podcast has ever complained about the sound quality of the theme song
or audio clips, especially after they switched over to 96kbps. Whereas there
is no doubt that any technical solution — especially any of the ones proposed,
including switching to VBR — would inconvenience a whole lot of people.

(By all means, Marco should continue working in this direction if it interests
him. If Apple ends up adding those ID3 tags to their MP3 decoder, it will have
a net positive impact on the world. I just think it's a rather foolish
endeavor.)

~~~
danseely
>I am certain that nobody in the history of the podcast has ever complained
about the sound quality of the theme song or audio clips, especially after
they switched over to 96kbps.

Source?

>Whereas there is no doubt that any technical solution — especially any of the
ones proposed, including switching to VBR — would inconvenience a whole lot of
people.

It sounded to me like the entire point of his approach is to find a technical
solution _without_ inconveniencing people.

------
kalleboo
That's MP3s. AAC/MP4 has better efficiency, and I can't imagine any devices in
2016 don't support it...?

~~~
colejohnson66
If only OGG support was more common :(

~~~
DarkLinkXXXX
Opus if the free software lossy codec of choice now, I think. It can be put in
an ogg container though.

~~~
TD-Linux
Yup, .opus files are the Ogg container. While Opus is newer, both Opus and
Vorbis are much better than MP3.

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

------
zymhan
So is this why I have weird problems fast-forwarding through some NPR
podcasts? I'll find myself at the end of the podcast (as indicated by the time
bar), but the podcast itself is still playing.

Man, Apple really is neglecting podcasts. Reminds of an article I read
recently - "Podcasts Surge, but Producers Fear Apple Isn’t Listening"

[http://www.nytimes.com/2016/05/08/business/media/podcasts-
su...](http://www.nytimes.com/2016/05/08/business/media/podcasts-surge-
apple.html)

~~~
colejohnson66
It's not Apple's fault; It's MP3 in general. Seeking in VBR MP3s is hard
unless you decode the whole file and make note of the offsets for timing.

~~~
derefr
And decoding the whole file, in turn, would be easy in any other use-case
(iTunes does this for "gapless playback" calculation) but podcasts are quite
often streamed, and only once.

Probably the simplest "clever hack", if Apple wanted to fix this on their own,
would be for all the podcast feeds registered through iTMS to get their files
retrieved by the iTMS servers once, chewed through to calculate this
information, and then all the calculated "keyframe" offsets injected as an
opaque extra data field for each feed item of the iTMS-served podcast feed,
where the Podcasts app can pick it up.

------
ksec
Not a fans of VBR MP3. VBR is great. But as some has shared maximum
compatibility is much more important. Let's do some maths ( Correct me if I am
wrong )

At 128Kbps that is 1MB per minutes, an hour would means 60MB. Since most
podcast uses 64Kbps we are talking about 30Mb, a saving of 20% means 6MB per
client, 10,000 listeners saves you 60GB per episode, assuming a Weekly
episode, that is 240GB....... on an 2015 Est of ATP listeners around 80,000,
that is ~ 2TB of Transfer. That is the transfer a $10 Linode would give you.

So is it really worth the risk of VBR concern on a little saving worth $10 to
$20?

Since i didn't exactly listen to the podcast, I wonder what problem does he
has with AAC. Because the argument about most having a newer devices with
proper support for VBR MP3 also works for AAC. And AAC sounds A LOT better.

~~~
et-al
You raise a good point, but if you're ever in a place with a shoddy internet
connection, you appreciate optimized filesizes.

------
CamperBob2
Not a fan of VBR MP3 files in general. They're more complicated to deal with
when writing a codec, due in no small part to the seeking problem. And VBR is
one of those optimizations that only works on things that didn't need
optimizing in the first place (i.e., low-entropy frames.) There's just not
much point to it.

If you need VBR MP3 for some reason, chances are you really need a better
format.

------
TazeTSchnitzel
Oh, that explains why when I pause music on my iPhone and resume, it doesn't
continue playing from the same place.

Damnit, Apple.

------
anonova
How does one actually see the bug report? What is `rdar://27848317` supposed
to open?

~~~
yoda_sl
This in reference to Apple internal bug tracking system named "Radar", the
number listed here is the bug ID and only Apple folks and probably the person
that created that bug in the Radar system can see it

------
mikey_p
I assume this is the same problem I see in my car (VW) when streaming Spotify
via Bluetooth? The progress bar in the car seems to go at double speed and
runs out about halfway through each track.

~~~
mattdonders
I thought so too but it's actually a bug in the radio itself (if you're
driving a MK6).

You can go to the dealer and reference Technical Service Bulletin (TSB)
91-13-03 and they'll do a software update to fix it.

\--- There's another bug in that radio but I won't tell you until after you
see if you want to get it fixed because its really annoying.

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

------
caiob
> VBR encoding is far more space-efficient and better-sounding than constant-
> bitrate (CBR) encoding

While this may be true for podcasts, it's def false for music files.

~~~
hyperbovine
How so? Any VBR encoder could choose to produce CBR at the targeted average
bitrate. The fact that it doesn't means that there is some better setting in
terms of either space or quality.

