In a few months, we are hosting the next Podlove Podcaster Workshop in Berlin in May (3rd/4th). It will the third of its kind and the fifth Podlove Workshop in total so far. Target group for this workshop is podcasters and developers in Germany, Austria and Switzerland. So the event will be in German only.
Well, you might ask: “your website is in english, the plugin is in english and you present yourself in an international appeal – why is there no international event in english?”. Good question. Let me explain the reasoning behind this and how we want to proceed in the future.
We know we have embarked on a long trip here. Producing capable and stable software on the one hand and to create highly useful standards on the other side is no easy task. In order to achieve these goals, you need to build a strong community that is willing to test and use your stuff from the get-go and will provide quality feedback as you go along.
Being centred in Germany, this project decided to focus on the German speaking community first because this gives us the chance to deal with our initial growing pains in our native language and in a well-understood culture. It really helps. With our “local” workshops we also create new bonds among those who use the software and work with us on many technical levels. So far, this has worked really well for us.
But that doesn’t mean we are not open for anybody else. Our website, software, documentation and personal communication is all in Interlang (aka English). And we are really thinking about launching some kind of European conference in the near future. But before this will happen we want to have our strategy in place and our software in use by much more people outside the realm of the German language. Once we see enough interest, we might come up with something special.
However, this should not stop you from downloading and using our software, read into our specifications and open code and get in touch with us when you have questions, suggestions, criticism or if you want to offer your help. And in no way should you consider Podlove to be for Germans only, because it’s not.
In version 1.9 the Podlove Publisher featured a brand new “contributor” feature that allows podcasters to represent people and/or organisations in addition to all the other generic metadata of a podcast episode. Since the initial release we have provided 12 minor updates to the system and we have improved and extended the contributor feature in many ways.
It’s now possible to assign contributors to both episodes and the podcast itself. Using the “Contributor Settings” menu you can also set up a default set of contributors to be included with each episode. This makes it easy to list everybody who has contributed in any way to your work. For Podcasts, the most personal medium on the Internet, this makes a lot of sense.
But many of you might have been confused by the option to also create a list of “groups” and “roles” and assign either or both of them to contributors. What is this all about? Well, let me explain.
While many people (or groups of people) might contribute to your work, there is some demand to properly express what kind of contribution it actually is and to decide which kind of support to show where and how. With “groups” and “roles” we give you flexible building blocks to make this work for your case. While the first version came with a set of “default roles” we have made a step back and now deliver Podlove Publisher with no default settings for either groups or roles as everybody will probably have a different approach to this and it is next to impossible to define a default set that works for everyone.
So what is a group, what is a role?
Groups are meant to express division of work on a podcast. Good examples for groups might be the people who are actually visible/audible on the show (group: “On Air”) or the team that prepares the content (“editors”) or takes care of the technical setup to make everything work (“backstage”). Once grouped, you can select which group to actually show on your website using the “group” parameter for the [podlove-contributor-list] short code.
Roles are meant to actually describe what kind of role somebody plays within the podcast. You could set up roles for “moderation” or “guest”, there might be one for people providing “shownotes” or other things.
So by combining groups and roles you get a very powerful way to actually express contributions to your podcast. How you decide to use it is up to totally you. You can also ignore groups and/or roles and they will never show up in the user interfaces.
If you still have the set of default roles of our initial implementation show up in the roles list and you don’t know how to use them: delete all of them and create new ones once you think you could benefit from it.
We are still not done with Contributors. They are going to be the building blocks for some cool future features and in the next release you will see some significant improvements to the user interface too.
It’s been a while since the last major release but we have been busy behind the scenes and finally landed the 1.9 update of the Podlove Publisher and it’s a big one. Apart from a multitude of minor enhancements, bug fixes and improved behaviour, we have also some big new features we want to present and explain to you here.
We have been thinking a lot about the meta data that is needed and might be helpful for podcasts in the last two years. And there was a big weak spot in the current infrastructure. While podcasts are personal media with a very direct and intimate relationship between sender and receiver, the whole distribution architecture was just dealing with podcasts and episodes. It was all about the “medium” and not about people.
We intend to change this in a big way and today’s release is our first step in that regard. Release 1.9 includes a brand new contributor module. While you could assign people to episodes before, this time you can create individual profiles for each person, assign “roles”, use your own avatars and also link to the social media accounts and insert donation buttons (Flattr for a start, PayPal will come later).
People now also show up in the feed giving crawlers and podcast clients a chance to actually identify contributors across podcasts. And you get new shortcodes to make nice lists of people and more.
This is just the beginning. We have a lot of ideas and plan to expand this area significantly in upcoming releases.
We acknowledge there is a certain interest in protecting feeds with passwords. There are actually a lot of scenarios where this might make sense. But it is also a very complicated issue as everybody has its own ideas how to integrate with subsystems, databases etc.
So we are not presenting a real solution here but just put our toes in the water to get a basic functionality running: you can now put a general login/password on a feed or let people authenticate against the WordPress user database.
Depending on feedback, we might expand this feature in other directions but this needs to be rethought and discussed.
There a lot of other notable changes in this release: the new license selector makes choosing the right license for your podcast easy and you can decide to have a license setting on a per-episode basis if you need to.
The Expert Settings now allow you to configure temporary redirects in addition to permanent settings. Feeds are now delivered gzipped and you can define a global limit for the number of episodes.
And of course, we killed a lot of minor bugs.
More to come
There a bunch of other subsystems that is being worked at, both existing and new. Our roadmap is reaching out for into 2014 and hopefully beyond.
The advances of this year were made possible by the pretty successful crowdfunding which enabled us to pay one developer to spend a few days a week to work full time. Thanks to everybody who helped and will help in the future. We hope the quality of our code and ideas shows our appreciation.
Last week, we have release version 1.8 of the Podlove Publisher which is a substantial improvement to the things we recently added to version 1.7 of the software, specifically we put some more work into our integrations of App.net and Auphonic.
The App.net (ADN) posting service now supports setting a language annotation and cross-posting to a Patter room. Patter is the “chat rooms” of ADN and so you can now deliver your announcement to both the public timeline and a chat room, encouraging users to subscribe to the podcast’s chat room in addition or as an alternative to following the podcasts’ ADN account.
We are still exploring the possibilities with App.net and so these changes are just more toes being tipped in the pond to test the temperature. However, we think there is more to gain here which is why we keep investing in this module. We are now also listed in the official App.net directory.
Version 1.8 strongly enhances the integration with audio post-production service Auphonic. While release 1.7 allowed to import meta data from existing productions into Podlove, the new release now enables you to create productions with the information already typed into Podlove, to upload audio files directly to Auphonic, start productions remotely and get the results without ever having to go to the Auphonic web site at all.
You can select the source of the audio file for your production as you are used to with Auphonic: all the external services defined in your Auphonic account show up and so you can pass along media files via Dropbox, Amazon S3, SFTP or whatever you have configured to be a source.
But we also offer manual upload to Auphonic if your media file still resides on your computer. Please note that the manual upload actually passes the file directly to Auphonic. We are not uploading the file to your blog but take the direct route so that you are not missing out on speed or have to provide extra storage on your system. This is the very same experience you would have as when dealing directly with Auphonic with the only notable difference that you don’t have to go there at all.
When creating a production, we take most relevant metadata from the Publisher and pass it along to Auphonic: title, subtitle, summary, the episode media file slug, license and publisher information.
If you work with chapter marks we recommend switching to “manual entry” (instead of using assets as a chapter source) so that you can benefit from the new integration too. The Auphonic module takes your chapter information and puts it into the production too.
We are currently omitting tags as these are difficult to access within WordPress.
We also do not support podcast and episode images to be uploaded automatically. You should set the podcast image in your Auphonic preset where you also define the output files and other settings. You can select the preset to apply to the production in the Auphonic module settings after authorization.
If you want to add an episode image or set other fields like the track number, you need to open and edit the production with Auphonic before starting the production. We currently discuss how we can improve these things in the future.
But the new integration should make working with Auphonic a lot easier, less error-prone and result in a much more reliable and quicker workflow for podcasters.
On the July 8th, tech show “Podcast Squared” posted a new episode interviewing me about all things Podlove.
While we are busy producing more documentation in english including a longer series of screencasts to make setup and operation of podcasts with our tools easier, this interview might give you more insights into our general approach, how we see podcasting and what some of our future goals are.
Thanks to host Andrew Johnstone of Podcast Squared for the invitation. There is no better place to talk about podcasts than podcasts.
If you are running a show on podcasts or if you are interested in our work in general, feel free to contact us. We’d love to get in touch and explain what we do and what we are aiming for.
App.net (ADN) is a promising social network platform that seems to appeal to podcasters and podcast listeners alike and that has some potential for modern social media applications. Our module does just a few basic rather unexciting things: you can log in to you ADN account and the Publisher automatically create public posts pointing to a new episode when you release one. We have plans for more features for this plugin.
Auphonic is a web-based audio post-processing, metadata and encoding service that makes life for podcasters a lot easier. If you are not using it yet, you should strongly consider doing so. And that’s why we are going to integrate Auphonic deeply into the podcast production process (it’s still optional of course).
With this first release of the new Auphonic module (which is about to replace the now deprecated, experimental “Auphonic Production Data” plugin) we let you associate the Publisher with Auphonic by authenticating with your Auphonic user account.
You can then select recent Auphonic productions you have created and import all the metadata with one click. The system will extract the title, subtitle, summary, duration and the episode media file slug from the production. If you have configured the Publisher for manual entry of chapter information, the plugin also retrieves the chapter information from Auphonic if available.
If you have placed all those information in the media files by using Auphonic, it’s now super easy to transfer exactly the same data into your episode description. This should make posting new episodes even easier, less error-prone and also much faster at the same time.
Soon we will add the option to create new productions from your episode data too. This allows to follow a workflow that is defined by collecting all data in the Podlove Publisher first and passing this on to Auphonic. Having both production creation and import at your disposal opens up various workflows that are still easy to use.
This release won’t be the last to add significant new stuff to the Publisher. We are addressing a variety of areas to improve the overall publishing experience:
- Improve visibility of contributors in feeds and the website
- A versatile conflict management system to ensure podcast integrity to make system setup and maintenance much easier and reliable
- Generating statistics
- Improved web player with better UI and embedding capability
Look out for more great news as we move along. And if you feel like you are getting something out of this project, consider a donation. It really helps.
Accessing old content using podcast clients has been a problem for a while as podcasters are running into several real world problems when their feeds get too big. We have published an article that describes this problem and also comes up with an interesting solution: Paged Feeds.
And as we try to put the money where our mouth is, we have built-in support for Paged Feeds in the Podlove Publisher. When you set podcast feeds to include only a limited number of items, we automatically create multiple feed pages so that any client supporting paged feeds can still access older episodes going back to the very first episode (you know, the one, that never wanted to hear about again!).
We can also point you to the first podcast client that actually supports this method: Instacast for Mac crawls through every feed page presented to it. It’s a rather simple addition that makes a huge difference.
Put your podcast client of your choice to a test by “feeding” it with paged-feed-enabled podcast feeds and see if you see all or just a few episodes. And if you don’t, please point the developers to our recommendation make this happen.
The latest release of the Podlove Publisher finally comes with extensive support for chapter formats for both episode assets and podcast feed support. Although most of this stuff is buried under the hood and there are no visible changes to the UI, let us explain what has actually changed, why this is a big deal and where we want to move from here.
The Podlove Publisher has been focusing on extended metadata from the beginning and chapter marks have been of particular interest ever since because we strongly believe that timeline-related information is a way to significantly increase the value of podcasts for the audience.
We have some plans on how to integrate more of this kind of metadata in the future but we think simple chapter structures are a good start, are rather easy to author and using the Podlove Publisher that information is finally easy to broadcast to the clients too.
So far, the only way to bring chapter information to podcast clients was to use MPEG-4 media files (.mp4) and use tools like Garageband to embed Apple’s more or less proprietary “atoms” to put chapter marks, links and pictures into that files. The iPod (and later the iPhone) read these atoms and provided the chapter information to the user. So far, so good.
The problems were many: Apple’s format was (and remains) officially undocumented (although successfully reengineered), it was restricted to MPEG-4 files and the client needs to download the whole file before being able to present chapters to the user.
We want to ease this process, make it less dependent on proprietary formats and allow extraction of structural information before downloading the media files. The first result was the definition of the Podlove Simple Chapters specification. The next step is the deep integration of that format in the Podlove Publisher.
So what’s new?
So what does the update bring to the table? For a start, the Publisher can now read PSC files natively so that you can use PSC files as episode assets as a source for chapter timeline information. We support the all fields of the specification, including links and images. However, you have to wait until a future update to the Podlove Web Player that this information is passed through to the web page.
In addition to reading PSC format the full chapter information is now communicated in the podcast’s feeds to the client. Every client that is interested in chapter information can now retrieve it directly from the feed and use that information – even before downloading any media file. So the chapter information is totally independent of the media files and can be used by podcast directories, podcast search engines (like Poodle) or other apps without ever having to download any media file.
The Publisher also supports other chapter formats on input like the previously preferred mp4chaps format or WebVTT, but we really think PSC is the most robust way to go.
Partnering with Auphonic
Although the Podlove Publisher is totally independent from other systems we have been conspiring with the great audio web service Auphonic on many levels. We have a very basic integration of Auphonic in the Publisher right now (by reading metadata from Auphonic production files configured as episode assets) but want to integrate it even more as the usefulness of Auphonic for audio podcasting can’t praised enough.
Auphonic has also achieved a lot for podcast metadata behind the scenes: it’s the first service worldwide to actually implement chapter information for MP3 — which has been specified since 2006 — including links and pictures and they have also triggered standardization of chapter marks for Ogg files too.
And starting today, Auphonic offers an interface to add links and images to chapters, write these to all kinds of media files and to create Podlove Simple Chapters too. So if you are into creating high-value structured podcasts, the available infrastructure has improved significantly.
The future of the timeline
The Podlove Simple Chapter specification and its integration in the Podlove Publisher is just the start. Behind the scenes, we are discussing much more detailed metadata concepts to form the Podlove Timeline. But it’s too early to speak about this and we have decided to go forward with this rather simple approach that can make podcasts much better today.
Right now, we are asking podcast client developers to embrace the Podlove Simple Chapter format as a means to improve the experience of the audience and to make us all more independent from complex media file structures that are expensive to load and difficult to parse.
So go and try the Podlove Publisher and test if it suits your needs. We are certainly not addressing everyone’s needs yet but we are moving fast and we have a strong roadmap that will bring a lot more cool stuff to you soon.
We have updated the Podlove Simple Chapters specification (bumped to version 1.2) updating the syntax for time markers to follow the Normal Play Time (NPT) spec as it is defined by Real Time Streaming Protocol (RTSP) specification (RFC2326).
This does not change much for existing PSC files or implementations as the former specification defined a subset of NPT and is therefore 100% backwards compatible. However, if you are implmenting a PSC parser you should probably make sure time markers can be specified using NPT notation and to accept version “1.2″ in PSC files.
We have also converted the specifications to MultiMarkdown format and put it up on Github so you can easily set up pull requests to fix bugs, make the specification clearer or to enhance it in any other way.