6 ms·

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 p

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?

jsmthrowaway 10y ago
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 software that long. None of the solutions that Marco found are great, either. The solutions were dismissed decades ago in manners like this: http://www.foobar2000.org/FAQ#why_is_seeking_so_slow_while_playing_mp3_files http://www.foobar2000.org/FAQ#why_is_seeking_so_slow_while_p... Here's an example of podcasters talking each other out of AAC: http://podcastingguru.com/aac/ http://podcastingguru.com/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.
- skrause 10y ago
  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 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.
  - archagon 10y ago
    Weren't they talking about .mov files at the time?
    - danbee 10y ago
      The MP4 container was based on the Quicktime file format (.mov).
      - archagon 10y ago
        Thanks! Makes sense.
  - jsmthrowaway 10y ago
    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?
raverbashing 10y ago
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
- derefr 10y ago
  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.
  - thecosas 10y ago
    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.
    - superdaniel 10y ago
      Overcast[0], the iOS app that Marco makes supports chapters and he usually adds them when he encodes his podcast and it's pretty nice. Hopefully he releases his personal podcast production tool soon so that it can be more widely used. [0] https://appsto.re/us/jhe90.i https://appsto.re/us/jhe90.i
- mixmastamyk 10y ago
  2x playback speed helps a lot I find.
- pavel_lishin 10y ago
  Some are better than others in those regards. Most of the ones I listen to, I listen to for entertainment - so I don't mind some meandering. And decent podcast apps will give you reasonable skip options - I will frequently skip intros and outros (I'm looking at you, 99% invisible; I have never cared what your boy has to say.)
archagon 10y ago
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 10y ago
  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 10y ago
    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.)
derefr 10y ago
> I don't have a great solution to this; some kind of automatic transcription maybe? 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.
- jim-greer 10y ago
  Actually that was the original goal of Google Video, which never got much traction and was discontinued eventually. https://en.wikipedia.org/wiki/Google_Videos https://en.wikipedia.org/wiki/Google_Videos

jsmthrowaway 10y ago

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 software that long. None of the solutions that Marco found are great, either. The solutions were dismissed decades ago in manners like this: http://www.foobar2000.org/FAQ#why_is_seeking_so_slow_while_playing_mp3_files http://www.foobar2000.org/FAQ#why_is_seeking_so_slow_while_p... Here's an example of podcasters talking each other out of AAC: http://podcastingguru.com/aac/ http://podcastingguru.com/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.

skrause 10y ago
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 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.
- archagon 10y ago
  Weren't they talking about .mov files at the time?
  - danbee 10y ago
    The MP4 container was based on the Quicktime file format (.mov).
    - archagon 10y ago
      Thanks! Makes sense.
- jsmthrowaway 10y ago
  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?

raverbashing 10y ago

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

derefr 10y ago
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.
- thecosas 10y ago
  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.
  - superdaniel 10y ago
    Overcast[0], the iOS app that Marco makes supports chapters and he usually adds them when he encodes his podcast and it's pretty nice. Hopefully he releases his personal podcast production tool soon so that it can be more widely used. [0] https://appsto.re/us/jhe90.i https://appsto.re/us/jhe90.i
mixmastamyk 10y ago
2x playback speed helps a lot I find.
pavel_lishin 10y ago
Some are better than others in those regards. Most of the ones I listen to, I listen to for entertainment - so I don't mind some meandering. And decent podcast apps will give you reasonable skip options - I will frequently skip intros and outros (I'm looking at you, 99% invisible; I have never cared what your boy has to say.)

archagon 10y ago

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 10y ago
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 10y ago
  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.)

derefr 10y ago

> I don't have a great solution to this; some kind of automatic transcription maybe? 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.

jim-greer 10y ago
Actually that was the original goal of Google Video, which never got much traction and was discontinued eventually. https://en.wikipedia.org/wiki/Google_Videos https://en.wikipedia.org/wiki/Google_Videos