Podcasting & ID3 Tags

Improper naming conventions unsafe ID3 tagging or no ID3 tagging of your PODCAST can lead to confused listeners, iPods with Podcast Clutter and most of all "upset" listeners.

Here is an example of the causes of unsafe ID3 Tagging : As you can see, in the photo below:

This unfortunate driver met disaster due to an irresponsible Podcast Author, whom did not practice Safe ID3 Tagging. Thusly, the drive was futzing around with his MP3 player whilst driving down the road.

SO REMEBER PROPER ID3 TAGS SAVE LIVES!! Or well cars & telepoles anyway!!

When delivering your Podcast to your listening audience editing the MP3 ID3 Tags properly to identify your Podcast is more than just important! ID3 Proper tagging helps listeners sort their podcasts correctly.

If you have iShuffle, I set the playlist to PODCAST GENRE and load my podcasts from this playlist. This provides a great method, EXPSECIALLY if you can group all podcasts by the GENRE!!

Attention to ID3 Tags ie: the NAME TAG: alone will avoid a similar “Track 1” display issue, which is a different techinal result than the Mercedes example, but nonetheless the end result is "WHAT THE HELL IS THIS TRACK CALLED?" The point, convey accurate information about your content to the listeners. If you produce a Podcast, its about your listeners....Right!?!

Categorizing these shows can easily be handled by current steadfast techniques employed in the publishing world today. Deviating from these standards just to deviate, seeking new for the sake of new may not be a valid platform to base a standard. The categorizing standards from the publishing world, library of congress and other sources through the music world including ID3 tagging makes conveying this information very easy for Podcast producers. These organizations do a fine job and we can “reuse” their work and get this effort kicked off faster from their experience than developing a new one.

Googling (if that’s a word) for a good description of ID3 Tags is seen at RadioBlogWare. Immediately reading through the comments on this site the issue of Genre is discussed as a problematic tag. If every Podcaster set the GENRE to Podcast... The grouping of all Podcasts would be simple for many savvy users and novices alike.

Simply put, ID3 tags are important in terms of documenting podcasts for archival, search and release purposes which directly effect how your listeners interact with your podcast. Remember is about your listeners!!

What are the components of an MP3 file in terms of ID3 tag information? How does iTunes display this ID3 tag information? Well, lets export my iTunes library to an XML File:

 XML Export : If you would like to Export your library follow the simple instructions below:

1. Got to the File Menu and Select Export Library
2. A Save As dialog requests folder location with a filename of Library.xml as a default
3. Click the save button.

I have edited the the library file to include one song Peter Gabriel’s “Shaking the Tree” and one Podcast Adam Curry’s June 9^th’s Podcast

What we would like to accomplish is to identify an accurate and descriptive naming convention for ID3 Tags from iTunes as the source. Since this the fields are already defined then lets just take what we have below and insure our Podcasts match this criteria…Thusly, making Mr. Curry Happy!

This information below is an XML header and I put it in here so you can see it raw. Just ignore it for now, if you have questions hit me with some comments here at zapcasater@gmail.com.

<?xml version="1.0" encoding="UTF-8"?>

<!DOCTYPE plist PUBLIC "-//Apple Computer//DTD PLIST 1.0//EN"
"http://www.apple.com/DTDs/PropertyList-1.0.dtd">

<plist version="1.0">

The information below identifies iTunes versions, Music folder (raw MP3/AAC/WAV/etc files) Then come the tracks grouped by the <dict> tag.

<dict>

 <key>Major Version</key><integer>1</integer>

 <key>Minor Version</key><integer>1</integer>

 <key>Application Version</key><string>4.8</string>

 <key>Music Folder</key><string>file://localhost/z:/OffLineStorage/iTunes/</string>

 <key>Library Persistent ID</key><string>C0CB4DEBC293FBA3</string>

 <key>Tracks</key>

Shhhhhhheeeeeezzzzzzzzzzzzzzzz,that’s over lets get to Peter’s Song.

As you can see below, there are tags named a track id, Name, artist, genre etc… A Podcast has some issues that we should consider, in terms of tags… The simple tags Name, Artist, size, total time, etc… should be straightforward, the highlighted in red below are clean for an album, however, they too have some issues in podcasting.  

The XML for a song is below:

 <dict>

 <key>Track ID</key><integer>296</integer>

 <key>Name</key><string>Shaking The Tree</string>

 <key>Artist</key><string>Peter Gabriel</string>

 <key>Composer</key><string>Peter Gabriel</string>

 <key>Album</key><string>Secret World Live (Disc 1)</string>

 <key>Genre</key><string>Rock</string>

 <key>Kind</key><string>AAC audio file</string>

 <key>Size</key><integer>9038763</integer>

 <key>Total Time</key><integer>558416</integer>

 <key>Disc Number</key><integer>1</integer>

 <key>Disc Count</key><integer>2</integer>

 <key>Track Number</key><integer>5</integer>

 <key>Track Count</key><integer>10</integer>

 <key>Year</key><integer>1994</integer>

 <key>Date Modified</key><date>2005-03-26T08:40:08Z</date>

 <key>Date Added</key><date>2005-03-27T01:29:59Z</date>

 <key>Bit Rate</key><integer>128</integer>

 <key>Sample Rate</key><integer>44100</integer>

 <key>Normalization</key><integer>1670</integer>

 <key>Track Type</key><string>File</string>

 <key>Location</key><string>
file://localhost/z:/OffLineStorage/iTunes/Peter%20Gabriel
/Secret%20World%20Live%20(Disc%201)/1-05%20Shaking%20The%20Tree.m4a/</string>

 <key>File Folder Count</key><integer>4</integer>

 <key>Library Folder Count</key><integer>1</integer>

 </dict>

As you can see Genre is a huge issue for podcasting, because this topic just expands endlessly and covers anything and everything a podcaster can Podcast. However, it really reeks havoc on the rest of your music library/files etc. This is a huge issue, which we can be addressed in the short term by simply entering "Podcast" in the Genre, more on this later.

looking at the other tags such as the disc number which is a remnant, of course, from CDs/Albums as does the disc count, track number and track count. Of course, these are integers and currently in most cd players digest them well. These tags can be problematic, however the TRACK NUMBER can be used as an Episode number. So, for example if you have a show a day, and its late December (of course you start Podcasting Jan 1) then for episode 354 would be placed in the track number. Pretty good use for this tag. The other tags, for now can be ignored with out to much repercussion, if any.

A simple explanation for each tag below is in order and should not be overcomplicated and rather simple. The goal is to get the listener and devices the accurate and informative data in the ID3 tags to convey the shows description.

We will start with comparing Adam’s XML with Peter’s. Adam’s XML is below for the “Daily Source Code”. Since we are working from the clients perspective the RSS format is taken as a second consideration later in the document. This XML IS NOT an RSS.XML compliant feed, though, iPodder directly maps the RSS.XML to the iTunes XML. I am sure as Apple integrates podcasting into iTunes v4.9 we will see a heavier marriage of RSS.XML to Apple’s internal representation. This could be the momentum we need to drive a standard! 

The most important item one should pay attention to in terms of ID3 Tagging is “BE CONSISTENT”. It appears, to me Adam has been fairly consistent for podcasting < than a year and I give him a lot of credit for this and also how he structures his information so lets look at this field-by-field.

Track Number : Is for Apple’s use and for now we can ignore this tag.

Name tag : Adam’s naming convention is the Show Name Initials, Year, Month, and Day.

Name tag : Adam’s naming convention is the Show Name Initials, Year, Month, and Day.

The Show Initials are limiting if one restricts themselves to the chars.

A good file name is descriptive. If you did not know who Adam Curry was or that his show is the "Daily Source Code", this name would be worthless to you!! Therefore, remember to be descriptive!! Being descriptive on your 60 Gigabyte iPod is not going to waste any space at all. Hence, there has been 63,072,000,000 seconds since the birth of Christ, roughly, give or take a couple of million seconds. I am sure description is not an issue...

So, to convey this in terms of an example acceptable names for Adam’s \Podcast of 6/9/2005 could be:

 DailySourceCode-2005-06-09.mp3.
DailySourceCodeWithAdamCurry-2005-06-09.mp3. (tad redundant, but you get the picture)

Artist : Of course in Peter’s and Adam’s case this is the same and should be used as conventional wisdom dictates

Album : Daily Source Code, well is this really an album no, however, within an MP3 player the top description of what is playing lists the Name, Artist and Album. 

These three  tags (Artist, Album and Name)are user centric and must be very descriptive with consistency in mind.

With the above being said, the Name Tag can be show tag name, for example:

1. Car Transmissions

2. Allstart Game 2005

3. Blogging Course 1, Class 3

This becomes confusing and difficult with a Podcast that hosts new topics from show to show. Some time thinking about your show and your naming conventions will go a long way. Author a document that you can refer to from day to day. Remember, this is a living document and can be enhanced and brought up to speed with the ID3 tag standards as they grow and mature over time.

No matter what happens with podcasting the more professional you handle these ID3 Tagging conventions the better your overall presentation will be for you, your listeners and your "new" listeners!

Kind : This is straight forward a a result of the software. You wont have to enter this element

These next fields should be focus on accuracy. This is the second most important item of focus when ID3 tagging podcasts.

 
Size : This is so important it should be repeated over and over again. WHEN YOU GENERATE your RSS feed you must insure that size is accurate.  Did I say This is so important it should be repeated over and over again. WHEN YOU GENERATE your RSS feed you must insure that size is accurate.

This is in bytes, so for the podcast DSC-2005-06-09 case 19316824 is 19,316,824 which is roughly 19 MegaBytes. This is important the listener can determine if they want to download passively over time or wait. In case of one with bandwidth limitations, like JB, passively overtime would be convenient. However, certain priviledge people with awesome bandwidth (FIBRE for example) do not have this issue and can actively download. This data is very important.

Size : This figure is the play time of the file.

Dates :  In general dates are as important in terms of accuracy. Insure the dates reflect your content.

The Track Number : Really is an instance and if we where label it Instance Show # for example Adam’s current show is

Genre : This is straight forward a result of the software. You wont have to enter this element

 <dict>

 <key>Track ID</key><integer>5335</integer>

 <key>Name</key><string>DSC-2005-06-09</string>

 <key>Artist</key><string>Adam Curry</string>

 <key>Album</key><string>Daily Source Code</string>

 <key>Genre</key><string>Podcast</string>

 <key>Kind</key><string>MPEG audio file</string>

 <key>Size</key><integer>19316824</integer>

 <key>Total Time</key><integer>1931580</integer>

 <key>Track Number</key><integer>6</integer>

 <key>Year</key><integer>2005</integer>

 <key>Date Modified</key><date>2005-06-11T12:16:27Z</date>

 <key>Date Added</key><date>2005-06-11T12:16:27Z</date>

 <key>Bit Rate</key><integer>80</integer>

 <key>Sample Rate</key><integer>32000</integer>

 <key>Comments</key><string>adam@curry.com dailysourcecode.com</string>

 <key>Track Type</key><string>File</string>

  <key>Location</key><string>file://localhost/C:/Data/iTunes/
Adam%20Curry/Daily%20Source%20Code/06%20DSC-2005-06-09.mp3/</string>

 <key>File Folder Count</key><integer>4</integer>

 <key>Library Folder Count</key><integer>1</integer>

 </dict>

</dict>

</plist>

That’s roughly the tags and for now being consistent in terms of the Album, Artist an Name is the best use of the ID3 tags. It probably takes more time here to describe it than to actually do it. Do it consistently, and accurately and insure to see what the successful sites are doing…. And always ask!! Zapcaster
 

The problem to the end user, the listener, is to simply retrieve the shows that are of interest to them. The issue is how to provide listeners the shows pertaining to their interest, directly or indirectly. Upfront, this does not seem like a naming convention, or standards issue. However, simply, the naming conventions and standards provide an organized search criterion that directly translates to a search in an MP3 Player client or MP3 Device. For example., there are several arguments from strict standards to who cares, and both sides may have merit but the extremes are intolerable and horribly non-functional. The intent is not to be in either of these extremes, but rather, employ a middle ground solution.

ID3 TAGS STANDARDS

The ID3 for version 2.30 ID3Tag “Informal” standard provides a good start. Once this is understood you can update your Podcast Correctly and provide Responsible Tagging to your listening audience.  Of course there is version 2.30 ID3Tag “Informal” standard and we will get into the direction of that standard but for now. 

 I hope this has helped you to get up and running quicker!!

Z…Out!

tags: sos  

links: digg this    del.icio.us    technorati    reddit