A much more clear, consistent and readable specification for the iTunes RSS Specification is now available, dated 7/7/2005:
http://phobos.apple.com/static/iTunesRSS.html
I had a sneak preview of this the other day and it’s certainly a lot better than the last one. I’m still not entirely sure how the
<itunes :block />
Tags: iTunes, Feeder, Podcasting
Apologies for the lack of updates to the blog recently. Mostly this is because I’m busy, but also my site has been seeing a lot more traffic since the iTunes podcasting release and my server had a few creaky moments last week; I didn’t want to add the the problem.
I released Feeder 1.1.3 today. This doesn’t include the iTunes extensions and is mostly a bug fix release to clear the decks before version 1.2, which I now expect to be ready by early August. I have updated the main site to reflect this.
In the meantime, I’ve designed the interface for 1.2 and estimated how long it will take to produce and test. It won’t just be an iTunes-related release either. There are a few other things going in there that either have been requested and promised or which will make support work easier (such as an FTP log). It does mean that some of the things I’d hoped to get in there will be postponed, but that’s OK because nobody has asked for them yet.
Sam Ruby, one of the authors of FeedValidator, is threatening to throw up an Undecipherable (sic) Specification Error if the validator encounters the <itunes:block>, <itunes:image> or <itunes:link> tags.
In Feeder I will implement all tags as per the example feed shown in Apple’s specification, but there is not an example for the
<itunes :block />
…so that its presence indicates the item or feed should be blocked. It could be…
<itunes :block>Yes</itunes:block> <itunes:block>No</itunes>
…as appropriate to indicate clearly the purpose of the tag or it could be something completely different. Until we find out, the option will remain disabled in Feeder. I don’t see this as a huge problem, because most people will be using these tags so that their show can be listed nicely in the iTunes Music Store. If FeedValidator throws up that indecipherable specification error for those tags mentioned above, it probably won’t be long until things become more clear.
Note also that your feed will work without any of these tags in the iTunes Music Store, it just doesn’t look as cool.
Ah, iTunes 4.9. Of course, everyone read the announcements on my news pages, in my news RSS feed and on this blog stating that Feeder would be supporting the iTunes RSS extensions, and tons of people haven’t flooded my inbox ever since to ask if it will be implemented, when it will be implemented, if there will be a charge, etc. Yeah, right. 😉 Seeing the futility of my actions, I’ve now plastered notices around Feeder’s product pages, but I don’t hold out much hope.
Actually, it’s great to hear how many people are interested in this and now I’ve got to grapple with the rather plain specification released by Apple yesterday and translate it into a smoothy and silky user interface that doesn’t look like you have to type the same thing at least three times in three different ways.
A few opinions popped up on the web about these iTunes extensions yesterday. Dave Winer thinks it’s “funky” in that it duplicates lots of information, Edd Dumbill thinks it’s somewhat disappointing and even NetNewsWire’s Brent Simmons thinks it could be better and will be revised.
I agree, but for now, we’re stuck with it. I want to be constructive about this. Some of the tags are great and no problem at all: explicit, duration and block. I can live with the predefined categories and understand that the images need to be a different size to fit into the CD artwork style boxes in the iTunes Music Store.
The first problem is that tag names which match those in RSS make it confusing to users and annoying to differentiate in the user interface. I’ve already had a few emails about this. With that in mind, “image” would be better named “artwork” and the “category” tag would be better as “genre”.
And then there’s the whole duplication thing. In particular, we now have two more versions of description at both a channel (i.e. feed or podcast) and item (i.e. episode) level: subtitle and summary. Subtitle is a short description, must be plain text and no more than 255 characters. Summary is a longer version, also plain text and up to 4000 characters in length. The subtitle appears in the lists and the summary appears alongside the artwork and in the Info window. You can’t omit the existing RSS description field, because existing podcatchers and newsreaders use that.
I think it would have been better if they added subtitle by itself and derived the summary by stripping the HTML from the RSS description or better still by taking the HTML description as is. I suspect all this duplication is because a) the contents of your feed is going to be stored in a database and / or b) the iTMS can’t handle HTML in its existing fields. Apple normally seems really good at taking existing technology and wrapping it up in user-friendly ways so you don’t need to worry about what’s going on underneath, but in this case the inner workings of the iTMS seem to be laid bare.
I hope the spec changes and will gladly rework to the new spec. In the meantime, I’ve really got no choice but to plough on. At least with Feeder’s templates, you can choose which fields to show and omit anything you don’t need. I’m also looking at ways to reduce the amount of duplicate data entry required. More information about how iTunes handles podcasts that don’t have these tags would also be useful. I think it’s early days and this will all come good in the end!
iTunes 4.9 is out, I’ve been checking out the podcasting features and it looks great. I thought I’d post some screenshots – click the images to see full-size versions.
It all starts at the iTunes Music Store. There’s a new Podcasts genre which works much like the rest of iTMS except everything is currently free.
The new Podcast entry in the source list holds all your subscribed podcasts. The small window on top is what you see when you click on the Info button to the right of the podcast or show:
The bottom right has buttons to unsubscribe and a settings button which takes you to iTunes new Podcasts preferences. Shown here:
Finally when playing a podcast, an AAC audio file can be set up to have chapters using a new application, currently in beta, called ChapterTool – at present this is a command line tool, but (totally unsubstantiated prediction alert!) probably a sign of things to come in something like, oooh, GarageBand. Anyway, when a podcast has chapters you can navigate them using a little chapter button next to the audio display:
Finally, I mentioned in a previous post that Feeder would support the new “pod” namespace extension that Apple would release with iTunes 4.9. It turns out this is called the “itunes” namespace and has a ton of stuff in it. The information for this is available in the iTMS.
Feeder will be supporting these extra tags in Feeder 1.2, which should be out, well, as soon as it’s ready. I’ve yet to do a detailed design and estimate and I’m hoping to put some other stuff in that release too, so expect it in a month or two.
It was mentioned on Adam Curry’s Daily Source Code today that iTunes 4.9 (the one with podcasting support built in) is to introduce support for a new “pod” XML namespace to extend RSS 2.0 and add tags that will work with iTunes, including a synopsis, the option to be excluded from the iTunes Music Store, an explicit tag and more.
It sounds like iTunes 4.9 will be out within the next 2 weeks or so. The specification for this namespace hasn’t been published yet so I don’t entirely know what’s involved, but Feeder users can be sure these tags will be supported in future versions of Feeder as soon as possible.