Jay Fieberg emailed these comments on my purple podcasting blog entry.

Wrong Notes started before podcasting was called podcasting, and also before XSPF had been spec'd sufficiently and implemented. My original idea was that, since I want to post bunch of audio via a blog, I want to support both the audio / playlist and the blog / feed interactions. So, I've always posted m3u playlists, and entries in my original RSS feed had enclosure elements that pointed to m3u playlists.

Each m3u playlist then listed one or more mp3s. As the author of the site, I am authoring blog entries that point to playlists of audio. And, technically (spec-wise), there is no constraint that prevents the RSS enclosure element from being used in this way.

But, with the rise of podcasting, I basically felt obliged to change my RSS to match the de facto standard for enclosures, which is a single mp3 file. I at first held out for a good while, and campaigned for playlist support in various podcast tools, but by the time iTunes became a dominant podcast client, I couldn't hold out any longer.

So, the MIME type error in my RSS feed that you mention, where I use type="audio/mpegurl" instead of type="audio/mpeg" is due to the legacy of my enclosures being m3u. When I changed it all over to use mp3s, I obviously missed the MIME type. (Thanks for catching that--I'll fix it next time I do a post. Actually, there are several other legacy issues around my original use of m3u, and I won't get to clear them up until I launch a whole new site later in the year.)

In terms of my current process, I create my audio segments as separate segments from the start. They are naturally separate in one way or another, e.g., talking about a song is separate from the song, and one song is separate from another song, etc. With the interviews I've done, I'm already editing down longer conversations into shorter and more focused discussion, so it's also very natural to break up talking segments. And, as a musician, I see these breaks in talking segments as natural places to introduce new musical interludes (which, of course, then are their own segments).

My final podcast publishing process involves:

1. producing individual WAVs (for archiving, etc.)
2. merging all of the WAVs into a single file
3. converting all of the WAVs into mp3s
4. creating a XSPF playlist listing all of the mp3s
5. creating an HTML list listing all of the mp3s (inline in the blog entry)
6. create an HTML reference to the XSPF music player and the XSPF playlist (inline in the blog entry)
7. create an RSS enclosure reference to the merged mp3 file

It should be relatively trivial to write a script that takes a directory of WAV files (my step 1) and does the rest (steps 2 -7). I am still doing all of this "by hand" (which is part of the reason I post so infrequently), but, to me, it's one right model for publishing music audio in a blog, and it's just screaming for some computer tool support. I think this model would naturally translate to video, as well.

Of course, were it up to me, I'd eliminate the "one big file" requirement--what a waste! We still need podcast clients to support playlists--now, with XSPF as a standard that is widely adopted, it should be a no-brainer!

And, a bigger philosophical issue: the most successfully marketed new formats, like podcastized RSS, tend to find a middle ground between meeting some of people's needs and totally discouraging any similar formats that could meet other of people's needs. What do you do when you are one of the others / have other needs?