Proposal: <podcast:alternatefeed> for alternate versions of the same show (Video, Audio, Low-bitrate, etc...

[mgdell]

Very similar to the podcast:alternateenclosure, but this new tag would be at the Channel level. This could be used to specify an RSS feed instead of an enclosure for a Video, Audio, Low Bitrate, alternate language and other versions of the podacst but in a separate RSS feed. This gives the option of doing a 2nd feed tied to the original feed for those who would rather do second feeds (or more) instead of by the episode using the podcast:alternateEnclosure tag.

I'm not a coder so I would need someone to provide the detailed code for this tag. I think it could be very simple.

[ryan-lp]

I wouldn't classify alternate language, audio/video and alternate bitrate as the same feature. I think audio/video and bitrate present different encodings of the exact same recording with the same transcript and chapters and the same item titles and descriptions, while alternate language would constitute a new recording with different transcripts and chapters, and different item titles and descriptions.

So I would classify these as two separate features with their own requirements. For the alternate audio/video or bitrate, I personally think alternateEnclosure is enough. It would complicate crawlers and indexers to have different structural ways of achieving the same thing. For example, it would be undesirable to crawl and index 10 feed entries for 10 different combinations of bitrate and audio/video variations all with identical titles and descriptions, that would be wasteful, and so extra effort would be needed by those coding the crawlers and indexers to merge the alternates into one entry. It would also potentially be more work for the podcaster to maintain 10 feeds all with identical item titles and descriptions, and more wasteful to store 10 feeds that are 95% identical in titles, descriptions and chapter/transcript links except for the enclosures.

For the alternate languages, the proposed feature could be justified. However I think it could be a helpful part of the proposal to reuse the same item guids for alternate feeds. If a podcast app provides a feature to show a menu of available alternative languages and then switch between them, and the user is currently viewing a particular episode, it would make sense for it to be able to find the corresponding episode in the other feed.

[jamescridland]

I would push back quite hard on this proposal, Mike, sorry.

The ideal should be one RSS feed for one show, which alternateEnclosure offers.

If you do a search for The New Media Show, you should find one entry in your podcatcher. When you open that, it should offer all the available versions for shows.

Having multiple RSS feeds for one show puts strain on directories to keep them all up to date; splits the equivalent of Google juice for podcasts making them harder to recommend or promote; and is just plain bad.

What I would like though is some form of metadata within the alternateEnclosure as to whether it's the same audio as the primary enclosure. That would enable any podcast app to mimic YouTube Music's "AUDIO / VIDEO" switch, as seen below - a simple way to switch between the video and audio versions. Currently we don't have metadata helping the app know that this is identical audio, or a different edit. Perhaps this is something for @agates to look at.

I'd agree that different languages is worth linking to. However, it looks like there is already a standard within RSS for this, and looks like:

<link rel="alternate" hreflang="en" type="application/rss+xml" title="English" href="https://domain/rss/">
<link rel="alternate" hreflang="uk" type="application/rss+xml" title="Ukranian" href="https://domain/ua/rss/">
<link rel="alternate" hreflang="ru" type="application/rss+xml" title="Russian" href="https://domain/ru/rss/">

Does that fix the issue?

[dhk2]

What I would like though is some form of metadata within the alternateEnclosure as to whether it's the same audio as the primary enclosure. That would enable any podcast app to mimic YouTube Music's "AUDIO / VIDEO" switch, as seen below - a simple way to switch between the video and audio versions. Currently we don't have metadata helping the app know that this is identical audio, or a different edit. Perhaps this is something for @agates to look at.

Seems to already be covered with 'rel'.

rel (optional) Provides a method of offering and/or grouping together different media elements. If not set, or set to "default", the media will be grouped with the enclosure and assumed to be an alternative to the enclosure's encoding/transport. This attribute can and should be the same for items with the same content encoded by different means. Should be limited to 32 characters for UX.

[jamescridland]

Seems to already be covered with 'rel'.

Oh yes! Thank you.

[geeknews]

Blubrry for many historical reasons, will "never" adopt alternate enclosure; over all podcasts on all podcast hosts for 19 years have been trained in 1 show = 1 enclosure per episode we are not adding a dynamic that shows have to do twice as much work to be able to support Apple and other platforms.

But we would be able to support a RemoteItem as a podcast:alternatefeed versus what Mike described as a podcast:alternateenclosure

The idea is you point at the alternate feed, and each could have a reason code

Video
Lower Bandwidth
Alternate Language
ETC.

We will be pushing hard for this adoption.

[geeknews]

James the reason we will never do Alternate Enclosures is simple. For podcasters with a Audio and Video podcast they still have to have two feeds no mater what. They have to have it for Apple etc I am not making podcasters do double the work.

AKA Podcasts still have to have two feeds for non-podcast 2.0 platforms and they are still in the high majority. Asking a podcaster to add an Audio file to his video feed as an alternate enclosure and add the video file to the audio feed is asking for trouble in screwing stuff up.

Again we will never adopt it. But we can support a RemoteItem; Podcast:Altternatefeed. because it does not break 18 years of how podcasting agreed and was adopted as one feed one enclosure.

[jamescridland]

over 100k shows have been trained in 1 show = 1 feed

Yep. My thoughts exactly. Not "1 show but available in two feeds, one with video and one with audio..." which is what you're pushing for.

The good news is that I don't make the rules. But I don't like the idea of having many different RSS feeds for the same show. That way madness lies, in my honest opinion - notwithstanding the point you make about Apple Podcasts not supporting the alternateEnclosure tag (yet).

[geeknews]

Apple will "never" support the alternate enclosure tag for a good reason. They want more listings, not less, in their directory. You will never hear them report a decline in the total number of podcasts in their directory. I'm not worried about Apple honestly I am more concerned about the 18 years of 1 show = 1 feed standard that was argued out long ago.

Not saying it was the correct argument but it was battled about long ago and is why things are the way there are now.

[agates]

Apple will never do a lot of things. Help those that will. This is not their sandbox.

[mgdell]

Right, but Apple does do video podcasts and Audio podcasts. 2 feeds. Why not give people a choice on how they want to do the same thing?

[jamescridland]

They want more listings, not less, in their directory. You will never hear them report a decline in the total number of podcasts in their directory.

Apple almost never comment on the number of podcasts in their directory. I doubt they care.

However, Apple does do everything for the user. The recent change in download behaviour was entirely driven by less battery life and less storage use (and had nothing to do with any discussions with the industry, despite claims made elsewhere). It is absolutely Apple's "thing" to make it easy for one show = one feed (and to offer the user the option of selecting video/audio within that feed). That's the right thing for the user.

There's absolutely no reason why you can't have a "master" podcast of "The New Media Show" which is MP3 but also contains the video as an alternateEnclosure; and then to add a "The New Media Show Video Version" if you really want to still be backwards compatible with backwards podcast apps. No need to block a proposal about alternateEnclosure; nor to fill directories up with badly duplicated material.

[geeknews]

Again, this is why we will never do this.

You're causing the podcaster to do twice the work podcast:alternateenclosure would allow them to be set it once and be forgotten and you do not cause the podcaster to double the work, and the apps that support alternate enclosures can now get it from one place or the other.

Everyone needs to start thinking like they are a brand new podcaster; if we are going to grow 2.0 adoption, this has to be seamless and not double work.

We are not blocking. We are not and never will adopt AlternateEnclosure that battle will not be won with us. But for those of us that have 19 years of teaching podcasters how to have an Audio and Video version of their show and to remain compatible with everyone else outside podcasting 2.0 we are not and never will cause podcasters more work when they don't need to.

[theDanielJLewis]

@geeknews's point is that alternate enclosures cause double the work. But it's also possible that separate feeds (for video versus audio) cause double the work. It all depends on the publishing system. PowerPress, for example, makes it easy to manage multiple feeds from a single WordPress post. But other publishing systems, like Libsyn, don't let you make multiple feeds with the same post.

Here's my suggestion for how to reconcile all of this.

1. @jamescridland pointed out the existing standard for dealing with different languages. So that seems settled, especially since different media languages need different text languages.
2. alternateEnclosure would be best for the same format (audio or video) but different encoding (MP3 and AAC, high bitrate and low bitrate, HD and SD, etc.). That makes me wonder if we should rename the tag for clarity. Like alternateEncoding.
3. <link rel="alternate" media="video" … /> would be best for linking from the audio feed to the separate video feed (and vice versa with setting it to media="audio" on the video feed).

[geeknews]

We still want to move forward with podcast:alternatefeed as part of a RemoteItem. This would allow us to kill two birds with one stone.

We can allow those with a separate Feed for video to link to that feed as a one-and-done for podcasters. This would be at the channel level.

[daveajones]

There is prior art for this with the podlove namespace here.

Could we offer anything new that it doesn’t? I’m not sure we can after reading it. I could be wrong though.

[mgdell]

I don't understand how this works, but most of us are not using the podlove namespace. Is it allowed to add that element into the "podcast" namespace as well?

[geeknews]

I do not want to declare the podlove namespace if this is covered under the podcasting 2.0 namespace so there cannot be two adoptions. I guess I do not understand either.

[mgdell]

Also, Alternate feed and Alternate enclosure can co-exist. I don't see a problem.

[theDanielJLewis]

Podlove was merely proposing a method that using existing RSS stands with a <link> tag. It's not outside the scope of normal RSS, but more like a define way to do alternate feeds with the RSS spec.