Namespace update - We now have the following:
- transfer locking (formalized)
- owner verification (formalized)
- transcripts (formalized)
- captions (formalized)
- 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?
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.
@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.
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.
<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?
@dave I'll drop him an email.
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.
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 thanks a lot for trying!
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
Intended for all stake holders of podcasting who are interested in improving the eco system