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.
When you make a podcast, maximum compatibility is the priority over audio quality and file size. So standard old MP3 it is.
Interesting how the incentives can be different. Stuck without proper broadband and paying for all the precious MBs for a few weeks I made a proxy for downloading/recoding podcasts as VBR on external server to save my data...
How are we defining modern here?
I'm pretty certain my Nomad Jukebox 3 supported VBRs fine, and that's coming up on 14 years old now.
Hardware support for VBR is pretty decent now.
A single episode of a podcast may be an hour and a half. If you are subscribed to 5 weekly podcasts, then that's about 1GB of data you'll need. If you're going on a long trip, maybe you stock up. That might take 3GB or 4GB... But that probably won't fit on your phone. It certainly doesn't fit on mine.
...is "don't use an iPhone until they start adding microSDs to their phones and don't stream" too obvious or am I missing something here?
Then add in all the gaps in people's speech where you need almost no data and he said he got pretty good savings.
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?
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
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.
This was the original goal of YouTube, as a project: automatic video transcription to enable better accessibility and indexibility for audio/video. It's theoretically in there, but it doesn't do well at all. I'm honestly surprised it doesn't do better, given the Google Voice dataset that's likely backing it.
Here's an example of podcasters talking each other out of AAC:
His is not the first article I've read conflating "AAC" with some kind of "Enhanced Podcast" buzzword and then dismissing it based on the flaws of "Enhanced Podcasting." I left the radio industry in 2006 and we'd already transitioned all in-house production and delivery away from MP3 then. Probably 50% of the spots we received from external shops in 2006 were MP3.
At some point you have to sit down with your listener and say that MP3 player you bought at Target in 2001 is holding us back, man. Marco is wrong on this one: it's AAC that would deliver all the good things that he wants, not VBR MP3. Fun fact: all AAC is VBR, in a manner of speaking, and it's way better than the hack that is VBR MP3s.
Which means that you can't have all features when streaming an AAC file, in a time when streaming podcasts is getting more popular every day. You first have to download the whole file before you can display e.g. chapter information.
Of course you could just embed that information in the RSS feed, but you could do the same with jump tables for VBR MP3s. So AAC does not solve all your problems, you just get a different set of problems.
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?
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.
Matroska draft: https://datatracker.ietf.org/doc/draft-lhomme-cellar-matrosk...
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.
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.)
(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.)
>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.
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!)
What solution is that which he didn't mention? He mentioned AAC, custom formats, just do it and ignore the share link issues (LOVE the share links).
Less seriously, why would you skip over the song? - it's a lovely little song and my only problem with it is that it's an earworm that I find myself internally singing all the time. "John didn't do any research .... da da da". Of course John always does some research anyway. Now if only John would occasionally concede a point or give the other two some credit, maybe just once, life would be perfect.
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.
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.
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.
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.
Man, Apple really is neglecting podcasts. Reminds of an article I read recently - "Podcasts Surge, but Producers Fear Apple Isn’t Listening"
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.
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.
If you need VBR MP3 for some reason, chances are you really need a better format.
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.
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.
While this may be true for podcasts, it's def false for music files.
BTW, if you're going to claim any mp3 encoding is better sounding than another one, I hope you've done an ABX test.