mit it partners podcast conference tape2
Jane White: Good afternoon everybody. My name is Jane White for those of you who were not here in the earlier sessions. I'm here to welcome you to the afternoon portion of the Podcast track of the IT Partners Conference. And this first session this afternoon is called "Creating RSS Feeds for Podcasting", and our guest speaker today is Robert Wolfe from the MIT libraries.
Robert Wolfe: Good afternoon. Can you hear me? Is this close enough to me? Great! If you'll excuse me I'm going to sit down while I give the presentation. I run a Metadata Services unit for the Library.
We're a service point for MIT, so I provide consulting and production support for digital publishing projects outside the library. My two largest clients are OCW and DSpace, but I also have done some work for IS&T, helping them to prepare their sort of users guide for Podcasting at MIT.
And what I'm going to talk about today is the, what I think is the coolest part of Podcasting, the little XML file that brings all of the various audio and video files you have together, and actually turns them into a Podcast. So let's see if we can, all right. So if you were at the early session, the first session, Podcasting was introduced. And it's basically explained to be nothing more than taking an audio or a video file and putting it on a server, and then writing a little XML file that contains some information about the audio, and putting that on the server as well. And then people link to the XML file, and that's where their applications, their RSS, their readers, help them to download the audio and video.
And what RSS really does, is it serializes them, so each time you add a new one, it provides a date that it's been added, and it attaches it to the end of the list and on down. And then when people come to read the XML file, basically the reader says, well I know that we checked this last on this date so anything that's newer than that, I'm going to download for this person. I'm going to ignore the old stuff, assuming that they already have it.
And RSS files are written in what is called the Extensible Markup Language. We will look at a little XML, but we won't get crazy with it. XML is a primary tool that I use in creating data structures and Metadata for clients. And to be honest, RSS really is just Metadata (laughs) similar to the library catalog but with some new and interesting features. So an RSS feed, basically what the XML does is it creates a structure. And it creates a linking mechanism. And the structure is simple, if you have a Podcast, that Podcast is in RSS 2.0 called the channel and there is a channel tag. And in Atom, which is another RSS flavor it's called a feed. And the Podcast or channel is comprised of items, so there will be multiple items listed one after the other or if your working with an Atom RSS file you'll have a feed that has multiple entries. And that is the basic structure.
Then in order to point to the actual audio file in a way that is useful to a reader so that it knows how big it is, what kind of file it is, and where it's going to reside permanently, there's a linking tag. Which in RSS 2.0 is called enclosure. I think that was mentioned a few times. And in Atom it's called a link. We'll talk a little bit in the next slide why there are different names for what is essentially the same structure. Channels, channels have multiple items. Each item has to have an enclosure to link to an audio or else it's not really a Podcast. And the rest of the information is Metadata.
Feeds come in many flavors. It might be, I don't know, I think I will go ahead, useful to talk about why there are many many flavors.
RSS was originally sort of invented...there was like 0.9, and you know it had channels and items and then some folks got the bright idea that they would turn it into RDF which is what Tim Burners-Lee was talking about earlier. So RSS 1.0 is what eventually turned into an RDF version and that stands for RDF syndicated serialized something something something. But in any case that's any RDF flavor of RSS. And then the people at the Berkman Center for the Internet and technology at Harvard, said that that's too complicated for the simple person. Let's go back and make a plain old vanilla XML version and that became RSS 2.0.
And then when ITunes and Google and Yahoo decided that they need to be podcasting too, they looked at RSS 2.0 and said, you know what we have to come up with our own proprietary standard, that will be the standard. And so there is an ITunes version of RSS 2.0 and Google and yahoo collaborated actually surprise, surprise, to come up with media RSS, which is also RSS 2.0, but with special you know media RSS tags. And a lot of people who are sort of XML purists, said well this is all well and good, but you're playing fast and loose with what XML is and how it works. And we don't like that so we're going to come up with a better more stable robust XML version and that's Atom.
And what you'll find is that, it seems every single Podcast chooses a different slightly different implementation of RSS, so there are lots of ITunes Podcasts out there, lots of media RSS flavors, and most of the RSS readers can read any of them. That's basically what you have to do if you want to write a tool to actually read RSS and to interpret Podcasts. You have to be able to understand any of these versions. What I would recommend is pick a version based on what your most likely to do. And if all you really want to do is upload your video, your funny videos to ITunes you would pick ITunes. If you have wider interests, say you're in educational technology, you want to Podcast lecture videos. You might pick Atom, because it is a little bit more robust, a little bit more, it's just better XML than RSS 2.0 and I'm not going to try to explain what better XML is, because I know that only interests folks like myself who work with it everyday.
But let's, what we're going to do today is actually look at some RSS 2.0 samples and then we're actually going to see if we can write one very quickly by hand. You probably won't be doing your Podcast creation by hand, but it's actually very very easy. So the rest of the stuff that comprises an RSS feed is Metadata. And for IS&T I prepared a list of recommended Metadata elements that you should include in your Podcast. I basically recommended ten elements. Identifier, well you can see them all here. These I think are very very important, not so much to improve the searching, the searchability or the findability if you like more of those terms, of your content, but just to make sure that it runs properly.
If you don't add a date, then an RSS reader doesn't know what the new stuff is. If you don't provide an ID for the file that you're linking to, it will get lost I guarantee it. If you don't provide a copyright statement, you can't protect yourself from people who misuse or misappropriate your content. And title and contributor and descriptions are also very very obvious. You'll want to provide those things so that when the reader lists all the Podcasts before someone downloads them, they're actually providing some information to the user, so they can make an informed decision. Oh, this particular video is what I'm looking for, and not the next one because it's on a different subject. Same for subject and language and duration. I tried to keep it very simple in what I recommended, nothing elaborate. All of these things though should be really easy to produce.
If you want to actually improve the ability to search your audio and video the only real way to do that is to do a transcript. And they're expensive, but as it was mentioned in an earlier session go look at Podzinger. It's this great new service that's built on several years of effort to actually transcribe or automatically transcribe audio and video into text. So you might find the solution there.
I had hoped that we would be able to hand out the users guide recommendation that I prepared but I don't think it made it into your packets. So what I will do is I will lean on Lisa and Stuart to put it up on their web site. So that you can download it, and we'll go to the web site in a bit. Ok. So writing RSS is easy. Here's where we'll leave the Power Point, the slides and get our hands into some RSS. You can use any text editor, because XML is just text. You can do it in Word if you wanted to, but I wouldn't recommend it, notepad is very good. I actually have an XML editor that we'll use called Oxygen, which just makes things easy.
There are some software applications you can download to help you write your RSS feed. ListGarden and RSS Buddy are some of them. I can show you what RSS Buddy looks like, it is just a client that you open up and it provides all of the Metadata fields and you just fill in your information. Now it doesn't have all of the Metadata, the elements that I recommend, which is why I wouldn't recommend RSS Buddy. But, it does have most of them. And it does have some different ones. RSS Buddy actually is targeted towards an ITunes RSS file so you have the ITunes categories that you can apply and subcategories. We'll see what they look like in XML and they have owner and contact information. Those are tags in RSS that ITunes adds that no one else does because if you're submitting a Podcast to ITunes, they want to know not who created the Podcast, but who you are that are submitting it. So that if someone finds something illegal or inappropriate or offensive they can come after you. So that's why you see all these different flavors of RSS.
Different applications that want to read RSS need different information. But let's go back to, and here's where you can access ListGarden, and I believe these links are in the user's guide, so you can find a list of references there. And here's where you can download Podcast RSS, but and of course your web log software, if you have a web log it does most. WordPress, Movable Type they do publish an RSS feed for your web log and most all of them now will accommodate audio and video. So if you link to an audio or video file it will create the enclosure tag. And automatically you have a Podcast. So if your really just want to simply get started without much and you already have a web log or you can go to BlogSpot or easily just create a web log for each entry instead of putting in text, just link to an audio or video file. And the RSS feed will essentially Podcast your items. You can point people to the RSS feed in their reader. And we'll see a little more about that.
Ok let's go back and see what to do. I don't want to get ahead of myself. And let's look at some Podcasts. So this is generic RSS 2.0. You've got some, just an XML declaration you can ignore that. Every XML file has to have that but it's always the same. We'll you might have a different encoding but I wouldn't worry about that. Then there is an RSS element. It has a version attribute just to tell you that yes you do have RSS 2.0 very simple. This is a URL to allow you to include elements from other Metadata schemes. This happens to be the Dublin Core element. A lot of Podcast users have been adopting elements from Dublin Core to supplement the RSS elements where they're not happy with them. RSS 2.0 doesn't have a way for you to ascribe a contributor or an author or a creator to the channel itself. You can, on items for individual video files, you can say this is the author or this is the creator of the video file. But you can't say this is the author or the creator of the channel or the Podcast. What you can say is this Podcast has a managing editor, which doesn't seem appropriate for all Podcasts. So what folks tend to do, is they want to use an element from a different scheme like Dublin Core. So when they get down to it that element right here, they use a prefix that says this is not an RSS element this is a Dublin Core element. And the thing that allows them to do this is this declaration which says XML namespace and it just tells you what web site actually defines the Dublin Core element. It's just a neat little namespace mechanism. If you don't want to actually bother with that you can leave that off and just deal with the RSS 2.0 elements.
And then here you have your channel, and we're going to title the channel so that we know what the Podcast is and this isn't the title of any individual file. This is the title of all of them so this is 6.013 electromagnetic applications video demonstration. And RSS 2.0 has a link, so we've actually linked, I took these from OCW. So here is the OCW link to that course. And then there's a description that contains movies and demos that are related to the course and then you have the contributors, these are the professors. You have the language, which is encoded English, US English, as opposed to British or Australian English. And then you have the copyright statement for OCW. Now I just sort of made up this category demonstrations to provide a category and what you would want to probably use is sort of a vocabulary or taxonomy so these are the define categories and I'm going to fit them into one or the other.
And here you've come to the first item so all of these elements or tags this Metadata describes the whole channel and all of the videos as a whole. What we're coming to now is each individual item and here's an item in the first video it has a title "wave propagation in free space" and then a description. This is demo 1.1 from our friends from lecture two and it demonstrates phase difference and amplitude decay. Here's the all important enclosure tag and you can see how it has, these are called attributes, a URL to point to the file. It has a length attribute, which is in bytes it tells you how big it is. And it has, I think I just made up this number, you don't want to do that. And then it has a type, which is telling you its mind type or format. This is a video, an MPEG video file. All three of those attributes are required for the enclosure tag. And they pretty much, they're self explanatory. If a system doesn't know what kind of a file it is looking at it might be able to figure it out by looking at the file itself. But you don't want to force it to do that.
And then this guid element is an ID. Guid stands for I believe Globally Unique ID. And every object in OCW gets assigned a guid. If it's in the CMS, there are tables of these things. It's just a random string of numbers. It's one way to produce or prepare an ID. What you're shooting for in an ID, is something that will persist. So that it will be the same over time. It won't change. That's why you don't necessarily want to use a URL because you might decide to move those videos. And if you do all the links will break. So you produce what's instead called a URI, a uniform resource identifier. It's like a URL but it doesn't actually resolve to anything. It just sits there uniquely and globally. Globally unique is ideal. If you can get unique within your system then you're doing pretty good so.
And then the pub date, these are all RSS elements. And this date happens to be formatted accordingly to an ISO Standard. I can't remember the number of the standard. And I also included a second item just to give you an idea of what it looks like when they're multiple items. It has a title and a description, it has an enclosure. Here's another option, this is what a URI might look like if I just to that one, it looks exactly like a URL, but what you're promising in using this URI is that you're never going to change that value. It may, I mean you might change where you put the video but this will always be its URI. And then of course it has it's own date. So that's RSS 2.0.
I did the same exact thing for these two in ITunes just to see, so that we could see the difference. So we have RSS, we have our version 2.0. We have a different namespace for ITunes, so that we can include the ITunes elements that they created to supplement RSS. We have the same channel, the same title and link. But instead of having description, ITunes uses subtitle, so we used the subtitle element, same information. And instead of you know ITunes recognized that RSS doesn't have a good author element for the channel. So they invented their own but according to their rules, you can only have one author element, you can't have multiple. So what we had to do here is cram all of the names into one element. Now that's a little idiosyncrasy of ITunes that you need to figure out. Fortunately ITunes has a really good technical specification section which is also linked from the users guide where you can go and find out all this information. And it has samples, which basically where I went and figured all of this out. And you can see their samples here have subtitle and author and summary.
And they have very good reasons for choosing their particular elements and making a new version of RSS. And they are all based around the ITunes client and software. So all of this Podcast information is ending up in those fields that you see: name, artist, title, album. And you kind of have to sort of, unless you're dealing with music, you kind of have to force fit the Metadata you have. Which you might not have an album for these OCW lecture videos. But it has to get in there some way and they chose sort of, well they chose what they chose. But subtitle maps to a very specific field in their client so does all the maps to a field you can't have multiple authors because you can't have multiple artists assigned to one of their Podcasts. So it would make sense for them to allow someone to duplicate the author field. They just have to do more work to concatenate all of those authors together at the end.
So this is what you have to, this is the complicated part about thinking about an RSS just thinking where your sending it, who's going to use it, and you have to get to know the primary systems. And then of course language and copyright is the same and here's where ITunes has its own categories, education and higher education. And that is from their category list, which they include, in their technical specifications. So you can go see here are the categories and they didn't have a demonstrations but they had education and higher education and that seemed to make sense to me. So I applied their categories and you'll see that they co-nest. So this is the higher level education category and then underneath it or nested within that element is a subelement that shows you that it's higher education. And then here is where they want you know who you are that is submitting this Podcast for legal liability reasons and I'm claiming OpenCourseWare did it so they're the ones on the hook.
And then here are the items. The title is the same, again they have a subtitle instead of a description. They have their author field and the reason you'll notice in RSS 2.0 that I knew that all the authors would be the same for every single video. And it's the professors. So I put them at the channel. So I didn't have to duplicate them over and over again in the item. But that doesn't work for ITunes because when you go to see a Podcast in ITunes. I don't know if I can actually do it. Let's see if I have some Podcasts. I have some funny Podcasts. You'll see that this would be the Metadata for the channel.
To keep our TV video and presumably there's an artist somewhere along here, it's just not showing. Right? Well if I just put all the authors in that one artist field in the channel the artist would show up here. But for each individual video you need to actually add the artists again. Now if you want them to show up in the client properly. And so I've had to duplicate them for the ITunes feed down here and that's something that you have to decide as well. Just to let you know all this, this is the guide introduction to Podcast tagging and there is a little discussion about introduction to feeds and RSS and XML. Here are the essential tags and why I think you should use them.
And then here are some basics. And we'll talk about channels and which tags you should apply there. And at one point we talk about, oh here we go.
Channels and items and deciding at which level you're going to actually apply Metadata, whether you are going to have different offers for each video so you want to apply it there, whether they'll all be the same and you just want to list them once in a channel. All of these things are influenced sort of by the information that you have, the content you have. And also by where you want to put the content and how you want people to access it. So if you're uploading it to ITunes you'll have one set of considerations. If you're uploading to iPod or Juice you'll have another. If you're sending it to Google video or Yahoo video you'll have a different set of concerns. So I hope that you all will get a chance, and I've got the samples up here too with the discussion of some of the tags, that you'll have a chance to look at that.
So, but, getting back to ITunes they use enclosure and they have a guid and a pub date and they also have these extra tags called duration and keywords, which it doesn't seem like I've filled in, and then you have the second one. Media RSS is a little bit different. I'm going to go quickly through this because I think I want to get to actually writing an RSS feed so. Let's see, the name space media is the media RSS namespace for adding their elements in. I added this one because I used the vocabulary from OCW from the Metadata set that I defined for them. They have a channel, a title, link description, they have their own limitation of authors at the channel level called credit, recognizing that not every contribution is going to be an author's contribution, or generic contributor. They allow you to define what the kind of contribution it is, and I actually defined those contributors for OCW.
So there's a vocabulary that I defined, and that's what we're using here. So this is where we point to it, and then of course you can duplicate it so all of the professors are in their own credit element again, language, copyright, category.
The new thing, the thing that media I think did well is they created, they replaced the enclosure tag all together with a group element and a content element. And what that allows you to do is what OCW has done is they have three versions of lecture video or audio. Like a 56k, an 80k and a 220k. Now those are all intellectually the same item, but they're different files. Where in earlier you'd have multiple enclosure links, you wouldn't want to have multiple items for these individual media files when they're really the same thing. Media RSS recognized that people are going to be publishing this way, and they created this media group element so that you could have multiple media contents one for each version of the file. And then they all get grouped together under the group element and then those all are recorded as the same item. And that way you can you give RSS readers the freedom to choose which version is appropriate for the bandwidth, the connection that the person is using. Which I think that that's a necessary and a great addition and it's just a shame that everyone isn't using it. Only the people who create media RSS are.
Here's an 'Atom Feed' it's a little more complicated. The one thing about Atom Feeds that RSS feeds don't have is that they validate which means that they have a name space and a schema. There's a schema for Atom. So you can actually say, you can actually take your RSS XML and say "this is a valid Atom file because I know that it conforms to all the requirements". You can't do that for RSS 2.0, there's no schema, well no official schema and they have an ID for the channel. Title, subtitle, notice that feed replaces channel. And they don't have an RSS element, they have a link instead of well that's still with the 'Atom'. They have updated instead of date, author, category, rights, similar stuff. Entries instead of items, and then link instead of enclosures, but it's basically the same thing, an ID, a title, a summary. People just decided that they wanted to name their labels differently or they said "well we need to have this kind of element that RSS 2.0 doesn't have so we have to makeup our own new system".
So let's create our own RSS feed, and I'm going to create a vanilla RSS 2.0. So I'm actually going to go to the RSS 2.0 one, and steal the RSS element, which I do all the time. And we should probably close it up, that's what I like about XML is that it automatically suggests the tag. So I know that the first tag that I need is a channel, what I actually should know is that I need an object to Podcast first. So what I've done is go to this OCW course: "Introduction to solid state chemistry" and I just happen to know there's a Donald Sadoway is the professor but the lecture notes section links to video. So we have video and we have slides. So we're going to create a Podcast, we'll probably just do one, which includes the first lecture video. Now what we need to do is, find Metadata the title, the name, all that information including the link. So the first thing that I would do is I would watch the first few minutes of the video to see if any of the information shows up. I hope it's not too loud.
[Video Snippet: Welcome to 309.1. My name is Donald Sadoway and I will be your lecturer.]
Robert Wolfe: This is probably the fourth lecture you guys have seen today so far. And well, he goes right into it. So we get no title slide or any information so I'll have to go poach this. Now since I happen to know OCW since I created the Metadata for it. I know that if you go to the directory for the course, so OCW is built, you know here is the directory the department of material science and engineering 3.091 fall 2004. If I were to erase all of this there's no index page for this directory, instead you get to see the directory. And OCW has been really kind to actually publish all of the Metadata, so I, one of the things we did is I created Metadata for every file in the OCW CMS so every lecture file or problem set. Now the video doesn't have Metadata because it's on a different server because it's so large. But what I can do is I can go find the file for the lecture slides and see if there is any information we can poach. So I'm just going to look at the XML and here it is. This is the Metadata produced for OCW, and we have what seems to me a pretty good introduction, a title right there. "Learning Object" Metadata is the type of Metadata that we are dealing with right here. So I'm just going to grab this piece of information, and then I'm going to go back.
And what elements do we want? We want a title, and a link. Well let's create our title element, let's add our information, and that's the title of the video. We just, we decided that, you know one other thing that you can do is you know you can look on the actual web page from which it's linked all they have here is lecture one and then the topics. So when I created the, we can actually look at the slide too and whether that had the title. "Welcome to 3.091" that doesn't look like a title to me. And then it goes right in. So it looks like I just invented the title out of thin air when I was cataloging the lecture slides which sometimes you have to do. So, "introduction taxonomy" seems to work for me. So we've got a title, what's the next element? We had a link, now what did I link to? I linked to the index for the course. So this is a link to the web site from which the Podcast is being hosted. So what I'm going to do, good Lord, actually I'm going to go backwards and backwards again, no I can't. I'm going to go back to lecture notes. And I'm going to attach this, and this is going to be the link to this information. And of course, then we just, what we are going to call this... like bid.rss and actually let's just go XML. Okay, so this is going to be the link, this will be the name when I save the file, of the Podcast [mumbles something about the link and that's what they want you to do]. Now you can also, if you have the users guide. I have listed here a list of tags that are important to include in the channel. Identifier, copyright, title now I've already done title, and I've done link. So now contributor might be next? Is that what we have over here? Yes, contributor, DC contributor. So let's see DC contributor, and what was the name of the professor? I think it was Donald Sanaway? Yes it was, Donald Sadoway.
And then the next one is Language and copyright. Well language was easy. Now there is a standard for producing two digit language codes. France would be FR and English would be EN. And now since English is spoken differently in different places there's a subcode you can use, I think I'm sure I linked to the standards for that in the user's guide. I think it's like 8601 or 621-2 or something like that. And the next one is copyright right? Now I happen to know that all the OCW material is under the same copyright? So I can pilfer this again, and that's a good I think lesson that I can impart here is... Oh I went all the way to category didn't I? Is reuse as often whenever possible, so create a template that includes all the information that you're never going to change and then just create new documents from what.
So what else do we include? That was all that we included in the channel. Now did I recommend anything else? Description, subject, language, we've got language, we've got subject, oh actually I should include subject shouldn't I? Ok, so we should go, actually yea, that happened when I accidentally copied the category tag in when I didn't mean to. So, let's add category, thank you for catching that. And I'll just make up video lectures. OCW probably has categories that I could apply this to but I'll apply to this already. So now we want to create the item, right? And you know what I did something really really,there we go, really really wrong didn't I? This title "introduction to taxonomy of chemical species and origins" is the title of the first video which would be the first item. It's not the tile of the whole series of video that we're Podcasting. I got a little too carried away, a little too eager. So we'll just move this down here. And now we have to go back and find the title for these lecture videos. And you know what I think I'm going to again follow the practice that I started over here. And put the full name of the course and then some mention of the fact that we are dealing with video here. So let me figure out what the actual name of the course is. 3.091 introduction to solid state chemistry'. Let's see if I can remember that whole thing as I type. Now I have to go back and fall 2004. For, I'll just call them Lecture Videos to keep it simple.
So there, now we have the channel properly titled and the first item it titled. And, now we want to provide a link, well, oh yeah. No, I was looking at the wrong thing. Now we move to the description. So what I'm going to do is I'm going to cheat again and I am going to go back to that Metadata for the lecture slides, and see if I can't borrow the description from the Metadata for the lecture slides. "Lecture presentation covering the following topics" and that seems pretty generic to me. Now we have a description, what else is on our list? We're sort of doing it out of order, we did the title, description, contributor. It's different from the channel.
Now we have to decide, do we want to list the professor's name for the item or not? Depends on what we want to do with the Podcast, if we are submitting it to ITunes we definitely would. In this case, I think I will skip it just to save time. But you shouldn't skip it. We want to make sure we get identifier and copyright right from the channel the copyright is the same all the way through so we use that information. I think we'll move on to the enclosure tag, the all important tag. So enclosure, if I can learn to spell. And then the first attribute is the URI, what we are going to do to get that URI is go to the lecture note section. And since if I click on this it'll try and open this, I can going to copy the link location and then paste copy that in here. And there you have the link to the actual video file and I did just the ADK.
You should have the full path, you should have the absolute URL, because what is going to happen is the XML file is going to be read by a external application. And that application may or may not, it should, may not be aware of where it is reading it. So if you use a relative URL it might not work, I'm fairly certain that it's actually a requirement that they be absolute. And I think that length and type were the other, and this is where is gets a little tricky. Figuring out what the actual length of the video is, I don't know if RealPlayer will tell me. Does it?
Oh well that's the, and this is where length is like really confusing and a poor choice for a label. That's the time length that's really the duration, what is meant by length is really the bit size or the bite size of the file. And I'm not even sure how to use RealPlayer to find that information out but I bet you could. I wonder if I'd actually download it to my desktop because then I could get it. And it did. So let's get the info, and it claims to be well yeah 311 bites isn't a very large video and I keep forgetting that RealMedia is a streaming format so that's just a pointer. Well that's where you actually have to have the content in hand so you can determine that for yourself. I am forced just to make something up, let's just say that it's that big. And that's in bites.
Five minutes? Awesome.
And then the type, equals, and I'm fairly certain that all I did was MPEG. So I'm going to have to try and remember off the top of my head what the mime type for RealAudio is. It's application, something like RealMedia. Anyway, that's approximately what it is. Oh, now I have to enclosure tags.
Okay, Great!
So, the only other stuff is a guid and a pub date. So quickly go a guid, I'm going to go ahead and do a guid I'm just going to go ahead and use the URL. And what that means is that even if I move the URL I'm not going to change this guid that will always be the guid. And, it's camelcased isn't it? Yes it is, this is called camelcased, it's when you smashed two words together and you capitalize the second one so that you know it's two words. An I'm just going to steal this date, because I don't actually want to type it all in. So there you have it, that is a Podcast file an RSS file. I could throw this up onto a point on the server and then share the address and people could actually go and their feeders could actually be able download this video.
[woman asks a non-understandable question]
Robert Wolfe: You just add new items, and in fact I need to close off the item. Is it closed at the top? Oh that's so annoying!
[a different man says something that is hardly audible]
Robert Wolfe: Yeah, that's, I've got to find that. Oh. You know what? I've like really botched this didn't I?
Well, this is why you check your errors. And it would be helpful if you could validate your XML because then you could just hit this little red checkmark and it could tell you what you've done wrong. But seeing as how, and now I think that's nested properly, yeah so these should all be and just to make it a little prettier. All right. So that's a rudimentary RSS feed, and lets go back and.
So writing RSS all that complicated, it's really simple it's all just a matter of learning what the tags are and you know having in your head ahead of time what information you are going to provide and formatting it properly. That's all. You know you want to have a title and author, and a subject and all this other stuff. And then you're just making sure that your XML looks right. And like I said you can use RSS buddy, and you could fill in the same information and hit save and it would write out the XML for you. Your web blogs will also do it and it's pretty cool. This is my moveable type software, and I happened to for awhile the New England association of information science and technology was using my server to host their events log until they got theirs up and running. They have a spring event and they Podcast it so they actually linked to these presentations in the blog and if you go look at the RSS the software just automatically spit it out and it did that because it's pretty freaking smart. It's a Perl application and it knows weather the file that you linked is an audio or video file that it can actually Podcast and then it writes a unique enclosure element instead of just the normal HREF.
So if you go down and look I'm sure we'll find that enclosure element somewhere, I should have probably just hit apple-f and looked for it. There it is, so there's one and I actually like to look at the way it does this and if you look at templates. Moveable type works by static templates, this is the template for the index page that it writes out. And there's a template for ours is 2.0 and it includes the little enclosure tag, you got a little pearl bit that says you need to go create a little enclosure tag if you can. And that is right right there. So, that is the little bit, it is just a little pearl command thing. It runs a little script on the server.
As someone just pointed out, to update, to maintain an RSS feed is kind of a tricky business. You have to make sure you put your new audio/video on the server, edit your RSS feed and then replace it, resave it up onto the server. In most of your web log will do it automatically, and I am sure ListGarden and RSS Buddy will do it as well. Oh, I was going to walk you through submitting your feed to ITunes, but I think what I will just do is point you. If you go to the ITunes section, they will actually will walk you through the process of sending them the link to your RSS file. So that's the presentation. I probably have like thirty seconds to take questions [chuckles]. Yeah, go ahead.
Woman 1: I have a question about the beneath ID's. That you assign, let us say that you assign 123 if you do not want it to be the URI. How do you also have that file linked to that number?
Robert Wolfe: Well, that is part, I didn't want to get to far into it, but there are different mechanisms for what are called persistent global unique identifiers. The Handle system is one, the document object identifier is another. They all involve resolvers, so they're basically just look up tables. You get a prefix that is you, generally, so some string of numbers. For D space it is like 1721.3, or something like that, that's their prefix. They have the ability to assign any string they want to the suffix. And that automatically is globally unique, because they are the only ones that have that prefix that can use it. What they have to do is periodically send to their resolving system their list of new objects, and then pass out those handles and the resolver system. So it does involve, basically, a look up table. Even the guids do. The guids are handed out by content management systems. They are at least internally unique to their content management system.
It's worth it though. I am one of those that will preach the most important thing that the web needs is persistent identifiers for the objects that are listed up there. It is the number one Metadata element. It is worth it to go the extra mile to either create a URI or some other form of a globally unique identifier. And then the copyright tag is probably the second most important. Then you can actually include creative comments RDF or XML in your Podcasts. You can go to create a comment site, choose a license, it will give you a snippet of XML. You just plug it right in there and you are off and running. Anything else? Well thank you guys for coming and.
[clapping]
Robert Wolfe: Yeah. Well, it always...
[another break]
Jane White: Good afternoon, I would like to welcome you to the final session of the Podcast track called "Creating audio and video files for Podcasting" and our guest speakers today are Jeff Silva from Amps and Sandy Mallalieu from OCW.
Jeff Silva: Thank you. Thanks for sticking around for this session. It's been a long day and I am sure you are all pretty saturated, so I want to make this, I think we both want to make this informal. Please if you have any questions while we are in conversation, do not hesitate to raise your hand. It's a little hard to see out there, but shout out if need be.
Jane White: I will try to identify some of them for you.
Jeff Silva: Also, I am going to give a brief overview of experiences that I have had with video podcasting at Amps with various projects that we have been doing, and there is some crossover with what Sandy has been doing, as well. So we might do a little back and forth here.
So in any case, we started this project earlier in the year, in January I would say we launched our first Podcast. And Larry has already gone over a lot of the projects that we've done, in terms of lecture Podcast and tutorial Podcasts and the Zigzag video magazine. And I'm going to go into more depth about the various issues that we encountered, specific to each project.
These are some of the considerations that were important to us in the deliver of this. Obviously, the video and audio quality is very important. The turn-around time to publish, it depends on if you are going to publishing a video magazine, like Zigzag. It is a scheduled program so we need to be able to deliver that in a timely fashion. Lectures needed to go up, usually our goal was to turn it around within forty eight hours. Sometimes we were on, sometimes we weren't.
Also another issue that came up was download time. Some of these files are up to eighty minutes in length and, actually some are a bit longer than that, and so the larger your file size, the longer the download time is, if you are going to be using ITunes. We had to factor in these considerations, as well as accessibility and operability for the user. We, not everyone has ITunes, so wanted to make some of our content accessible via the web. For instance, the magazine, which I'll show you more of and there is a few in Codex that were used, some of which people don't have QuickTime version seven, which supports H264 and others support MPEG4 so.
So, capture, this is probably pretty basic stuff here, but we have been capturing on tape for the longest time. DVCam is sort of our major sort of standard these days, but nowadays we are moving into more digital acquisition. So we explored a few different options, in this front. The direct edit using what was called the 'Firestore', is a attachable piece of equipment that has a built in hard drive into it. I believe it's about forty gigs. We can store via fire wire directly. We can record lectures or anything for that matter, directly onto a hard drive in the QuickTime format and be able to go straight into the edit suite, hence direct to edit, to compress it, edit it and publish it.
We, also, explored direct to laptop solutions, bringing laptops in the field. We used various softwares, like QuickTime broadcaster, QuickTime pro, foulcup[sp] pro and Imovie, to various degrees of success and failure. We found that bringing a laptop in the field was, although sometimes it was very helpful, other times it was a bit more cumbersome then we had expected and we had issues with static electricity. We had issues with all the programs not specific to any of them, but we had certain issues that brought our success rate down, so we always made tape back-ups. There is still no substitute for having a tape back up. Something towards the end of this semester term, we started experimenting with was some new technologies that are allowing us to do direct to Podcast files. And it's a product by Neuros, which, essentially, takes any video and audio signal and we can plug it into our tape decks, and sit and such. We can record an MPEG4 Podcast ready files that we can, essentially, there is an SD card, actually, no it's a compact flash card, excuse me, that it records to. And you can plug that in and publish it immediately. Which is kind of pretty amazing.
And we started using that, the last four or five weeks of the semester, and we had quite a bit of success with it, so we are very excited about it. But things that we need to think about when we're doing this is what is the archival shelf life of some of these products. If we are just going to be doing a compact flash Neuros recording, we're not going to have a high quality back-up to tape unless we do that at the same time. So we're trying to do some simultaneous things and cover our bases for when we need to up converted for a later time.
These are some of the, we have probably gone over these a hundred times, but these are some of the standards that we've been exploring. The screen size is an issue in Podcast format, 320x240 is the standard, but we've also been pushing it a little bit further beyond that. With the magazine, Zigzag, we're trying to go as much to a like TV look high quality image look, as possible. So we've bumped up the resolution on that to 480x270, it is a widescreen format. We are able to make the play on iPods, as well as in ITunes, and Web browser.
One issue, also, frames per second affects your file size. Compression type, the two major flavors are H264 and MPEG4. And H264 gives you a better quality image but takes quite a bit longer to encode and compress, so that's one of the down sides of that. And then the wrapper that goes around the compressed files, there's MOV, M4B, and MPEG4, which is not, these are the three wrappers that ITunes can handle, essentially. I'm not going to go into a lot of detail about that, but we tend to use MOV just because it allows us to do the quick start, particularly with Zigzag. And then data rate, which is very important, is how it directly effects the quality of the image. So sort of the industry standard is 900 kbs, and we've been going with that for some of our content. But other things, like tutorials that Professor Louin does and 15053 and other things where there is not a lot of camera movement going on, we have explored reducing the rate down to as low as 500 and in some cases even lower. But we found that going lower than 500 was not entirely, the quality wasn't acceptable for us.
So we're constantly playing this game between file size versus quality. This is something that if you are going to be making your own files, you're going to constantly be battling. There are a lot of softwares out there that can help you with this. It's not, you don't have to be going into the real detail of making these settings yourself. There's a lot of standards that are set by Apple and by other software companies and programs that are here.
So these are just a few of the ones that we used during the test QuickTime pro, obviously, and they have a nice, if you're in a hurry and just need to compress an iPod compatible file, they have an export to iPod feature which is kind of nice because you do not even have to think about it, you actually can not make any changes to it, which is frustrating if you want to make those adjustments further. So you can with Apple compressor. You can actually make very specific adjustments in terms of the data rate, file size, frames per second, etc. ITunes is, also, just pretty much automatic, in terms of you open up the program, you tell it to convert the file to an iPod ready file and it does it in the background. Then there's a couple programs, third-party programs that we use Podmary and iSquint. They also do a very good job and they give you much more flexibility. I know that Sandy has also used some other programs.
Sandy Mallalieu: Yeah, but something that we run into, especially when we are trying to process things that are preexisting, that a lot of people run into. You don't you can't go back and find some sort of original tape, you do not have money or the time or something. We are dealing with a lot of real media files, which we found to be particularly difficult to find something to convert those with. And we found a piece of software by QQSoft, it's a video to iPod converter, that is terrific when you think about how many resources, saving in terms of you know people, time, money, all of that that you have to devote to possibly converting something that already exists in real, in particular. I literally sit at my desktop, I have got a Windows machine sitting next to me, and I just run the program pull in the files and I let it run for a couple of hours. It runs through all my videos that I have uploaded into it and spits them out as MP4 files and I can just add my Metadata to it, which we'll talk about in a bit, and then they are ready to go. So it is little to no effort on my part once I found the software, so it's something you can do very easily. And I know when we get into Metadata there are some other programs that we use, but that we found to be really helpful beyond sort of the standard compression file software programs.
Jeff Silva: So the Metadata is becoming increasingly important, as you just heard about in the other presentation. This is really key in something that we are trying to pay as much attention to as possible. So you know, in terms of tagging our videos, we've explored you can tag with QuickTime, you can tag with a variety of programs, but I've been using Metadata Hootenanny, and, which I love to say, and Tech station, also for chaptering. There is a couple of things about tagging in terms of information, copyright, description, etc. Which I am not going to go into a lot of detail but I will show you the programs.
Then there is also chaptering. This for us has been very attractive, because of some of our programs have had such long run times, like Walter Louin's Problem sets, for instance. We can segment the video, just adding chapters at different problem sets. And this way the student can just jump to and from what they need to learn and they don't have to sit through the entire video. They can just bounce around. I have used Hootenanny and Tech station for that and I think I'll show you, just briefly what those look like.
So this is MetaHoot here. So it allows you to, it takes the file name and you can change the display name here, add copyright, comment, artist, album, composer, creation and then even that it was encoded with the Neuros. And this is something that you have to do after you do the compression. What tends to happen is if you add Metadata to a file and then you compress it you'll lose that. And then you can see that, I don't know if I have chapters on here, but you can see that this is chapter just with general chapter one two three four five six that I believe are at about five or ten minute intervals these were created. It just allows you to flip through much quicker then you would otherwise. Yeah?
Man 1: Jeff, are you restricted to call them chapter one two three four five or can you call them anything you want?
Jeff Silva: You can call it anything you want. You can go to, well for instance, with Zigzag, the audio is off, but this was also created with Metadata Hootenanny and so these are named 'To 007', 'Highlights', 'Disco dance floor', 'Singing machine', etc. Just, I'm sorry, so you can call it whatever you want.
I'll show you, I think I have a file, with Metadata in it. What it creates is, it creates this track here inside QuickTime, a text track. That if I were to turn it on, I think it actually overlays on top, well actually it doesn't. But in any case it works behind the scenes and it adds this in. This is the chapter track right here. So it's kind of neat. And the Metadata, also, this one probably doesn't have Metadata, maybe it does. Yeah, so you can see that this is also listed here. The lecture, MIT, Chris, that's all in there.
Sandy Mallalieu: Something else that we use is also adding copyright information. So people know, too, you know the source URL where something came from and where you can find the rights of usage, especially because across MIT we have a wide array of usage rights that we assign to media.
Jeff Silva: Yeah, So, Tech station is just another program. The thing, Tech station is good for chaptering but it doesn't allow the other fields of Metadata. You can't add in the description, copyright and all that stuff. So you would have to do that in another program. What's good about Hootenanny is that it is all integrated. The thing about text station which is interesting is that you can actually create this HREF URL hotlinks. So I, you can click on a web video, and if you link a story that's associated with it, like we just did a disco dance floor segment, so if we wanted to create a hot link that you could click directly on the video, it will open a web browser and go directly to the link that we specify. We have been experimenting with it, but we haven't found it to be, you know, it's interesting, but we do not know how it fits in to what we are trying to accomplish at this time. One of the disadvantages is that the browser goes it up and usually immediately covers up your video, we want you to watch out videos, we don't want to cover our videos up.
Sandy Mallalieu: The other thing you run into is all these different programs I use, I use another sub-set of programs where you can enter in Metadata into the fields as they call them, and then you pull it into different applications like ITunes or something. Suddenly you will find that some things have disappeared, some things are in different fields. You definitely, you find the mediums by which you want to deliver, be it Google video or whatever, and ITunes or you know your web site.
You try and find a program that matches well with the kind of information or applications that you are using. So you can figure out a formula, and really hone sort of a work flow, so that you can quickly edit things and you are not doing a lot of work for nothing. And I think we have both been through a bunch of trial and error with our programs, and you use those or I use a program called Media Rage for a lot of Metadata and video, I find particularly useful. ID3X for audio Metadata and they all come with a myriad of fields. We have been sharing, we are happy to probably post somewhere what fields we use within them probably would be helpful to people so we can all share that and what applications we actually aim to deliver the content through as well. Because I do not know as well if the HREF hotlinks when you get into like ITunes, all the different ones then some things would disappear, not appear, and it gets a little crazy, you want to try little trial and error try a few files at first.
Jeff Silva: Yeah, even the chapters can disappear if, depending on the way that you do it bring it in to ITunes after the fact, I do not know if it works in the ITunes for you the other chaptering.
Sandy Mallalieu: Yeah there are some things they seem to be a little picky, yeah and what we were doing with ITunes is a totally seemingly different application or derivation of what you see on sort of the music store in standard piece, you know standard piece application from what is functionally possible. They even get into genres and all kinds of things that I think Rob's documentation on recommendations for different kinds of fields are really helpful and he translates a lot of those across applications. So his documentation helped us a lot too.
Jeff Silva: Yeah definitely. I will just speed through here. The final stage after we have our videos ready is to publish them. There's a lot of tools out there and what we used from the beginning was Iweb came out. Ilife06 came out and had this Iweb publishing. I have no web creation background. I'm a multimedia producer. I'm used to editing videos and producing videos, but not making web sites. So I was excited about this because it was always something I had to pass off to someone else to do. This gave me the opportunity to actually post and publish the videos when I was ready with them. And if it didn't, if things did not look right or work right I could make adjustments immediately and get instant feedback.
So the nice thing about Iweb, for me, was that it creates a basic video web log, you can stylize it a little bit, but it's very basic, no frills. It generates an RSS feed and every time you add new content, and you publish upload that content, it generates a new RSS feed. It can generate ID3 Metadata as well. So it's pretty easy to use, but it does have its limitations. And I can show you just a little bit about the interface for it. I have it somewhere. There it is. I am just going to have a blank page here but. So this is just one of the templates. It comes with several different templates but this is one of the standard ones that allows you to essentially type in the name of your Podcast, a little description. This would be you know lecture number one here. And then you can add entries. So that this you know would probably be lecture number one then you just drag your video directly in there. Then when the next lecture comes in, it's lecture number two, etc. I think you get the point. Very easy to use. Very user friendly.
And then it's just a matter of file publish to the folder that you have. you are connected to a server and it can be live immediately. On this area it allows you to change the name of your Podcast, so instead of calling it site, for instance, you can call it Zigzag, something like that. And then you can change all the subcategories as well. It also has information for, so you can change that to blog or something like that. Here is the RSS information. It's pretty basic stuff, but you can put Amps in here, your contact, your episode, artist, etc. All this information is there.
So this has been I think revolutionary for us. And although we are not using it for everything, and I think it is a little too simple for a lot of people in this room, it gets the job done certainly. Now for Zigzag, which is here this is designed by our web team Joanna Prool designs this. And this is a little bit more sophisticated. I submit the video to her and she publishes that, basically just changes the link and does all these hotlinks here, which are nice because they just go directly to the segments. I lost it. So that is that and let me get back to.
Sandy Mallalieu: Well, actually, with all the different kinds of things that we are going through in trial and error and all the pilots that we're doing, we are finding what is nice to think as an array of tools and things depending upon how much effort, time, money and all the experience you have there's a lot of interesting viable options. Which is really terrific and helps you really think about, too, learning a lot about the work flow you need for this and how minimal it can be in reality. If you think about ITunes, you think about how many Podcast are out there, they would not be able to be published if you couldn't figure out how to this in a pretty simple way. Really sharing all those kinds of things, your available, we are always available and anybody thinking about doing this, we can sort of share our work flow, as such. And it gives you, it creates a template that people can use. We are always interested in hearing what people are learning as they move along, find new applications, we're always interested in them too.
Jeff Silva: Yeah, it does seem like there are new applications coming out every month. Maybe even more than that. And I am constantly keeping an eye on it and trying it, but it's hard to keep up with it.
Sandy Mallalieu: Yeah, and too and when you actually talk about the different quality and what you actually encode too be it resolution or whatever, in trying to figure out with what kind of archival format you want to start with ideally, or you know whatever it is you have, it can come from preexisting or wherever. You know, keeping that somewhere and coming up with something, we found that the MPEG4 has been really flexible for us. So far we have not run into a situation where we have not been able to adapt that to something or even just use it, in it and of itself, seems to be working pretty well for us. Just because you know gadgets evolve applications evolve, as well.
Jeff Silva: So I'm going to show you a few examples of, actually, of various encodes, formats and styles. It is mostly just an excuse to show five video tracks at once because I think it's kind of, but I think it is pretty cool. Maybe it will crash my computer I really do not know we will see.
But in any case, these are five videos running, simultaneously here, hopefully and the one on top is the Neuros MP4. There's not a lot of settings on the Neuros, it is pretty much I think they call it basic and, the other one is like, economic. Those are the two settings.
[laughter]
And I believe this is on the economic setting this Neuros MP4 and it's a 320 x 240 signal. And this file was created in this room, in fact. You can see that the resolution is pretty good. You know it's readable anyway, but it is fuzzy. It does not look as nice as this one, which is an H264 compressed Podcast file which was using the direct attached storage that we had on the FS3. You can see that, clearly, things are a little bit sharper. Can you still read this? I think so. This is from tape not a lot different from here, it's using the same compression. These are all at about I believe 800k. These top three. I think all these are at 800k. This next one is H264 iPod preset form QuickTime. Now this is the tutorials that we shoot in the studio. This is Mike Metzger doing his tutorials. He's doing his own zooming there. That is captured, there's a camera that is hanging above our lighting grid pointing down onto his blank paper and he's going through his problems. Now this video feed goes straight into a laptop, just a Mac PowerBook. And this is capturing, at first we started capturing with Imovie, but it has a lot of limitations. It wasn't sufficient for our needs, we ended up needing to do a bit more editing than we expected. Particularly, with someone like Walter Louin, who is very detail-oriented and he will go through his video second by second and he will make a detailed list of edits that need to be made. Fortunately, for us he doesn't make a lot of mistakes, but it does happen from time to time. And so there has to be a lot of precision with the editing. We ended up moving to Final cut pro on both of these bottom presentations. And students were complaining, as you saw from Larry's presentation, that they wanted bigger screen size. They always want more, more, more. So we started moving towards creating 420x315 for Louin. And as you can see, you get more detail it's crisper. This actually we encoded with the Thrivex Codec, which is another thing we experimented with.
Sandy Mallalieu: Jeff, the actual file size in each of those formats what's the variation and how that impacts on download time?
Jeff Silva: Yeah, they range from about two to four hundred megabytes. So the file size does make a difference. It is a doubling of file size, but one of the advantages of being at MIT is that we don't have to worry about bandwidth too much. Since these are all for internal use, in theory, everyone has access to very high bandwidth. So this hasn't been an issue thus far. At least we have not received a lot of complaints about it. At first we created some early files that I think were 800 megs and we reduced those down pretty quickly.
Sandy Mallalieu: Because I know that we were running into from looking at what other schools have been posting. It is somewhere between 100 to 200 megs for an hour, which is what we are trying to stay with because we have basically the world is our audience. So we're trying to come up with something that they could deal with.
Jeff Silva: For our short form videos, so for, the other thing is you can look a this stuff in ITunes and you can scale them up, which is always nice. It frees you from that file size that's on the web. So for this, for Zigzag, for instance, you can detach it and scale this up as large as you want. And here's the, again, the chaptering. I do find that ITunes gets a little fussy about trying to play with the video files while it's playing, as you can see.
So this is a big difference in quality from what you saw in computation structures, but like I said I think it is still acceptable, it was acceptable to the students as well.
Man 1: Jeff, what about the other files, other formats that you worry offering as a part of this example?
Jeff Silva: Right that is a good question. So for Zigzag, this is going out to a mass audience. We have no idea what the en user, what the technology is going to be on the back ends. We are hoping to make this public to everyone and I believe episode four has multiple formats, let me check. Yes, it does. So here we have an MPEG4 version of the QuickTime, now we have an H264 version in case someone can't play an H264 file they should be able to play an MPEG4. We also have Windows Media, Bit Torrent, and Flash. So that pretty much covers all the bases. Then we have a large downloadable QuickTime file that ids your equivalent to a QuickTime movie trailer size, which full resolution, full screen, and also the equivalent in windows media and for those early adopters of cell phone videos, we also have that as an option. And this is a new thing we are just exploring now. And we're interested to see what the usage statistics are going to be when we out this together but now we are definitely focusing on what seems to be pretty standard and pretty widely accessible as H264 or MPEG4 compressions. But we do see that this has potential of being something that people might want to see full screen, they might want to blow it up to the full screen. So we're trying to keep the quality as high as possible. Let's see, what else do we have here?
Man 2: Regarding the windows media option, was that put in there because you got feedback from parts of your audience that did not want to install QuickTime on their PC?
Jeff Silva: No actually we put them in voluntarily just based on the idea that people would contact us. But we wanted this to be accessible to as many people as possible. So we thought it would be a good idea. We are kind of using it as an experiment to see what the usage statistics will be. We will gather those over the coming months. And if the demand is low for windows media then we'll phase it out but I don't expect that to be the case. We're also using it if you think about it in terms of as a portfolio of the different options we can provide. So we are not just creating movie files or real files, we're pretty much do the whole gambit of things.
Man 3: Jeff what is the difference between the quick start that we are looking at here as opposed to the one to the compatible synchronization for an iPod?
Jeff Silva: Ok, good question, there is a ringer in the audience here. So if you get the subscription to Zigzag, hopefully you all will if you haven't already. The file downloads in here and it's different from the one that plays off the web. The web browser file is a bit larger and a bit higher quality actually than what can play in here just by a little bit but hardly noticeable. These will play in your iPods. We had all kinds of trouble getting, like we just wanted to create one file initially so can play off the web one play in ITunes and play on an iPod. It became a struggle that we could not resolve. So it is possible to do but it's very difficult. Now we created a separate file that is identical except for the slight variation in terms of its compression. It plays perfectly in an iPod. Has anyone tried it ? No I just downloaded the last episode last night and it worked fine.
iPods can be plugged into televisions now, or video projectors and presented large, so we do see that as a way we are going to move. So we are going to create these higher resolution files for ZigZag, so that you can look at it on this tiny screen but you can also plug it in and project it larger and the quality will hold up.
Any other questions? We're starting to run down.
Woman 2: What are you using to get all the different formats that you are exporting to, FinalCut Pro or ..
Jeff Silva: If we are going to be editing a project we're almost exclusively using FinalCut Pro, so ZigZag is edited on FinalCut Pro and the files are exported out from there
Man 1: Were digital graphics cards used for encoding the files or do use the workstation....
Jeff Silva: I guess David would be the one to answer that. I believe that was encoded with the AnyStream, wasn't it ?
David: AnyStream or ..
Sandy Mallalieu: That's what you guys use for us
Jeff Silva: The web browser ones you've seen were encoded within the edit suite itself. Then the additional files which I didn't even show you were done with the DigitalRapids or AnyStream system which is an automated system.
I should mention our AMPS podcast team, because certainly I was not alone in this venture. Kevin Kirwin is some one who should be singled as some one who had to deal with the tutorial podcast working closely with Walter Lewin and Micheal Metzker. He shot and edited all of those himself. He had no previous editing background. He went from iMovie to FinalCut Pro and over the course of 3 or 4 months managed to pick that up pretty easily.
He's also been a podcasting R&D Guru from the very beginning. I used to share an office with him 3 or 4 years ago he was some one who always send me these emails, and tell me about these new developments in the web and RSS, and I was too busy to deal with it. And one day he comes into the office and it was about a year and a week ago, that Apple announced it's RSS integration into iTunes. And he was all excited about it, and I was what are you talking about? And then we started to look into it, and here we are a year later and of course it has taken off like he mentioned it would.
Lily Ladd was really working closely with me on editing ZigZag and all kinds of supporting other ventures. Craig Milanesi, was just all geared up to get involved in these podcasting experiments. And he did all the productions for 6.004 and 6.0034 which happened here. And he did all the switching and camera operating, and dealt with all the various technical challenges that where thrown at him from week to week when we were like "Oh lets try Broadcaster", "Oh lets try Final Cut Pro", "Lets try the Nueros" and he was right there, always gung ho for it. And Kevin Tierney who also did a lot of the encoding.
And Tom White was also heavily involved in doing a lot of these shootings and production supports. And also, incidentally, just ideas for ZigZag and shows, and hopefully all of you will have some ideas you want to pass our way. But Tom was just very enthusiastic about going out to the MIT Flea Market on Easter Morning and recording videos of the MIT Biolog WMBR radio show and things like that. He was really gung ho for it. So all these people are very much appreciated.
And I think that probably only leaves us with a little time left.... Does anyone have any questions?
Jane White: Any questions?
Jane White: Thanks everyone. And thanks to our panelists again.
Transcription by CastingWords