I am able to publish a direct link to the worst song ever because Jay Fienberg used an interesting new method to assemble the podcast in which I discovered this very bad song.

Podcasts are, by convention, one long file made up of multiple distinct segments. It is the file as a whole that has a URI, rather than the segments. If the segments had URIs of their own they could be bookmarked, linked, and cached. A highfalutin way to say that this would be good is that An important principle of Web architecture is that all important resources be identifiable by URI.

Jon Udell has addressed this issue several times. In O'Reilly Network -- MP3 Sound Bites, for example, he describes the problem as:

Until and unless we achieve a radical breakthrough in speech-to-text translation--and I'm not holding my breath--we'll need to find another way to make audio content more granular, and easier to consume selectively.

Jon's solution is to define a new URI syntax which allows you to link into an audio or video file. HTML does something comparable by supporting the idea of fragment identifiers. Fragment identifiers are sub-addresses within a document using the syntax http://example.com/thedocument#fragment. For example, this link to the last paragraph of this document relies on the fragment identifier #lastparagraph.

The problem with that approach is that it requires a new internet standard (since the meaning of a fragment identifier must be specified as part of the MIME type for a file format), and this standard must be implemented by many different software developers. This is not doable; I know that because we have tried and failed a very similar angle within the XSPF group. Standards are insanely hard to pull off.

Playlistcasting

A different way to approach the problem is to use playlists.

When a podcaster was putting together their presentation, they would break up the larger document into smaller ones, for example a spoken introduction, a song, an interview, another song, and a spoken conclusion. Rather than concatenating these into one big audio file, the podcaster would leave each part as a separate file. They would put the files up on a web server, then write a simple playlist pointing to each of the files in sequence. Lastly, the podcast client would render the playlist.

And that's just what Jay Fienberg did with his podcast, which looks like this:

Wrong Notes Podcast #02

1. Talking: Introduction [1:16]
2. Music: Spy? Music (new, for Wrong Notes) [1:45]
3. Talking: A Little History [0:46]
4. Music: New Dawn Coming, by The Light [3:32]
5. Talking: Segue into Dark Is The Night [0:48]
6. Music: Dark Is The Night, by The Light (The Worst Song Ever) [7:38]
7. Talking: Conversation with Dean Fienberg [7:42]
8. Music: Nostalogia (new, for Wrong Notes) [1:38]
9. Talking: Colophon [0:24]

Or, play it all now! Here!

(If you're reading this in a tool which strips out embeds, like Bloglines, you're not seeing the embedded player for the playlist in the above text. You might want to check out this blog entry in its original browser form to get a feel for it, including the extremely cool and immediately useful feature that you can skip around within the podcast if you right click on the player).

This may be crude, but it works. There is no audible difference between this method and the conventional one, yet it enables linking and bookmarking within a podcast.

A necessary workaround

Ahem. Sort of. There's a catch -- you'd need support from podcast clients. Many of them would need to be enhanced to support playlist formats, and avoiding this overhead is exactly what this approach is supposed to avoid. To work around that problem the podcast would need to be published in two forms, the monolithic audio file and the separate segments.

<enclosure
   url="http://earreverends.com/podcast/02/ear_reverends_podcast_02_all.mp3"
   length="30506007"
   type="audio/mpegurl" />

Jay has a telling mistake in his RSS -- he uses the MIME type for an M3U file, though the file itself is an MP3, which has a different MIME type. That comes out in the wash because the web server returns the proper MIME type, but some podcasting clients will refuse to handle his podcast precisely because they don't support playlist formats.

You might say that this is not really a playlist, just a list of links in the HTML of the blog entry and a separate enclosure containing a single file. That's an overly limited view of what a playlist is, though. Any list of audio or video links is a playlist. In this case the playlist format just happens to be HTML.

How-to

1. Break your podcast up into logical chunks. These should correspond to sections that make sense and that people might want to access in isolation. For example, if people might want to skip over the weather report and go straight to the sports segment, then give sports its own segment.
2. Publish each chunk as a separate file. In your HTML make a separate link to each one. For example:

         <a href="chunk1.ogg">top news</a>
         <a href="chunk2.ogg">local news</a>
         <a href="chunk3.ogg">weather</a>
         <a href="chunk4.ogg">sports</a>
         <a href="chunk5.ogg">say goodnight</a>
       

3. Publish the original monolithic podcast as a single file. Link to this in the RSS enclosure.

   (On a personal level it pains me to not recommend that you link to an XSPF file in the RSS enclosure, but I can't do that until podcasting clients support XSPF, if ever).

4. Embed a player in your web page.
5. If you want to allow users to skip around within the player, which seems like a big win to meq:
   1. Use an embedded player that supports playlists and makes it easy to skip from one track to the next. Music Player Extended mode is one possibility.
   2. Create a playlist of your segments. If you are using an XSPF player, the XSPF quick start instructions may be helpful.
   You can also use Webjay to create a playlist and embed a player.

Purple numbers

As with most interesting things related to contemporary technology, Doug Englebart has been here before, in this case with a concept called Purple Numbers. There is a bastardized but simplified version of Englebart's vision by Eugene Eric Kim. There is related discussion on Tim Bray's blog. Mark Nottingham argues that addresses within a document that aren't linked to the semantics of a document can lead to brittleness and loss of utility. Mark's argument, if you buy it, suggests that Jon's time-based clipping would be improved by having clips be defined by the podcast creator, as Jay's method does.

Purple podcasting would have benefits for the web as a whole. Because of the ability to use fragment identifiers within HTML, third parties are able to annotate web pages published elsewhere. Similarly, this method would allow third parties to talk back to, elaborate on, or otherwise respond to audio and video files. They might even post their responses in audio or video, and these responses themselves might contain addressable fragments. Taken together these documents would constitute a new web of interlinked audio and video.