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.
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.
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
@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 https://playlist.podcastnotes.org
@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.
@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.
@tomrossi7 I disagree as mastodon is better for discussing
@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.
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)
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
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.
@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.
@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?
Intended for all stake holders of podcasting who are interested in improving the eco system