Namespace update - We now have the following:

- transfer locking (formalized)
- owner verification (formalized)
- transcripts (formalized)
- captions (formalized)
- location
- chapters
- platform/directory id's
- funding/donation links
- alternate enclosures
- guest/host bio information
- multiple image sizes
- contact info

All in a very small and efficient spec so far. This is looking great. Thanks to @tomrossi7 for writing the declaration for these as we finish them. Onward!

· · Web · 4 · 2 · 10

@dave @tomrossi7 that’s a great start! I think it really addresses everyone’s needs. Now let’s get adoption from various hosting companies! @Todd_Blubrry are you in?

@mikek999 @dave @tomrossi7 Obviously having internal discussions with my team. Was hoping Angelo would find time to pop in here to provide some input.

@dave you already have chapters? Can you give me a link where they are described so I can double check?

@adam @dave

Thanks, AC,

Chapter part looks good👍

So No need for me to submit any more proposals.

In future I’ll research extracting outlines from shownotes (like in Lex Fridman podcast) to chapters.

Extracting chapters from MP3 in web players - that’s challenge that might be solved by crowdsourcing - I’ll think about it too later.

@csb @adam @dave I was looking at implementing chapters for Buzzsprout, but got cold feet @theDanielJLewis have you considered the impact on RSS feed size and speed?

@csb @adam @dave @theDanielJLewis I love the chapters spec and think its the right move, we may just want to wait until we can collaborate with an aggregator that will expose some new functionality to warrant the performance hit and additional cost.

@tomrossi7 @csb @dave @theDanielJLewis We have at least five app developers here that can implement this right away. What “aggregators” are you referencing? All we need is one implementation. We’ve been waiting for 10 years for a namespace to be written. The time for action is now. If it doesn’t work, because nobody tries it, then we remove it from the document for the next round of refinements.

@adam @csb @dave @theDanielJLewis absolutely! I was just talking about the chapter markers. Buzzsprout is going to focus on the locking mechanism next since that is *new* functionality.

@adam @tomrossi7 @csb @dave @theDanielJLewis Re: Chapter Markers, we have a working implementation for that today that is widely supported (embedded in the MP3). I'm not saying it can't be improved, but it doesn't feel like the most important thing right now.

@kfinn @adam @tomrossi7 @csb @theDanielJLewis We can always punt that to phase 2 if needed.

I can go ahead and start proving out some of these things in the real world with the PI aggregator so we can see how they perform.

When we record Podcasting 2.0 tomorrow I'll clone the feed to a new experimental feed and drop it in the aggregator, then start putting in some of the new tags and we can see how it performs, feed size increase, etc..

It can serve as a reference feed as we go forward.

@kfinn @adam @tomrossi7 @dave @theDanielJLewis


1) chapters that are embedded in MP3 can’t be used in web based players / HTML 5 web apps

2) Chapters are important to me

3) having chapters in RSS would not only enable chapter jumping in web based players but also would provide additional metadata for search purposes

@csb @adam @tomrossi7 @dave @theDanielJLewis I totally get where you are coming from. The biggest concern from our end is feed size. The more we add to the feed the more bandwidth and computing power will be required to serve and process. Chapter markers constitute a lot of code at the <item> level.

We can get creative and come up with a great spec for chapters, but it's not a straight forward as some of these other initiatives.

Maybe this?
<podcast:chapters url="[link to chapter data]" />

@kfinn @adam @tomrossi7 @dave @theDanielJLewis


Dave can show basic RSS to all podcathchers and only if &chapteMetadara=yes provided , then the RSS can provide additional crowdsourced metadata

@kfinn @csb @adam @tomrossi7 @theDanielJLewis Kevin, The transcript spec that you guys use is basically almost a chapter document already. Can that format be forked, and tweaked to include the chapter metadata, like time-based images, blurbs, titles, etc and then we could address it with the tag you just proposed? Maybe JSON format since it would most likely be pulled in by the app directly and not the aggregator?

@kfinn @csb @adam @tomrossi7 @theDanielJLewis We will definitely aggregate that in the index. But, if it's an external file we'll just pass the url to the app instead of digging into the chapters. At least initially.

@kfinn @csb @adam @tomrossi7 @theDanielJLewis Would be nice to have the PodcastAddict dev here to give some feedback and testing the proposed format. Since they already support the transcript format it seems an "easy" drop-in for them.

@kfinn @dave interesting idea! If I understand the proposal is to use a link to the chapter information in a JSON file? That would keep the RSS feed smaller and provide runway for extending what is done with chapters.

@tomrossi7 @kfinn Yes, that was the idea Tom. Having an independent spec seems a good solution. They can evolve independently.

@dave @tomrossi7 @kfinn I think moving chapters to a separate file would be a mistake.

Chapters really only _need_ a title and starting time. Ending time isn't necessary.

But I also must challenge what @csb said. MP3 chapters are in the header information. IAB-certified hosts are not supposed to count a download until 1 minute of _audio_ has been downloaded. So you should be able to access the ID3 tags and chapters in web players.

@theDanielJLewis @dave @tomrossi7 @kfinn


and yet no web player can access this chapter info from MP3

I guess it’s impossible from JavaScript in web browser

there is big difference between “should be able” and: it works, here is example

@csb @theDanielJLewis @dave @tomrossi7 @kfinn

I was thinking "What's the problem" and created a proof of concept. I can get it working reading chapters from the mp3, but A LOT of times it fails, because of CORS.

That means it cannot realistically work from the client side.

Having chapters in the mp3 might be a lot of work on the server side too (too much overhead doing a head request to every mp3 file out there).

I am unsure. I think the mp3-way had it's chance. Time to try something new!

@martin @csb @theDanielJLewis @dave @tomrossi7 @kfinn

With the prevalence of mobile web, I _always_ try to do the heavy lifting with the CPU on mains power rather than a battery.

I have actual code to take metadata out of SQL and supply as JSON to the player, which updates the player text as it reaches time points. This worked quite handily:

in particular the metadata() method

@csb @dave @tomrossi7 @kfinn No play _can_, or no player _does_?

Chapters are only just recently catching on. Plenty of web players have already pulled in other data from the ID3 tags.

@kfinn @adam @tomrossi7 @csb @dave However, AAC files spread the chapters through the file instead of grouping in the headers.

@theDanielJLewis @kfinn @adam @tomrossi7 @csb @dave I also think moving chapters to a separate file would be a mistake. Here a re a few reasons:
- There are very few podcasts the currently support chapters
- Chapters aren't transcripts and most podcasts that support them do it using less space than show notes which are also in the RSS feed item.
- Many podcasts have extremely long show notes and that doesn't appear to be an issue with Buzz Sprout

@theDanielJLewis @kfinn @adam @tomrossi7 @csb @dave
Podcast chapters are currently embedded in the MP3 File itself, but this makes it very difficult to index chapter content (a big advantage to using podcast index if it adopts this). Also, since the mp3 must be downloaded entirely before chapter content can be parsed from the mp3 file its means clients need to download all of this data before it can be displayed to users so it's not a good solution at all.

@theDanielJLewis @kfinn @adam @tomrossi7 @csb @dave
I know Buzz Sprout has already invested a lot into developing their MP3 Chapter editor, but I don't think that's a reason to not do MP3 chapters the right way now.

@hypercatcher @theDanielJLewis @kfinn @adam @tomrossi7 @csb I know what you’re saying David. But you’re in a better position (as a native app developer) than someone like @martin who is stuck in a web browsers and has to deal with CORS and sandboxing issues. HTML5 can be a real debar to deal with trying to pull an mp3 and parse the binary.

A feed based chapter spec can easily coexist with the built in MP3 based spec. Tools can be created to generate both in one go.

@dave @hypercatcher @theDanielJLewis @adam @tomrossi7 @csb @martin Yes - we wouldn't replace the MP3 embedded chapter markers, we would supplement. We have all the data in our database, so we can spit it out in various ways.

@dave @theDanielJLewis @kfinn @adam @tomrossi7 @csb @martin I completely agree with that. I hate chapters being embedded in MP3 even as a native developer where it's much easier to deal with

@tomrossi7 @csb @adam @theDanielJLewis Podcastindex is an aggregator. That's how the API works. We aggregate a little over 1.3 million feeds right now. We will be implementing the chapter spec (whatever final form) immediately along with everything else. I'm happy to make our system the mad laboratory for all of the new stuff. And, I'll give everyone here stats and impressions on how it's working. The Podcasting 2.0 show will bake this stuff into the feed immediately too as a test bed.

@dave @adam


I wish that in future, not now, your podcast index dot org, could provide ability of crowdsourcing of some infos about episodes like chapters ,

Question: could you envision end users (not podcasters) crowdsourcing chapter info back to podcast index org for example by running some app or command line that a) extracts chapters from outline , b) extracts chapters from MP3 file, c) user created chapters (title+time stamp)


@csb @dave @adam

Like 'share from this point in time' to a Mastodon toot with a description?

Maybe that's not so elegant though (on second thoughts!)

@csb @adam Would love that. Tell me an API endpoint design that you think would work and we can try it out.

@dave @adam


Something like this what @marshcast proposed: .

Exactly how doesnt matter: gist is to enable end users not merely podcasters to enable enriching episodes with these chapters points

@TeringNering @tomrossi7 @csb @adam @theDanielJLewis "Enhanced podcasts" relied upon embedding the chapters and images in the audio file, and it had to be an Apple AAC format, not MP3. It was all too proprietary. AAC in general never gained much traction. MP3 dominates.

@tomrossi7 @csb @adam @dave @theDanielJLewis

This question is right to the point. If you have a hammer, everything looks like a nail. At what point are you loading show assets into the RSS feed, rather than pointing to them? I feel like the actual transcription of a No Agenda show should NOT be all embedded in the RSS, for instance. As an alternate approach, imagine a companion to the .mp3 (say, with .json extension) which can be imported directly by a player when replay starts.

@csb @adam @dave @theDanielJLewis hey @vandys! That is how it works. The only thing included in the RSS feed is the link to the transcript, not the actual transcript. (

@dave I feel like we should give it a little more time for some more app-devs and hosting providers to weigh in before we consider things formalized.

@theDanielJLewis Those top 4 only comprise 2 actual tags. The transcript/captions tag is already being used in the wild by BuzzSprout and has adoption by PodcastAddict. Formalizing it just makes sense.

"When practice deviates from the spec, change the spec." --Rules for Standards Makers

The locking/ownership is such a dead simple and effective tag that I don't see how it can be refined any more. It's now the only tag that's required.

Everything else is up for grabs at this point.

@dave @tomrossi7 I agree with @theDanielJLewis that we need to socialize these new namespace tags to the whole industry. Do we have all the big listening platforms involved in this group providing input yet?

@robgreenlee When you say "listening platforms" do you mean the app developers, the hosting platforms, or both? Just want to make sure I'm understanding you.

We have a good start on it. Getting more voices each day on the Github and here.

@dave ALL Listening App Developers, yes and Apple, Google, Spotify and Pandora. Plus all the podcast hosting platforms. Even larger content networks like NPR and iHeartRadio folks plus many of the podcast creation networks.

@robgreenlee That one's above my pay grade, which is currently zero. lol. 😃

My opinion is that a small, nimble group who is laser focused on a single mission can do far more and move much faster than a group of 100 voices that all have different, possibly competing interests.

We are basing the spec, first and foremost, on what we see already happening in the wild. So, the apps and platforms have, in many cases, already shown what they want. We're just bringing it together.

@robgreenlee When the desire is not so clear, we slow down and listen. Or, push it off to a later phase.

"Rules for Standards Makers" is our Bible. We're doing well so far.

@dave I agree with you all that is good, but it is important we get involvement and buy in from as many as we can in this for it ever to be adopted broadly? The basis for the spec is correct to do, has anyone reached out to the Apple team on all this? Without them, this whole thing will sputter. We have seen it before and Apple is willing to get involved.

@robgreenlee That one's beyond my reach I'm afraid. Maybe you guys with inside contacts can do the proselytizing? We'll concentrate on giving you something good to work with.

@robgreenlee @dave I see this involvement and buy-in is something that everyone in this group is able to do. I'm doing my very best to promote these tags, and have popped into a few Slack groups to point folks there to here.

Specifically - let's get Libsyn involved here, that would be awesome. Are you able to help us with that?

Sign in to participate in the conversation
PodcastIndex Social

Intended for all stake holders of podcasting who are interested in improving the eco system