alternateEnclosures in RSS - why to do them
Let me help out Todd Cochrane from The New Media Show. Quizzed by Sam Sethi on why he wouldn’t do the alternateEnclosure tag on social media the other week, he’s now clarified his thinking on his show, which means I can understand his line of thinking a little more.
The podcast:alternateEnclosure tag exists in the new RSS namespace for a number of reasons, but the most important ones are:
- to offer seamless switching between audio and video
- to offer alternate bitrates/codecs for different devices
Todd starts by saying:
You got to walk in my shoe a mile here before you understand the reason why Blubrry is not going to, at least at this time, going to adopt the alternate enclosure tag. We have for the past 17 years encouraged podcasters to have one show per feed per content type, a.k.a. this show has a video podcast on a separate feed on Apple Podcasts and an audio podcast on Apple Podcasts.
And this is the problem to fix.
Having two feeds for the same show splits the “follow juice” between these two feeds, meaning the show appears lower than it needs to in Apple’s charts. It’s the same show - just an alternate file for it. Otherwise there’s no difference. So why split into two feeds?
Spotify’s podcast experience has it as one experience. You can watch the video if you want, or listen to the audio. The same for YouTube Music, where as you listen to a track, you can switch between the “song” or the “video”:
Use YouTube Music, for example, and when you turn off your phone’s screen, your phone automatically only gets the audio version of a track, because it knows you’re not watching the screen. This is good for listeners, because they aren’t paying for bandwidth they’re not using, and good for podcast companies like Todd’s, where bandwidth costs are some of the biggest.
So, putting “one show per feed per content type” is wrong. It ought to be “one show per feed”. Ideally. But, as Todd says, we’re not there yet.
You still need an audio feed and you still need a video feed because 30 of the 35 apps require one feed, one item, one enclosure.
Indeed. Actually, 28 out of the 35 apps require one feed, one item, one enclosure: but that’s fine. But - 28 out of the 35 apps don’t support “boostagrams”, but we seem quite happy to promote that!
I don’t mind building stuff for 3%. But I’m not building something for decimal of 1%. And that’s what you would be doing here.
Let’s not mention support for the live item tag!
If I’m going to go and tell a content creator that’s using my platform, all these things you’ve been doing these years are good. But now on your audio feed, I need you to add your video file as an alternate enclosure. And on your video file, I need you to add it as an audio enclosure. They’re going to go, “Why? Why am I doing this? Why do I need to do this? Why should I do this?”
Agreed. Why should they be doing anything? If you’re the podcast hosting company, you know the video filename and the audio filename for each show, this is up to the podcast hosting company to build the RSS feeds accordingly. This is the podcast hosting company’s job.
No need to confuse the content creator. If you know the video filename and the audio filename, just create the RSS feed automatically. Simple job. It’s what I do. It’s super-quick and super-simple.
The next argument was - Todd, you can put a lower quality audio file in your feed. So if you have a 128 kilobit audio file, you could set up an OGG. So you could set up a 64, 32, 16 kilobit bit rate. Been there. Done that. We did this in the United States when there was an actual issue with bandwidth. No one subscribed to those lower bandwidth feeds.
Well, no, you didn’t - you set up additional feeds with lower bitrate versions in them. That’s absolutely not the same as one feed with a choice.
Listen to the Podnews Daily, as one example, and you’ll probably be given a 112kbps mono MP3 file. But if your phone is aware of alternateEnclosures, you could be fed a 16kbps Opus file. Or even the video version.
This isn’t necessarily a choice your listener might make. Instead, your app could be configured to automatically download the 16kbps version if you’re on mobile data, and the “better one” on wifi.
This article on Podnews details the cost of mobile data in different countries back in 2019. In the US, a mid-range phone deal costs 1.8% of your annual salary. In the Philippines, it costs 17.3% of your annual salary. In Thailand, it’s 7.4%. Not everywhere works the same as the US for cheap data. (In Australia, it’s just 1%, by the way).
How does a podcast listener in a country that is bandwidth constrained, how do they know to pick which version of the audio file in the app to get a lower bandwidth? They don’t.
They do - because the specification asks for the bitrate of each alternateEnclosure, and a title for it.
But they also shouldn’t need to, because the app could make that choice for the listener anyway.
If I have to tell a podcast creator you need four versions of your file to support three or five listeners in another country, they’re not going to do it. They’re not going to do it.
Agreed, absolutely. But, again, you’re the podcast hosting company. When a podcaster uploads the main audio, produce a 16kbps version for them: it takes seconds to do. This is the line of Podnews’s publish script that produces it for me (automatically) from the master WAV:
ffmpeg -y -i podnews.wav -c:a libopus -ac 1 -b:a 16k podnews.opus
Why would you do that? Because a download of a 16kbps Opus version (supported by Chrome on desktop and Android, and supported by Android phones) will cost you, as a podcast hosting company, eight times less than a download of an 128kbps MP3 version. You want to save 87.5% from your bandwidth bill, I’d bet, even if it’s only for a small percentage of your downloads.
(Put the re-encoder on its own server, and give it a queue of new episodes to produce an Opus version; it needn’t be instantly generated).
And if I have to tell a podcaster now, you have to have more storage on your hosting account because you’re creating now four versions of a file. They’re just going to say, Todd, you’re milking more money from me because I need a, I need a bigger plan.
Not sure where the “four versions of a file” are coming from. Most podcast creators could happily get away with a 128kbps file for audio, plus a tiny 16kbps Opus file. That would increase their storage by just 8%.
And, of course, if they’re running a video version of their show in a separate feed, it costs nothing to add a pointer to that video in their audio feed as an alternateEnclosure.
Not all podcast hosts charge for storage, either.
I know what the percentage is of shows that have actual video podcast feeds and it’s pretty small to begin with. So it’s been, it’s been declining because of YouTube.
Correct: and it will continue to decline because of YouTube. So if the plan here is to let YouTube (or Spotify) walk away with all the video podcast business, that would be a mistake from my point of view.
So, today, you’ll spot these alternateEnclosures in Podnews’s RSS feed - and that’s why I think they’re a good idea.
<podcast:alternateEnclosure type="audio/aac" length="1651960" bitrate="64000" title="AAC">
<podcast:source uri="https://podnews.net/audio/podnews230331.m4a" />
</podcast:alternateEnclosure>
<podcast:alternateEnclosure type="audio/mpeg" length="1439309" bitrate="112000" default="true" title="MP3">
<podcast:source uri="https://podnews.net/audio/podnews230331.mp3" />
</podcast:alternateEnclosure>
<podcast:alternateEnclosure type="audio/opus" length="453637" bitrate="16000" title="Low bitrate Opus">
<podcast:source uri="https://podnews.net/audio/podnews230331.opus" />
</podcast:alternateEnclosure>
<podcast:alternateEnclosure type="video/mp4" length="14302474" bitrate="512000" title="Video">
<podcast:source uri="https://podnews.net/audio/podnews230331.mp4" />
</podcast:alternateEnclosure>
If I can do it… ;)