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

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.

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

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

"a 1.3x size increase is really not that big of a big deal" - you say this about Marco "All my image resources are vectors so the OverCast App is 5 Megabytes large" Arment? For the same reason that UTF-8 is awesome, VBR podcasts are likewise a perfect system, presuming we can get over the chapter marking hurdles.

Not vector, but drawn by code.

I've always divided 2D graphics of the kind you see in Apps (let's ignore 3D Graphics cards with shaders/textures/etc.. for a bit) into two categories - bitmap and vector graphics. Bitmap is pretty straighforward, and vector graphics (googling for a second) is "...the use of geometrical primitives such as points, lines, curves, and shapes or polygons" - which presumably Marco is doing to keep his app size so small?