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!

@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 @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 @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 @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 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.

· · Web · 1 · 1 · 1

@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.

Sign in to participate in the conversation
PodcastIndex Social

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