Information technology tools and resources at the UW
Podcasting/Vodcasting: Distributing Your Audio and Video Files Via the Web – Part I
- Introduction to Podcast & Vodcast Publishing
- Introduction to XML
- Intro to RSS
- Adding Episodes
- Advanced RSS Tags
Podcasting and RSS have taken the internet and its users by storm. Podcasting uses RSS, or Really Simple Syndication, which is an XML-based technology. Podcast creators describe new content in an XML RSS file which includes dates, titles, descriptions, and links to MP3 files; this is called an RSS feed. The key to making podcasting work with RSS is enclosures, a feature supported by RSS version 2.0. In order to create a Podcast, you must be able to create an RSS feed. In order to create an RSS feed, you must have some basic working knowledge of XML.
We will introduce XML as a basic platform that RSS sits upon. Then we will explain how Podcasting uses RSS and how you can exploit many of the Podcasting-specifc elements to get your content distributed to hundreds or thousands of visitors as often as you’d like.
We assume you already have your podcast content (e.g. your audio, video, or other files) created and put on a publicly-accessible server (such as your UW Student or Staff web publishing space). If you are looking for information on the hardware and software necessary to create spoken audio files (like those used in Podcasting), please visit our GarageBand or Intro to Acid workshops in the Audio Series or the iMovie or Windows Movie Maker workshops in the Video Series. Getting these files online is as simple as putting them in your public_html (or student_html) folder on your Dante account.
Let’s get started…
Introduction to Podcast & Vodcast Publishing
If you are completely unfamiliar with the notion of a Podcast, consider them akin to talk radio on Tivo. Podcasts are audio files published on a (usually) regular or predictable schedule. Listeners or Subscribers then tell computer clients (sometimes called Pod Catchers), of which iTunes is one of the more popular, to check for recently-published audio files (often called Episodes). You, the Podcaster, get to be like the talk-show host, the internet is like the radio waves, and the subscriber is like the person caught in rush-hour traffic with nothing better to do. The key difference, however, is that the Subscriber can keep the Episodes as long as he or she wishes and listen to them at his or her leisure.
The way the above paragraph describes Podcasts is slightly simplified, of course. We can tell that just by looking at this workshop’s title–it includes “Vodcasting.” We put that there to emphasize an important aspect: podcasts are not strictly audio. Podcasts can contain any one of hundreds of different media files including MP3s, PDFs, MOVs, AVIs, and all such manner of content. It really gets interesting when content types are mixed. Include with your video file a copy of its audio and a PDF for its notes. Lectures can now be Podcasted as often as they are presented complete with overhead notes or even the PowerPoint files to go with them. Podcasting has many more implications than just recorded talk radio.
Podcasts are a form of RSS feeds and are generally audio or video files. Podcasts are shared on the Internet for anyone to download or subscribe to. Earlier we said that the internet is much like the radio waves of talk radio. RSS, then, is similar to the radio tower. RSS is used as a sort of way to give Subscribers information about Podcasts and tell them when new episodes are available. Podcatchers use the internet to periodically connect to the RSS feed and check for new episodes. If the Podcatcher sees that there is a new episode available in the RSS feed, it will download it.
What is RSS then? To explain that without first explaining XML would be like trying to explain addition without first explaining numbers. RSS uses a technology called XML. In fact, RSS is just a specialized (and much more strict and less forgiving unfortunately) form of XML. The next page gives some of the ground work for XML.
In case you missed some of that terminology, here is an abridged glossary of terms we just covered.
A series of files grouped together by a Podcaster and distributed over the internet via an RSS feed which can be subscribed to by Subscribers using a Pod Catcher.
Any software that regularly checks an RSS feed for updates to a Podcast. Pod Catchers may or may not be able to put these files onto an iPod or other portable media device. Common Pod Catchers include Apple’s iTunes and an open-source program called Juice. We will cover both of these later in the curriculum.
Any files within a Podcast’s RSS feed. We call them “Episodes” because they are commonly audio or video files, but any file in a Podcast could be considered an episode. Many Podcasts are limited solely to PDF documents. Each of these documents would be considered an episode. Similarly, if both audio and text were distributed on the same Podcast, each one would be considered its own episode even if they were directly related to each other as much as notes are related to their concrete material. Such a distinction will become more clear once we cover creating RSS feeds.
You! Anybody publishing a Podcast is called a Podcaster. Many Podcasts are published by a group of Podcasters or even corporations dedicated to their production.
An acronym for Really Simple Syndication. It sits on top of XML. An RSS “feed” is simply an XML file that is highly specialized to give information that a program is expecting to know. A Pod Catcher, in particular, is looking for certain information in the RSS feed about the Podcast, what episodes are available, when they were published, etc. RSS provides us a very concrete and predictable way to give this information to the various Pod Catchers so they can all see and use it in the same way.
An acronym for eXtensible Markup Language. It is formatted very similarly to HTML–by which it was inspired and conceived. XML is simply a hierarchical way of delineating, storing, and delivering information. It is now very widely used and supported in lieu of the many hundreds of proprietary formats that used to plague information systems to the point of inoperability. We will cover the basics of XML in this workshop.
Introduction to XML
XML is an acronym for eXtensible-Markup-Language. If you’re at all familiar with HTML, you may be familiar with the concept of a markup language.
In casual conversation, we gather information very informally and it usually takes us a while to figure out what’s important within a sentence. For example, If I were to ask you to tell me your schedule for the next 6 months, it might take a while. You might first start by saying “I have a meeting with Professor Boynton at 7:30pm on Monday, April 5, but I’m going to dinner before that at the Ram with friends at 6:00.” And then continue with, “then on April 6th, I’m going home for a few hours before meeting with Professor Devinatz at Noon…” Eventually we would have to come up with a system if we wanted to make sure we didn’t confuse days, times, and other information. Maybe we’d always say the date first, then the time, then the place, then other information. But how would we necessarily know when one thing started and one thing stopped? And if we were to record our conversation, would somebody else be able to understand so we wouldn’t have to repeat the entire conversation in a different way?
I can tell you’re already ahead of me. For the exact reason alluded to above, we have XML. Its acronym would have you believe XML is like something out of an LED-filled basement at MIT, but it is actually very simple. XML uses descriptive “tags” to say what kind of data is being given, what it pertains to, and where it starts and stops.
XML is used for description of data, whereas HTML is used for the display of data. HTML utilizes pre-defined tags (called Elements) whereas you can define your own tags in XML. We care about this in terms of Podcasting because Podcasting uses RSS which uses a certain agreed upon set of XML tags.
We use XML to give information to iTunes and other Pod Catchers and Podcast Directories.
In order to use XML, we must understand its form. XML uses tags like HTML, but unlike HTML, all XML tags must have a closing tag. XML tags are also case-sensitive, meaning “” is not the same as “.” XML tags must be properly nested and must contain a single root tag. All attributes must be quoted. Below is a simple XML example for music albums…
A very basic XML document, example.xml:
It is important to note that the tags (the text between the < and >) are completely arbitrary. It is only in application of XML that we have strict definitions for what tags can be used and what kind of data they should contain.
We like to space things out as this example shows, but that is a matter of personal preference that just makes things easier to read and spot errors. XML has no standards about breaking lines or indentation. Your xml file could be entirely on one line.
One very important concept of XML is that of nesting. When you open a tag inside of another tag, you must also close it within that tag.
Now that the basic XML markup is known, we can add the RSS. Onward!
Intro to RSS
We are now armed with the knowledge of what Podcasting and XML are. Now we will finally get to put that knowledge to good use to make our Podcast. The hard part isn’t over yet, unfortunately, but now we’re getting to the fun parts (remember that this is all on a relative scale).
Consider the following example of a perfectly valid Podcast feed:
Our first Podcast RSS feed, podcast.rss:
Note how we are now naming our file with the .rss file extension. We can use .xml if we wish, but since we are using RSS specifically, it is more appropriate to use RSS’s extension.
ADDING THE FIRST EPISODE
The podcast.rss file we have thus far gives us the Title of our Podcast, the URL link to our main page (the home page for our Podcast ), and a phrase or sentence to describe our Podcast. The good people at Harvard (who also maintain RSS 2.0 in addition to XML) say that every valid RSS feed must have exactly one (no more; no less) which of course must be closed.
Therefore, what we have so far is all that RSS requires. But in order to add the functionality of a Podcast (i.e. listing episodes), we will need to add some code to bring us up to:
Our Podcast RSS feed, podcast.rss, with one episode:
We have added the tag and a few other tags to give us more information about that item. You can think of as being like . Each episode will get its own .
Remember from a while ago how we said that each and every tag in XML (and thus in RSS) must have an accompanying closing tag? This is both true and not-true (interestingly enough). It wouldn’t make sense for some tags to have a closing tag, and the tag is one of them. In order for this to make sense to the Pod Catcher (and so our file conforms to the XML and RSS standards), we add a />(preceded by a space) to the end of the enclosure tag to tell the Pod Catcher that it shouldn’t expect it to be closed later.
Notice that the enclosure is left with empty attributes url, length, and type. Each of these attributes needs some explanation before we start giving them values.
The url attribute takes the full url to the actual file we would like to podcatcher to download for this episode. Please note that it must start with http:// or http:// or some other protocol. Simply putting the www. without the protocol will not work.
The length attribute is probably the trickiest. You need to find the length of your podcast, not in minutes and seconds, but in bytes.
- If you are comfortable with the UNIX shell, you can use the ls -l (l as in a lower-case L) command to see a file’s size in bytes.
- If you are on a Windows machine, right-click on your Podcast file and select Properties. A window will appear and will show you the size in bytes of your file.
- If you are on a Macintosh, Control+Click (or right-click) on your Podcast file and select “Get Info.” The size of your file in bytes is located in the “General” tab of the Info Window that pops up.
The included screen shots indicate different file sizes for the same file, but this is a factor of how the different operating systems downloaded this particular Podcast episode from the iTunes directory. Your file size will be specific to whatever operating system you used to create and upload the file. For this reason, you should always check your file sizes on whatever computer you’re using to upload the Episodes.
Depending on your operating system, you may be given the file size with commas to make it easier to read. For our purposes we will delete the commas when putting this number into the size attribute.
The final attribute, type, is where you input the kind of file the podcast episode is. For audio files this will be the the MIME type. In general, the .mp3 format will have be of type “audio/mpeg.”
MIME Types and You
|File Extension||MIME Type|
Included is a table for the most commonly-used MIME types associated with Podcasts. MIME stands for “Multipurpose Internet Mail Extensions.” When you send something as an attachment to an email, the email program actually takes all of the binary data from the attachment and throws it at the end of the message. The MIME type associated with the attachment tells the recipient’s computer how to interpret the binary data.
True, we are not using email for our Podcast, but this idea has made its way onto the Internet. Every sort of file out there has an associated MIME type that gives the computer information about what kind of file it is. We humans can commonly tell what program opens what file just by its extension, but computers often need more than this. Such is the case with our Podcast Episodes. While it technically is possible to have a MIME type that’s different than the extension (e.g. putting the PDF MIME type for a .mp3 file), this would have unpredictable results. We tend to think of MIME types and file extensions as being one-to-one (i.e. for every file extension there is exactly one MIME type and vice-versa). This is not always the case, but we can think of it as such for the purposes of Podcasting.
…should include a brief description (ideally less than 255 characters) of your Podcast. You should not use any special characters. That is, limit yourself to letters, numbers and basic punctuation ( . , ” ‘ ). HTML is not allowed. There is an analogous tag that will allow for HTML, but it is specific to just iTunes. We will cover it later.
PUTTING IT ALL TOGETHER
Adding this information about URL, Length and, and Type, we have a final Podcast RSS feed:
Our (now complete) Podcast RSS feed, podcast.rss, with one episode:
Now you would be able to save this file to a public server and subscribe to your Podcast via iTunes or your favorite Pod Catcher. We’re left with a pretty boring Podcast, however. It only has one episode, it’s not listed on any Podcast directories, and there’s no more information like its category, relevant album art, or “show notes.” the next page will show you how to add a new episode (a fairly straight-forward process). After that, we’ll get into the more iTunes-specific RSS tags that allow us to give Apple’s widely popular Pod Catcher (and thus a large number of subscribers) more information.
From our last lesson, we have the following podcast.rss file:
What we’d like to do now, however, is add more episodes. While this process is mostly straight-forward, there are a lot of opportunities to make small errors. Pod Catchers are highly unforgiving–if you get completely stumped on why your feed isn’t working, there is no pride lost in starting over.
EXISTENCE AND UNIQUENESS
When we have more than one episode, the notion of existence and uniqueness comes up. We won’t go into it too heavily, but the basic idea is that we need to keep track of what’s old and has simply changed and what’s new. Since we may get new Subscribers after we’ve published subsequent Episodes, we leave information in our XML file about the older episodes to offer the ability to download old content. The problem of existence and uniqueness then is posed by the desire to tell new content from changed old content.
The answer, of course, is obvious: IDs! We give each Episode its own ID that we can *never* change, and then we are free to change absolutely anything else about the XML file that references it. When posed to a group of people, many suggested that we simply use an Episode’s web address (URL) as the ID, but then what happens if we want to move the file to a new server or to a new folder? The same thing goes for using the Episode’s Title: we may wish to change it in the future. While there is no standardized way of giving your Episodes IDs, using a combination of sequential numbers and the date works well. The following might be a list of IDs for monthly Podcast Episodes
“Where does this ID go?”, you might ask. The confession, then, is that there are (quite) a few tags you might not know about yet. Many are specific to just iTunes and other PodCatchers (and we will cover the most useful ones on a later page), but the next few tags are applicable to all PodCatchers (and RSS Readers for that matter).
After all that talk about existence and uniqueness theory, we finally get to apply it with the tag. GUID stands for Globally Unique Identifier, and its purpose is to assign what is like a social security number to your Podcast Episodes.
An example of the tag in action would be:
There must be a tag inside each item, or many Podcatchers will only ‘see’ the first episode.
Before we move on, we need to add one attribute and property to it–the isPermaLink property. A PermaLink is a static URL in a dynamic directory structure. Because some Podcasters use an Episode’s PermaLink as its ID, there is support in PodCatchers for this. Since we are not including the Episode’s URL, we will just leave this as false.
Given this, we are now up to:
You can now simply copy/paste iterations of the above text multiple times and replace the respective values as necessary to add new episodes. Doing so, we arrive at another completed Podcast Feed:
AN IMPORTANT NOTE
Up until this point, the order of tags has not mattered so long as we haven’t broken the nesting rules discussed with XML. That is, the tag could have appeared before the tag and so on. Order doesn’t appear to matter. However, iTunes and most other PodCatchers will list s in the order that they appear in the feed’s code (which is why we’ve put episode 3 above episode 2 and 2 above 1 in the code). Next we will learn some extraneous (i.e. not completely necessary but sometimes useful) tags including one that will allow us to change the order.
At this point, you really really can stop with this tutorial. You know how to set up your feed and add new episodes. If you know how to upload to your Dante (or other FTP site), you can save what you have so far and run with it without worrying about anything we’ve purposefully left out.
We will devote another two pages to more RSS tags to add new features to our Podcast (such as episode descriptions a/k/a shownotes, “album art”, and a slew of iTunes-specific features). Then we will cover validators to be sure our feed is free of errors before posting it. Then we will refresh you on how to upload to the webserver and the basics of HTML and linking to your Podcast on your website. After this, we will cover listing your Podcast on various Podcast directories (including the iTunes Music Store). And then last (and perhaps least) we will introduce a few Podcast feed Generators and tracking services that will do the hard work for you and let you more accurately track your Subscriber statistics. Finally we will give you the HTML and some free icons and buttons you can use to link to your podcast on your website.
Advanced RSS Tags
We would now like to take our Podcast to the next level by adding more tags to the RSS feed to give PodCatchers (and thus our Subscribers) more information about our Podcast and various episodes.
We have arrived at the following podcast.rss file during the preceding lessons:
Our functional but still boring podcast.rss file:
ADVANCED CHANNEL TAGS
We will start with some of the advanced RSS tags that go within the tag before covering the more advanced tags within the tag.
Some PodCatchers (including iTunes) are capable of displaying basic HTML within their content regions. This is not supported, however, in the basic tags. In order to use HTML and other special characters (i.e. anything other than a-z,A-Z,0-9,”,’,comma,.), you must use one of the iTunes-specific tags that we will cover on the next page.
|Copyright||A sentence or two describing the fair use of your Podcast. Seen by some PodCatchers.|
Copyright 2006 by Ryan. No rights to distribute or disseminate without Author’s consent.
|Publication Date||The last date of publication for this channel (i.e. the last time you added an Episode or made a change to this feed). The format that this tag requires is a bit awkward. Consider the following example:
Sun1, 042 Sep3 2010 144:345:216 PDT7
You should update this tag every time you post a new episode. Many PodCatchers will not pay attention to added items if the has not changed since it last visited the feed.
Sun, 04 Sep 2010 14:34:21 PDT
|Time to Live||The number of minutes the PodCatcher should wait before checking for new episodes. If you omit this tag, most PodCatchers will assume a wait period of 24 hours.|
|Image||The “album art” for your Podcast. Each Episode may have its own , but many PodCast directories (including the iTunes Music Store) will display Podcasts’ feed url in the listing of Podcasts fitting certain criteria.
The tag has several sub-tags rather than attributes. These sub-tags include:
tag. HTML is okay.
Craig’s Podcast Logo
A picture of me and my new car.
Here is our PodCast feed after adding these tags to our :
ADVANCED ITEM TAGS
The next round of tags is very similar to the last round. In fact, many of them are exactly identical and have the same function. The only difference is going to be that the contents of the tags are going to pertain to each individual episode and not the Podcast as a whole.
That is, instead of us putting the URL to our Podcast’s logo in the tag, we are going to use an image that is specific to each Episode. The logo will be displayed on directories of multiple Podcasts, but the “album art” will be the content’s of the most recent ‘s tag.
The following tags may also be used for each within the . The caveats to their usage are the same as addressed earlier.
- (and its sub-tags)
- (remember that HTML is not okay for this)
Adding these for each of our s, we are brought up to:
Our really almost complete but still boring podcast.rss file:
WHAT’S IMPORTANT: RECAP
- Make sure you correctly update the in your every time you add a new Episode.
- Make sure each Episode (and thus each ) has its own .
That’s it! There are of course more RSS and Podcasting tags, but they are mostly obscure. Please see Apple’s Podcast Technical Spec page (opens in a new window) for more information.
What’s next? Next we’ll cover some of the iTunes-specific tags that you can use if you plan to list your Podcast on the widely popular, free, and publicly-available iTunes Music Store. We will also briefly cover a few of the other popular PodCast directories that use the iTunes tags. If you are not concerned with advanced features such as HTML-enabled show notes, keywords, and categories, you may safely skip the next page.
Then we’ll need to upload our feed to a public server. We will do a quick-review of how to upload to your Student Dante or Staff Homer account using various means. Then we will cover validating your feed so we don’t submit a broken feed (which guarantees no subscribers).
We will then conclude with a quick HTML wrap-up with pertinence to linking to your Podcast on your web page using royalty-free graphics.