Introducing the Podlove Subscribe Button

The Podlove Subscribe Button — One button to subscribe them all

Podcasts are becoming more and more popular for many reasons – the subscription model being one of the more important ones. Automatic downloads make podcast content easy to access and flexible to use and create an important bond between creators and the audience.

However, to actually subscribe to a podcast has proven to be a confusing and error prone task. No more: because today, we are going to change all this with the introduction of the Podlove Subscribe Button.

The idea is simple: present one simple button that makes selecting a podcast feed and passing it along to your favourite podcast app (either on your computer, mobile phone or in the cloud) a no-brainer. To subscribe, your audience just clicks the Podlove Subscribe Button, selects an app and there is (usually) no step three.

One button to subscribe them all

Okay, so we say it’s simple. Let us walk you through this to prove our point.

On the podcast website, you see the Podlove Subscribe Button somewhere. We use the established term “subscribe” and the well-known generic Podcast logo (once popularised by Apple) to make clear this button is all about subscribing to a podcast and not to be confused with blog subscription which is a totally different thing for the user (although being technically similar).

That’s how the button looks up-close. Please note, the button comes in various sizes to be able to fit various contexts in web sites. We like the big smashy version that combines with podcast cover best:


Once you activate the button by clicking it, it displays a summary of what you are about to do. We do this to ensure you know what you are going to subscribe to. This is how this looks on an iPhone 5:


When you select “choose app” the button automatically detects the OS you are using and presents a list of well-known apps for that particular platform.


In this example, we choose to open the podcast in the Castro app for iOS which brings up the app’s subscription dialog window. Here you can review your decision once more and proceed to actually subscribe to the podcast (or cancel the process). Please note that some apps just go straight to subscribing to the podcast without asking. This depends on the App and can’t be influenced by us.


What if launching failed or if the app is not yet installed? Well, then you get some strange OS-dependent error, but the Podlove Subscribe Button still has you covered: you can retry or just proceed to the primary location to download/install/buy these chosen app (or go back and choose a different one).


Alternatively, you can change to the “Cloud” tab and get a list of web-based services where you can log in with your account and subscribe to the podcast there. This means you can actually subscribe to a podcast even if you are not using your or your primary podcast device.


In the rare case that you use an app that is not yet supported by the Subscribe Button, you can also choose “other app” and copy the usual feed URL that you can then manually transfer to the application. This is somehow still the tedious old way of doing it but at least there is a defined way how to present the URL to the user.


The button has been translated in many languages already and we will provide as many translations as the community is willing to contribute.

The button is hosted by Podlove and will silently be updated to accommodate for new or updated apps and services. Podcasters simply have to set up the button once and they’re set. When new podcasts app surface: we will include it. If new platforms become important: we will support it. When things break and change: we will take care of it.

Supported apps

As of today, the following apps and cloud backends are actively supported by the Podlove Subscribe Button (with more to follow):

Working with the developers

Behind the scenes we have been reaching out to almost every podcast app developer on every popular computing platform. We have pushed for simple changes to their apps (while many have been compatible from the start) and we have seen many small updates in the recent months to prepare for the launch of the Podlove Subscribe Button.

While we cover most of the current podcast app ecosphere, we are going to add new apps and services as long as they are compatible with the Podlove Subscribe Button. If you are a developer and your app is missing, please review our technical guidelines and contact us.

We provide extensive documentation on how to properly integrate with the Subscribe Button and there is also a fancy testing page to make sure your integration works the way it should.

Loose ends and future plans

Currently, the Podlove Subscribe Button only supports audio podcasts but we will extend it so that you can actually subscribe to video (and even ebook) podcasts as well soon.

We are also thinking about how to support explicit selection of specific formats (like MPEG-4 AAC, MP3, Vorbis, Opus) or feed variants (high and low quality versions etc.). Right now, we automatically choose the right format for you which should serve most customers properly.

There are some issues with new podcast websites that (understandably) go https-only as many podcast apps have problems dealing with podcast feeds via https properly and/or have just trouble subscribing to them once the Subscribe Button presents an actual https URL to them.

We are also working on a solution to make the button blend in more friendly in your web site design so that colours can be easily customised.

Paged Feeds for Podcasts

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.

Podlove Publisher 1.6

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.

Podlove Simple Chapters 1.2

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.

Updated Deep Link Specification

Following the final discussion on last weeks second Podlove Developer Meeting in Berlin, Germany, we have posted version 1.1 of the Podlove Deep Link specification that Podcasts can use to communicate to Podcast Clients that they are ready to accept direct addressing of time points and time ranges for immediate playback of certain areas in a given podcast media file using a web-based player.

We have changed the spec to adopt the syntax proposed in the new Media Fragments URI 1.0 (basic) specification as it perfectly fits our goals and we don’t want to invent the wheel twice. This puts this specification much more in line with upcoming web standards and should further the adoption by podcast clients.

The latest version of the Podlove Web Player supports this new addressing scheme and an upcoming version of the Podlove Publisher will add the proper link in all feeds.

Alternate Feeds

It’s reality today that podcast publish multiple feeds to support various media encodings or distribution methods but there is a lack of machine readable ways to grasp that information and present it to podcast users to check for alternatives.

So we published Podlove Alternate Feeds which is actually just a recomendation of how to use the standard link element from the Atom Syndication Format within a podcast feed.

But sometimes is the little things that make a difference.

Deep Linking

It is been a long-standing wish of the podcasting community to provide some means to easily link back to content on the web that consumers engage in on their playback devices. But a lack of standardization meant there was no defined way how to bring together podcast clients and podcast websites in that way.

That’s why we have put together the Podlove Deep Linking specification that explains how to easily extend your podcast feed to direct podcast clients back to the website and allow to automatically cue audio or video material to a certain point in time depending on the users selection.

If you incorporate that link information in your podcast feed, Podlove Deep Linking-enabled podcast clients can take advantage of that information to link back to your website allowing users to link to certain time ranges of your media content.

The first podcast client supporting deep linking is Instacast 2.0.



Bitlove is one our associated projects that has just been released online as an alpha version. Bitlove is a web-based service that converts any standard podcast feed to a BitTorrent feed with no extra work for the podcaster apart from adding the feed once to the system.

Everything else is done by Bitlove: files are being torrentified, seeded and tracked by Bitlove. Bitlove publishes a copy of the feed with links to the original files replaced with links to the torrent files to enable subscription with BT-capable clients like Miro or uTorrent.

Bitlove is a free service based on free software written in Erlang by Astro.