Welcome to Libsyn3 -- Getting Started

• destination-based publishing engine (including separate release windows for each destination)
• smart media conversion for optimal compatibility and quality
• improved Wizzard Player™ integration with new Audio Mode
• TubeMogul™ integration with release scheduling to YouTube and dozens of other social video sites
• improved statistical reporting (including geographic breakouts)
• new ad slot selector tool for precision ad placement in audio and video content
• support for multiple media file types per episode
• support for unlimited number of RSS feeds & players per show
• Application and Platform based ad targeting (including iTunes, iPhone, and iPod Touch platforms)
• Redesigned AJAX publishing UI with improved publishing workflow, background uploading, and integrated help system (including real-time chat support)
• Redesigned advertising campaign manager

The libsyn[PRO]3 system is based around a completely redesigned publishing engine which is capable of formatting, trans-coding, and delivering content specially suited for various destinations. A destination is a physical (or virtual) place to publish your content to. In the Podcasting world, you can think of iTunes (or more specifically your iTunes RSS feed) as a destination. If you desire, you can configure another destination for something like Zune Marketplace, or Boxee, or any place else you might register an RSS feed. Breaking your feeds out that way allows you to then publish specific content to each place, or release episodes at different time windows quickly and easily from inside the publishing interface.

RSS feeds are just one type of publishing destination. Wizzard flash players are another. Once you embed a player on a website, you have essentially created a node (or destination) in a great publishing network which you can then “send” episodes to. Just like feeds, you can create as many separate players as you like and embed them, hand them out to distribution partners, etc all around the Internet. Then, come publish time for your next episode, strategically distribute your content to your network of publishing destinations with just a few clicks of checkboxes.

The third type of destination is a 3rd party external, or API-based destination. These are popular web services which either publish or consume media content. The first of many third party destinations planned for libsyn[PRO]3 is the social video site wrangler, TubeMogul. Through our partnership with TubeMogul, you are able to publish video content to dozens of video sharing websites like YouTube, Vimeo, Blip.tv, etc. Just as with all publishing destinations, you can time the release of each episode so that it maximizes your ability to draw a crowd to a particular media outlet and also reach the widest audience possible.

You may choose to setup release windows such that the new episode is first available on your website (via an embedded Wizzard player), and then a few days later is sent to your iTunes audience, and then next week shows up in your YouTube channel and 20 other social video sites. Or you may have a distribution partnership with an exclusive blog or website and have agreed to debut content on their site. You can create a customized player for them and then delay the public release to the rest of the Internet for a few days or a week. The options are almost unlimited and the power is yours to create the release schedule that works for you. It's very simple to do and fun to track your contents performance through the newly revamped statistical reports.

The libsyn[PRO]3 producer section is totally new. Like the publishing engine it controls, it has been built to elegantly expose the power of the destination release system combining several key components:

• Media content conversion
• Managing multiple pieces of content in each episode
• Scheduling delivery to multiple destinations
• Setting up in-stream advertising
• Tracking audience consumption

Each of these components have their own place within the web application. By taking pageloads out of the UI (100% AJAX based web app) allows for a seamless linear or non-linear navigation through all sections- even while uploading multiple large media files. It feels more like working with a native desktop application then a traditional top-down website.

The user interface is broken up into 6 areas. Each area contains upfront tutorials as well as integrated help to assist you wherever you need it. If you still need some extra TLC, there is a persistent Help link in the bottom left which can open a real-time chat with a live libsyn[PRO] support person (M-F 9am-9pm EST, if available)

The producers dashboard is the first thing users see when they login. It contains any of a number of widgets which allows users to select the show they would like to publish to (if they have many), create new shows (if they have permission), see the status of any episodes awaiting approval from Quality Control, see an quick snapshot of their stats (coming soon), and view comments and messages from the network admins (coming soon) and audience feedback (coming soon). The dashboard is accessible via the show icon in the upper left corner.

Each of the following 4 sections have a consistent layout containing a narrow navigation column on the left and a wider workspace panel on the right. The initial view when entering each section is a splash screen providing an overview and some tutorial information about that section. If you move to another section and then move back, the state you left the section will be restored. For example, if in the middle of publishing an episode you switch context to check a stats report and then switch back the new episode form will be exactly as you left it. Wherever possible, lists are searchable and sortable to make it easy to find things quickly.

The publishing section is where users create new episodes, get direct download URLs for published content, manage unpublished content, and get embed code and view the status of all episodes. This is the heart of the producer interface where most of the work is going to be done.

All Episodes view gives access to all the published episodes where you can view, modify, or delete single episodes or batches of multiple. You can also quickly grab embed codes for web players for any episode. If there are issues with the release of any episode, it should be readily apparent from this view as well.

Unpublished media view allows you to see all files that were batch uploaded via FTP- but not yet published. The files can be previewed or deleted from this view.

Creating (or editing) episodes launches the 5-step publishing workflow. The process can be performed in any order, however new users should follow the wizard in order to ensure no steps are missed. The steps are as follows:

 1. Select media
 2. Describe content
 3. Set destination release schedule 
 4. Configure advertising options
 5. Review and Publish 

Step 1. Selecting the file(s) to be published together for a single episode is the first step in the process. It is recommended that you do this first as you can save some time by allowing the content to be uploaded in the background while you perform the other steps in the process. You may mix a combination of files uploaded via FTP and those uploaded right here through the publishing web interface. *Important: If you upload multiple files, they must be exact copies of the same content just in different formats. An example would be a H.264 MPEG4 video file and an FLV version of the same video. Here is a good place to talk about “master files” and media trans-coding. The first file which you select is the “master file” for this episode. This should be the highest quality file you are going to include. Any trans-coded variations will be derived from this file. You can stop after the master file and let the libsyn smart encoding system handle the rest. But if you are perfectionist and want to use your own hand encoded files for each format, you are free to do so.

What drives the various formats which are required are the publishing destinations selected for the episode. Each destination can required a variety of formats for different devices or consumer situations. The classic example of this is the wizzard player which utilizes high quality, low quality and HD quality video files depending on the end users capabilities. The files it uses are a mix between FLV flash video and H.264 MPEG4 video codecs. If you simply uploaded 1 video, if it satisfies the requirements for the high or HD quality roles, the other variations will be trans-coded for you. If you would rather upload all 3 variations, you can as well.

You can select files, swap around the Master and secondary files, add or remove files all from step 1 section. As soon as you click to another step, the uploads begin and you cannot cancel the uploads w/o discarding all the changes to the entire episode. This is a known limitation which is being addressed.

Step 2. In this step you describe the content or provide all the meta-data for the episode. Title, description, tags, category, etc. The description, or “show notes” section can be entered in HTML rich text- however at this time on a stripped down text only version is used in RSS feeds. Future web-centric destinations will take advantage of the full HTML versions you create. At the minimum, a title is required to publish the episode live.

A custom thumbnail for the episode can be selected on this step as well. If the master content you selected in step 1 is a video file, the system will attempt to pull up to 5 frames from the video stream. (Currently, one of the frames will be selected and there is no way to select from the other 4 that are pulled. This is a known limitation which is being addressed.) Regardless of any system generated thumbnails, if you upload a custom one, it will be used for this episode.

TV-style content ratings currently have no function other then documenting the catalogue of episodes and assist third party ad networks in selecting appropriate material (should you choose to participate in those advertising initiatives). Future plans are to include rating markers in web players, provide the ratings to other systems through the RSS feeds, display appropriate disclaimers on websites, etc. The bottom line is that you should get in the habit of using them now.

Step 3. This step could be very very simple, or quite complicated depending on your needs. Most users will chose to skip right over this step and only make changes to the default settings for rare occasional special content situations. One very simple modification many users may do is to simply uncheck one or more destinations. A good example of this is a special web-only episode or announcement which you do not want sent to iTunes in your RSS feed. For advanced users who need the controls, this episode can be released and expire at a different dates and times creating windows where your content will be made available to various publishing destinations.

Step 4. This is another step which will be crucial to many users and completely skipped by others. There are 3 parts to setting up advertising for this episode- enabling it to allow dynamic ads at all, selecting the commercial break points or “ad slots”, and including this episode in any of the various episode filters already setup. *Important- By enabling an episode for dynamic ads doesn't automatically start putting ads in your content. The show needs to be setup in a running ad campaign for this to happen. Discuss this with your network administrator or libsyn/wizzard media representative to learn more.

By making it available for ads, you are allowing pre-roll and post-roll ads to be run on this episode. If the master file is still uploading when you get to this step, you can only enter the mid-roll ad slots manually by clicking the (+) button and typing in the time codes. If the master file as already been uploaded, you will be assisted by a playback tool which allows you to mark slots, drag them around, and preview the breakpoints live in the audio or video content.

Episode filters are basically subsets of episodes from your show which have been put together in a collection for the purpose of running a campaign either only on that set (a white list filter) or on everything except that set (a black list filter). The filters are setup under the main Advertising section- the checkboxes which appear in this step are only to add this episode to any of those filters. If you decide to setup a new filter at this point, simply click the advertising section, save the new filter and switch back to the publishing section. Don't worry, you won't lose any changes in the switch! When you return, click the refresh icon on the bottom of the list of filters and the new one will appear. A useful example of episode filters and step 4 of publishing workflow is the scenario where you have a black list setup to ban any episode which contains explicit language in an ad campaign that is currently running. This episode you are about to publish has explicit language so you want essentially say “include this episode in the black list filter too.” This ensures that no ads are delivered in this content between the time you publish and going to the advertising section, editing the filter, and adding the episode then.

Step 5. The review. You've made it through all the steps and are ready to publish the episode live. This screen is like the shopping cart review prior to checkout. There are a few last minute options before you click the big green PUBLISH button though. Now is a good time to talk about quality control. There are 2 forms of QC built into libsyn[PRO]3 publishing. One is informal and personal, the other is a more rigid process involving other people in your organization.

The informal QC check is simply an extra step put into the process which requires the file upload to complete before the publish button could be pushed and the episode made live. This is gently force you to preview the content and review what you have written and your selected for publishing options. This of course can be bypassed by clicking the checkbox “Automatically publish when upload completes ” which unlocks the publish button allowing you to walk away and trust that everything will be fine when the upload is done.

The formal QC process involves using the libsynPRO quality control system. If you do not have the system permission which allows you to publish content live, you don't have a choice in the matter- everything you publish will go through the QC system before it's made live. If you do have the permission to publish directly, you can still choose to enable the quality control check for this episode by clicking the checkbox marked “Submit to quality control.” A good example of this feature coming in handy would be if you were part of a group of users all working for the same organization and you were somewhat unsure about a particular episode or section of the content. Sure, you can publish it and live with the potential embarrassment of a sloppy jump-cut or typo in your show notes- or you can force the episode to be reviewed by one of your peers first. The choice is yours (if your network admin says it is).

The episode notes option goes hand in hand with the formal QC process. If you submit to QC you can tack on a message to the reviewer if you like. It will not be made public anywhere, so don't worry.

Now is a good time to discuss draft mode. At any point up until step 5 there was a gray DRAFT button sitting at the end of the directional arrows- just begging you to click him. Once you reached step 5, the draft button has stepped aside making room for the big green PUBLISH button. Don't worry, draft is still there if you need him. If you aren't ready yet to pull the trigger and publish your episode live, saving it as a draft keeps everything as it was the next time you come back. Obviously, if you save as draft during the middle of an upload, then close your browser or logout of libsynPRO, the partial file will be discarded and you will have to upload the whole thing when you edit the draft later.

If you are ready to go, clicking the PUBLISH button will set everything into motion. It may take several minutes to process the episode if there are many publishing destinations involved. You can click around other parts of the publishing UI while this is going on, but don't leave the page/app until it's completed.

Post publish / Episode view screen After the episode has been published or if you click 'more' from the all episodes list, a read-only view of the episode- similar to step 5 of the publishing process is displayed. Now is a good time to talk about “releases.” A release is simply the result of an episode being published to a destination. If you think of it in terms of a film which is released to the box office, and then released on DVD, and then 2 years later has it's network TV debut- the same thing is happening here. You can simultaneously release the episode to as many destinations as you have configured, or you can create those timed release windows we've been talking about. From this screen you can see all the releases and their status, get embed code or direct download URLs for the content, view technical details about the files, etc.

And that's all there is too it. Who knew uploading a file could be so easy?

The statistics reports currently available contain a great deal of details about the audience downloading your media files, and very shallow report on the playback performance captured from the web media players. This is a known issue that is being addressed. A much more robust player report is coming soon along with a coherent method to combine the 2 reports together to get a grand view of your audience. Currently, there are 2 reports: the download report and the playback report.

The download report tracks exactly that- the amount of downloads each file has gotten. Now is a good time to touch on the “libsyn publishing hierarchy” We have spent years modeling the abstract concepts behind podcasting, and the media world in general, and have devised the following relationship. One or more media files (content) make up an episode (or item). One or more episodes/items make up a show. One or more shows make up a network. This relationship is depicted exactly in the download reports. As a producer, you come in at the show level. You can see the download trends, a geographic breakout, and look at how all the ways your audience is getting your show. Then you can drill down to an episode, and where relevant look at one file vs another in that episode. As an admin, you can bubble up to the network level and see across all shows.

The playback report simply displays the start plays and completed playback for each episode in a show and the totals across all episode. There is currently no admin-network level view for playback data. As stated above, we are working (very hard) on that .

The statistic reporting is near-realtime; as near as we can get it. After doing this for a 5 years, we found out that other people's “near real-time” means “more then once per day”. While we have had our share of problems in the past, we strive for more then once an hour. There's a lot of processing that goes into these reports, so please don't hold us to that. Also, please don't open support tickets if the freshness date on your report is from 25 minutes ago and “yesterday the reports updated every 15 minutes.”

Q: Where are MY geographic reports? A: Many of the features mentioned above are only available on our brand new, super powered stats system. Since this is the maiden voyage of that system, we have kept the legacy system running in parallel while we let the new one run under production load and delivering reports to beta users for a while. If you want to be part of that group of beta users, please contact your network administrator or libsynPRO / Wizzard Media account rep.

In general, the new stats section is just the tip of what is coming in terms of reporting capabilities. We are collecting tons of information, processing even more, and reporting out a decent but still relatively small amount of information.

This section is currently only a small subset of what it will be in the near future. Eventually, here is where producers will opt their show into various programs and campaigns, manage paper work for Wizzard Media and 3rd party partner programs, and view how their show did in campaign reports. Right now, this is where you can setup and manage episode filters and also quickly jump through all the episodes in a show setting up ad slots.

The destination section is where you can setup multiple feeds, players, and other publishing destinations. This is also where TubeMogul can be configured. We were this close to making the TM integration really tight, and they kinda jammed us up on at the last minute. The result is a kinda messy series of pop-up windows and a fair amount of hand holding is probably needed to navigate users through the process. Now is a good time to talk about content, roles, role filters, and media formats. If you are not a power user, skip this section.

All the media files you publish for your show is called content. When you first upload content, it's sent though a media scanner which extracts as much meta data as we possibly can form it. During that process, a format is assigned. The format tells us technical details about the file- codec, bitrates, frame size, etc, etc. All those technical bits can be used to select out of a pool of content assigned to a specific episode the right file to use for a specific purpose. That “purpose” is what we call a role. A role is simply “what is this piece of content going to be used for at/in this destination” A perfect example is an lower-res FLV video file is used for the “Wizzard PLayer Low quality” role. Roles have common names and to the end user, they may think of them more as formats (in a general meaning of the word). To the public, format is a pretty fast and loose term, so try not to get lost in the nuance of how the libsyn system uses the word format. What a user would call a format, we likely will be calling a role. What we call a format is very specific. This all comes together (roles and formats) via the role filter. A role filter is the specific rules by which a role is selected. They can be very specific or very broad. A specific role filter could be something like :must be h.264 video codec, must have frame width ⇐ 640px, must have bit-rate between 11000 and 128000, etc, etc. Or it could be broad like “must be a video file”. We have come up with about a dozen stock roles with role filters that make the most sense to us now.

The beauty of this system is how fluid it is to adapt changes and improvements in capabilities and quality. End users currently have some controls over what roles are used in a destination, but they cannot yet create their own role filters. The last bit worth discussing about this is conversion [transcoding] and “required roles”. Trans-coding is when we take a master file and send it through the A.R.M.E.N. system to make an alternate version of that file. When roles are assigned to a destination, there are 2 additional options: required, and transcode. By making a role required, it means that the episode will not be published to that destination until the required role's role filter is satisfied. An example of this would be if you wanted to delay publishing a new episode to the player until the low-res version was done converting. That's NOT the default behavior currently, but a user could enable that. There will be more things in the future that will rely on specific formats which may not be what the user uploads, so we'll want to require transcoding to complete before we send it off. When a role has the transcode box checked, that means that if the role-filter is not satisfied, we will attempt to transcode the master file. Every role that allows transcoding has a special “recipe” assigned to it which tells A.R.M.E.N. what settings to use to make the best file for the job. This currently is not something the user can mess with, but there is talks of allowing for custom conversion formats in the future. That is a super-power user feature, but could allow for some pretty rapid adoption of new devices, formats, etc. Oh, and the order in which roles are assigned matters for some destinations. Right now, it only matters for podcast feeds, which i'll explain in a minute. *Important- Currently, media files are NOT transcoded between media types. So that means despite what options are selected, if you have an audio role set to transcode, and you upload a video, the audio format will not be transcoded, and vice-versa. That will change in the future allowing users to upload video and make an MP3 feed, or upload audio and mix it with their thumbnails and publish to YouTube (for example).

Podcast Feed Destinations

The podcast feed form is pretty self-explanatory. The only gotcha comes at the end where you choose options for media transcoding. By default we have the “most compatible” set of options pre selected. What that translates to in format/role/role-filter language is an RSS feed destination which will accept MP3 content, iPod Video content, or PDFs. Both MP3 and iPod Video roles have the transcode option set. So how that works is like this: the file that you upload fits into the iPod (if video*) or MP3 (if audio*) role filters. if that's the case, no transcoding happens since it fullfills the role. However, lets say you uploading a .wmv file- a H.264 .m4v file will be transcoded since that's what the iPod VIdeo role's designated format recipe told A.R.M.E.N. what to do. Still with me? Remember (*) this because of the “don't cross the media type” rule.

The other options for media transcoding are “off (no transcoding” where whatever you upload is what goes into the feed (also referred to as “libsyn classic” mode), and iTunes AppleTV HD. The AppleTV presets will accept any iPod Video, 540p HD video, or 720p HD video - since that's what the AppleTV device supports. It's useful to setup one of these feeds if you do an HD show and also want to maintain a seperate feed for iPod/iPhone users. This preset will transcode all videos uploaded to 540p -even if the file is not HD. This is a known issue and is being improved up for a future release.

Here's a good time to discuss role ordering. When a destination can only take 1 file (in the case of standard RSS feeds that only have/use an enclosure tag -as iTunes does) we have to know which one to use in case there are multiple files which satisfy multiple roles. The way we know is by role order. This is important in the case of AppleTV HD feeds especially since each destination does not work in isolation- but instead all destinations pull from the same pool of content for a given episode. Let me break it down: The user uploads a 720p HD video for the master file- publishes to the wizzard player destination and their AppleTV feed. An iPod Video formatted file will be transcoded for the player to use. Now, if the role order was messed up for the AppleTV destination, then when that iPod Video was ready (since it is also an option for the AppleTV feed) it would get used in the enclosure tag instead of the proper, original HD file. However, since the role order puts the HD file on top, it trumps the iPod video so even if one gets made for another destination, it won't interfere with the AppleTV feed's HD file.

Luckily no user needs to really worry about this, and for those who want to, there aren't many options yet. It'll be important for everyone on our team to understand at least at this level what is going on for troubleshooting and Q&A with users. It's only going to get better going forward once transcoding can be based on rules (similar to role filters) instead of just a simple true|false that it is now.

Wizzard Play Destinations

This is where users setup players. New options include the ability to override the flash player check and default it to a given quality level and the option enable iPhone support inside the options.

TubeMogul Destinations

As stated above, this is cool but kinda obnoxious in terms of the embeded iFrame in a popup window. The only real issue, to be fair, is that you have to click “submit” inside the windo, then click 'Close' on the outside window, then click Save on the internal destination setup form. Good news is users won't have to do it more then once- bad news is it might be too overwhelming for anyone to even try just once.

The show settings and account preference are accessed differently from the other sections of the UI. Show settings are available from a gears button next to the show icon in the upper left and can be accessed at any time. The setting window “pulls down” like a drawer overlaying whatever screen you are working on at the time. Account settings are the same, and available by clicking the silhouette shadow icon in the upper right. In the future, the account settings section will expand to include billing information, usage reports, avatar uploading, etc.

The show settings has pretty self explanatory fields, with the only one requiring more details being the Default Show Feed field. With all this talk of multple this and unlimited feeds that, what is the “default” show feed? Well, its the primary feed you would give someone if they asked you “what's your RSS feed url?”. Chances are the most multi-tasked user there is would still come up with a single answer. Any question this field answers might be “what feed would/did you submit to iTunes?” since that's typically the show's main feed. The options are a drop down of all Podcast RSS Feeds setup for this show or an option for a custom 3rd party URL which then exposes a text field to type in the feed. This is useful if people have a feedbuner url or something else they want to direct traffic to. The #1 use of this field right now is in the web player. When users click the subscribe> RSS button, the value they enter in this form will be used. Settings + Account Preferences

The show settings and account preference are accessed differently from the other sections of the UI. Show settings are available from a gears button next to the show icon in the upper left and can be accessed at any time. The setting window “pulls down” like a drawer overlaying whatever screen you are working on at the time. Account settings are the same, and available by clicking the silhouette shadow icon in the upper right. In the future, the account settings section will expand to include billing information, usage reports, avatar uploading, etc.

The show settings has pretty self explanatory fields, with the only one requiring more details being the Default Show Feed field. With all this talk of multple this and unlimited feeds that, what is the “default” show feed? Well, its the primary feed you would give someone if they asked you “what's your RSS feed url?”. Chances are the most multi-tasked user there is would still come up with a single answer. Any question this field answers might be “what feed would/did you submit to iTunes?” since that's typically the show's main feed. The options are a drop down of all Podcast RSS Feeds setup for this show or an option for a custom 3rd party URL which then exposes a text field to type in the feed. This is useful if people have a feedbuner url or something else they want to direct traffic to. The #1 use of this field right now is in the web player. When users click the subscribe> RSS button, the value they enter in this form will be used.