Chapters on Spotify - to kludge or not to kludge?

For podcasting, Spotify has a non-standard chapter implementation that they’ve dreamt up themselves.

Spotify don’t really care for anyone else. Their previous podcasting head, Michael Mignano, didn’t understand the technology behind RSS and thought that it wasn’t extensible, so we have the situation now that Spotify have independently reinvented the wheel for a number of core podcast implementations.

So, just as Spotify doesn’t implement video podcasting the same way as anyone else, Spotify doesn’t implement chapters the same way as everyone else.

A bit of background…

Chapters the ID3 way

Until now, podcast apps who have supported them have done chapters using ID3 tags within the MP3 file. A podcast creator uses their audio editor, or their hosting company’s interface, to define chapter points (which can include a title, a graphic file, and links); then they’re exported as part of the hidden metadata in an audio file.

This is what works in Apple Podcasts, Pocket Casts, Overcast and many other podcast apps.

There are a few issues with this approach:

• Stuffing all this data into the ID3 tag can make the audio files rather bigger, increasing data costs for the user and the podcast hosting company. Bandwidth is the main cost for a podcast hosting company.
• This additional data slows down “streamed” playback for every listener, since if you’re playing a podcast using progressive download, you have to download all this extra data before you find the audio.
• Baking in the data about chapters within the audio means that if you need to change the chapter data, you need to change the audio file.
• Browser-based players, using the standard HTML5 <audio> tag, can’t see any of the chapter data.
• Podcast directories cannot index the chapters in their databases without downloading the whole MP3.
• ID3 isn’t present in AAC audio files, which are also prevalent in podcasting. A separate method is required for producing chapter files for these services.
• The chapters cannot be created by a third party without giving them access to the main audio files.

Chapters the JSON way

The new podcast namespace defines podcast chapters as an external JSON file, referenced in the RSS feed. This fixes all the issues above - but adds a new problem: because the audio is now decoupled from the chapter file, if the audio has a variable-length dynamic ad inserted in the front, it can mean that all the chapter points are no longer synchronised with the audio.

Since the people behind the new podcast namespace are anti-advertising, this is a problem that nobody seems to want to fix; but it’s hard not to argue that JSON chapters is, currently, inappropriate for podcasters who use dynamic advertising.

Spotify’s way

Spotify supports chapters in their app if you add them into the episode description, like this:

(0:12) This is a chapter twelve seconds in
(45:12) 45 minutes after the last chapter
(46:23) And here's another chapter

This looks ugly, though is almost the same as the way as YouTube does it. If you throw your chapters into your description in this way, you’re rewarded by a clickable chapter list and chapter points within the player.

It has drawbacks:

• There are no chapter images, nor links
• It doesn’t support dynamic advertising
• It’s horribly ugly to put machine-parsable data into a humanly-readable description field

But it does mean that chapters work in the app. It’s quite a nice implementation for the user. It means that companies like Vizzy, who have worked on chapter and show note authoring software, can make their product work for Spotify, too.

The kludge

In the old days of the internet, when web browsers weren’t as standardised as they are now, we used to use the browser user-agent to give different pages to each browser. If you were using Internet Explorer, we could give you different code to if you were using Netscape or, later, Opera. This isn’t ideal - it’s a kludge that breaks caching and adds complexity. But it works.

Here’s the list of RSS user-agents; Spotify’s RSS user-agent starts just Spotify, so it’s easy to spot.

Since the Spotify RSS crawler is clearly identified, we can give Spotify a slightly different RSS feed to other apps.

So - when Spotify asks for our RSS feed, we can automatically append chapter points in the description field, as above, and by doing that, we would enable chapters within Spotify. Nobody else would see them.

Spotify is responsible for about a third of all podcast plays. This adds chapters for every listener using Spotify; and because the chapters would be derived from either the ID3 or JSON chapter data, also means that podcast creators are more likely to support chapters for the rest of us, too.

“Against open standards and rude”

Adam Curry is not entirely enamoured with this idea - to the point where he calls it “against open standards and rude”.

He’s right - at least, the “against open standards” bit. We should be putting pressure on Spotify to do this properly, to the standard everyone else uses.

Spotify doesn’t care much about standards, or about working with the rest of the industry. We should call them out.

But - listeners don’t care. If they want to use Spotify, it’s up to us to give them the very best experience.

If podcasters want to use this kludge, or podcast hosting companies want to, I think they absolutely should: because the listener comes first. Nobody else. We shouldn’t be penalising our listeners for wanting to listen in Spotify (though there’s nothing stopping us heavily promoting other, more creator-friendly, methods).

Let’s have our own robust conversations with Spotify about open standards, about collaboration, about working together to grow this medium. But let’s leave the listeners out of it.