Chapters
sandikbarr opened this issue · comments
chapter marks within an associated media file as in http://podlove.org/simple-chapters/
Dynamic media makes this hard to keep in the feed, as opposed to more directly attached to the media (e.g. as ID3 or as a Link header on mp3 response)
I agree with @chrisrhoden that "chapters" should be stored in ID3v2. Would be interesting to start a separate discussion about which ID3v2 frames to use for what. It would be nice to separate images, videos, URLs (like a wikipedia URL) and other types to be able to display them in interesting ways.
Yeah, this shouldn't be part of the Syndicated Media spec. Normal podcasts can use the metadata in the media file, and Pod Love either instead of in the file, or as an override if they want to fix anything without a new media file.
Dynamic podcasts should just stick to the media file metadata. And I don't know enough about the media formats to say anything about that really.
@chrisrhoden is a http header already a thing, or something you think would be good? Never heard of anything link that before. Are you already doing ad injection? How do you deal with time stamps such as the PodLove deep link spec, or Overcast and Pocket casts/anything elses share features?
About Chapters in ID3 tags @empaempa:
You can add URLs, titles, images, and basically all other frames in a chapter.
There is an official spec for that:
http://id3.org/id3v2-chapters-1.0
And nowadays most tagging libraries support that.
For information about other formats, please see
https://auphonic.com/blog/2013/07/03/chapter-marks-and-enhanced-podcasts/
@Cj-Malone yes, HTTP headers are a thing, they already include things like status codes, content types, and cache information. There is, in fact, a header called Link which could be used for this purpose. https://www.w3.org/wiki/LinkHeader
@Cj-Malone There are several organizations (including PRX, where I had the pleasure of helping build the system powering these features) that have had widely deployed dynamic ad injection for a while now. It's been a thing that was quietly working in our industry for over a year at this point.
There are a few reasons from an implementation standpoint that I can think of why a referenced resource would be a little simpler than wrangling ID3 tags, though I think I agree that ID3 is the most logical final place for the data. Using a reference would allow us to do lots of interesting stuff without needing to fall back gracefully for clients that are already using the mp3 chapters, and it would let us use a much larger payload without requiring clients that don't intend to use the data to download them.
There are a few reasons from an implementation standpoint that I can think of why a referenced resource would be a little simpler than wrangling ID3 tags…
In addition to being simpler, it would be less brittle. MP3 isn't long for this world — podcasting is the last holdout for what is at this point a very old and relatively inefficient compressed media format.
Modern podcasting offers multiple file formats (mp3, m4a, ogg, opus) and lets the client decide which it prefers. Properly embedding chapter information in all viable formats is still a challenge. And then there's the other end to consider: clients reading the data from the media files.
I keep reading questions on Twitter about how to embed chapters so they work across all devices and platforms. It's hard. And then there are web players to consider, wo might ideally want to provide chapter information even before the media file has loaded.
An XML format that can be embedded or linked to in the RSS feed solves all these problems. Parsing XML is trivial, no matter what device or platform. It's a solved problem. And clients can even show this information before loading the media file.
@eteubert I don't think that linking from the audio asset (e.g. as a Link header on the HTTP response) is worse than encoding in the feed from the clients perspective, and it permits for different chapter markers depending on the way that the media is constructed, e.g. with different duration ads. I am very glad that the podlove specification exists, but it literally cannot be deployed for most of the top publishers because the markers move around depending on the specific ads served to different clients.
PodLove's chapters can be done in feed, or an external file that's linked to by the feed.
@chrisrhoden Remember that most publishers don't do thoes things, maybe it's comon with your crowd and "top" publishers but it's not a common thing. And as you're doing it programmaticly it's trivial to inject the modified chapeters at the same time as the ads.
But if you don't want them in the media file, when are you building the media file (injecting ads)?
Every X days when you get a new sponsor? In this case when you create the new media file, at the same time as updating the link, and duration in your feed either update the chapters or the link to the external chapters.
Are you changing ads every x downloads? I'd recommend doing the same, you would still get a few people hit the old files until they update the feed. But if you don't want x being approxiate you would have to switch the file, at the same URL. I don't think this is a good idea, you can't update the duration in the feed. But in this case you could just swap the external chapters the same as the media file.
On http get requeast, this just seems kinda wrong, I hope you aren't doing this. But then you'd have to maintain state between the 2 requests. Unless HTTP Link gets adopted, and I agree that it wouldn't be hard to implement, but I don't think its a great idea.
On every request. You can say that that feels wrong, but you're mistaken. It's how nearly every piece of content on the internet works. Different users may receive different ads at the same time. This site shows a different username in the top right for me than it does for you.
HTTP Link headers are are used in the wild. The RFC defining this permanent response header can be found here: https://tools.ietf.org/html/rfc5988
Dynamic ads as a serving technique is picking up and seems likely to be more prevalent in the future. Right now, it makes up a very significant portion of the download traffic, and I would wager an even larger portion of the traffic for which chapter markers would be generated.
@chrisrhoden Yes it's common on the web, but podcasting isn't the web and you'll need more than a few namespaces to turn it into it.
I'm aware link header is already a part of HTTP, I meant being adopted in podcasting + clients, is your server the only thing that currently supports it? Could you post a link that I could curl and see as an example.
@Cj-Malone I don't understand your first point. Podcasting operates over HTTP, the same technology powering the web. I think any further discussion of what you think is and is not possible for dynamic ad platforms should be taken up in another thread.
I have not implemented anything with a Link header, but adding headers to responses is trivial in every web application development environment I am aware of. Every time your client accesses a Podtrac or Blubrry media URL, it's reading and reacting to Location headers to redirect.
https://pubsubhubbub.github.io/PubSubHubbub/pubsubhubbub-core-0.4.html is an example of something that is well established in the RSS/podcast ecosystem that relies on HTTP link headers.
Going up several posts, I think I am in favor of the SM spec (though perhaps not the RSS extensions) to include this kind of functionality. Given how many options there are for doing it already and for implementing new methods, and how high the demand is for it, leaving it out of the spec seems like a bad idea.
I don't mind HTTP link headers. I can see how it allows for greater flexibility and at the same time, even if I don't need to deliver highly dynamic content, I can deliver static chapters.
At Acast we've have chapter support (we call it Interactive Media) since a couple of years back but only in our apps. Some of the podcasts hosted on our platform uses more than 30-40 of these per episode, so it need to scale. And I think putting them directly in the feed would probably not scale.
We also have dynamic ad-injection and can have 100s of different versions of each episode, all with different lengths. So for us it's crucial that chapter info is stored "close" to the media file - either in the media file response header or as ID3 tag on the media file.
I'm no ID3 tags-expert but a quick google led me to this: http://www.mp3tag.de/en/#formats - seems like most formats have support for some sort of metadata/tags.
From my perspective both the http-link and the id3-tag have their advantages.
The http-link solution is easy to implement, both from a client and server perspective and doesn't have a dependency on the media file format (mp3, ogg, aac..).
The id3-tags has the advantage of being bundled with the file, so even if the file is downloaded they still keep their metadata. There's also seems to be fairly good support for id3v2-chapters in many podcast apps for today.
On a side note: should the target of the http-link still be a xml document or would it be an option to serve it as json? Would also be interesting if it would be possible to server other file metadata in this document and not just the chapters (transcripts come to mind..)?
Hello everyone,
did you know that if you add chapter marks in content:encoded some podcatchers parse these timestamps and make them link to the specific points in the audio?
Below is an example on overcast, where the yellow timestamps are links.
if you want to take a look to the feed that generates these chapters, you find it here. Since this already works with the current status of RSS, it may be worth taking a look into?
@borja-rojano That's interesting, didn't know anyone was doing that. The likelihood for false positives seems very high. Do you have a sense for how often random X:YY strings are being turned into chapter markers?
@farski Under what circumstances would someone include in <content:encoded> a string with a 01:15 format if she does not mean a timestamp? In any case, if we'd want to root out false positives, we could use [01:15] as the standard for timestamps.
Using this solution has the following advantages:
- Anyone can add timestamps, even by hand.
- Overcast will already transform them into actionable navigation items.
- If they are ignored by the podcast client, they still look good in the notes and give listeners a good indication of chapter content. See iTunes rendering of the same notes below.
- If a podcast client wants to parse them and add them to e.g. the audio transport bar (as we do in our web player) it is relatively easy.
@borja-rojano Pretty much anytime someone mentions a time (eg The crime took place at 3:15 AM), or even other types of content, like bible verses (John 3:16). I'm sure there are other examples.
My gut reaction to this kind of system is that having a standard notation for these kind of inline to add good functionality to the long descriptions in UI. As a long-term solution for reliable, machine readable metadata it feels a little...weird. It turns in to a lot of parsing of parsed data.
Yes, those cases would result in a false positive. There are solutions to this, though:
- Wrap them in brackets
[01:15]. The brackets are visible for the listener but they still look good. - Wrap them in
<span>01:15</span>. This is invisible for the listener.
Of course, we can think of another way of adding chapters but since this one already works in one of the main podcast clients and is dead simple to use, perhaps it is worth a shot? To parse notes to extract regex with any of the two formats above is a very, very simple algorithm.
@empaempa I'd love to have your view on this last part of the discussion. How does acast deal with <content:encoded> containing chapter timestamps?
We don't :)
We're looking into supporting it but no decision yet on how.
@borja-rojano I do strongly believe that we'll need some sort of microformat to delineate any data within the description (e.g. <span class="t-timestamp" data-time="140S">2:20</span>) . There's a lot to like about this approach, because it works with some existing podcatchers and it gracefully degrades, though I am still of the opinion that such a dramatic amount of listening (perhaps not by number of shows, but certainly by number of downloads) are excluded from participating in this system because those timestamps are unstable. For context, please review the rest of the discussion.
@chrisrhoden yeah, if we'd move to <span class="t-timestamp" data-time="140S">2:20</span> it would be also easy to implement for everyone and, as you said, would degrade gracefully.
Just my two cents, we'll make sure our feeds are compatible with whatever chapter formatting that goes in the spec.
However, the listens that are excluded is not because instability but for lack of support, is it?
@borja-rojano I think what @chrisrhoden was referring to was the instability of the exact location of chapters in an episode. As more content is generated dynamically (with ads, without ads, different ads, longer or shorter, etc), where a chapter actually begins moves around quite a bit. In those cases all this data would have to get generated dynamically also, which is why some of the other ideas that have been floated adapt to that system a bit better.
A little late to the discussion, but my app iCatcher! also turns those time stamps into clickable times. I don't extract them and display them as chapters, but if the user views the show notes they will see they can click them.
It seems like a nice way for a podcaster to add markers without having to use other tools. If there was a standard for indicating chapters in the show notes that would be helpful.
You can see examples of these in podcasts like Herding Code and the Windows Central Podcast. In those cases it's HTML and has a list item <li> followed by either (01:35) or just 1:35. Some simple javascript turns it into clickable links.
Chapter support in media files is possible but an ongoing problem, especially in MPEG-4. While ID3 chapters are becoming more popular, supporting chapters in MP4 has become a nightmare recently.
Apple never published the documentation on their initial implementation and has changed the way they do it a least a few times as they moved from iPod to iPhone. Today, there is no way to produce a MP4 chapterized file that can be reliably played back on an iPod shuffle and an iPhone.
iPod shuffles might not be a big deal but similar problems exist with a variety of Android phones and closed-source and open-source media helper libraries. It's a jungle out there and I personally think, MP4 is dead as a media file because of this. But MP4 is still the only way to get chapters into Apple's Podcast.app so there is still a (single) reason to support it.
We have created Podlove Simple Chapters because it addresses all those issues with a simple and very effective approach
- any app can easily parse chapter information from the feed without having to parse complicated media file structures where many fail and get things wrong
- chapter information can be extracted and presented even before any download starts
- podcast directories can present chapter information without downloading any media file at all
- chapters can be fixed later without touch media files at all
I strongly support adding chapters to the SN spec. In Germany, chapters are very popular and PSC has proven to be helpful for many subsystems including but not limited to podcast clients and directories.
I think there's a balance to strike here - some of our publishers use A LOT of chapters, which would make their feeds huge. And Acast use dynamic ad-insertion so chapter times vary for each user, making it impossible to cache the feeds.
Agree ID3v2-tags won't work across the board - but that might be OK. Having chapters in a separate feed/document has been discussed, too, and starts making sense to me. The format of this feed/document can be based on Podlove's Simple Chapters with some possible additions.
@empaempa if dynamic ad-insertion changes chapter times it also changes the overall duration, right? then your feed is incorrect anyway. However, chapter info in the feed would not be mandatory: if it can be done in your publishing environment, leave it out. But it should be standardized nevertheless because it will work for 99% of all podcasts using chapters.
Huge feeds can be prevented by adopting Paged Feeds (see #48).
@timpritlove You mean that the duration-tag isn't correct? Not really following what you mean with if it can be done in your publishing env, leave it out - please elaborate.
Paged feeds would be nice but will it work across the board (read: in Apple Podcast-app)?
@empaempa I mean, if the length of the episode media file changes with inserted ads, the <itunes:duration> field would also lead to a non-cacheable feed (unless, all your ads have a predictable total duration).
In general, chapter information does not add much to a feed in total. Most chapter titles are just short sentences at best and there are usually not more than 20 of them. Most <description> or <itunes:summary> fields pack much more information. I agree that smaller feeds are better, but podcast clients should be tested against big feeds anyway (SN-SPEC should in the end provide reference feeds to test against).
Most feeds are limiting the amount of episodes in the subscription feed today anyway. So Paged Feeds
are just added value for apps that do support them.
Getting support from Apple for Paged Feeds (and anything we want to define here) might be difficult to achieve, but what good is an standardization effort like this if we would not aim for all major players to join? If all popular podcast apps except Apple's will join the effort, what position will Apple finally be in? Users will demand support and/or move to other apps. That's exactly what might drive them to finally adopting a new standard.
Right, we add silence in the end to pad for duration. We're looking into other features that will make the feeds hard to cache so it's just a minor concern for us, but worth weighing in.
The problem with cutting feeds is that our publisher will be angry that not all their episodes are available in the Apple Podcasts apps. But I agree that the only way forward is to get wide adoption so they have to follow suit.
Another argument has been to keep chapter information as close to the media file as possible - in its ID3v2-tags. I tend to agree, in theory, that's the best place to have them.
@timpritlove I'm not sure whether this is the case in the rest of the world, but a quick survey of the top 20 podcasts in the iTunes store in the US found 15 shows hosted by organizations that have publicly talked about their per-request dynamic-audio serving, and a few others appear to be doing the same without having publicly talked about it.
This isn't a red herring. Dynamic audio is here, and it's something we need to get on board with. To your point about duration, this is a real problem, and one that many podcasts served this way are choosing to opt out of completely by providing a duration of 0 for every episode (see Radiolab for a very popular example).
I don't think we need to abandon existing specs to support this, though. I just think we need to provide a mechanism for the data to exist alongside the media file and not in the feed. My proposal is to use an HTTP Link header, which would work with any media encoding / container. We could continue to use the Podlove spec for the documents referenced by the Link header.
@chrisrhoden Would the link header be on the media file or on the RSS? Or both?
The media file.
@chrisrhoden What is stopping you adding the chapters directly to the media file when building it? Surely that is the easiest time to make the chapters info.
I just think that all these different formats and delivery mechanism will be a barrier to implementations.
I think the chapter information needs to be in the delivered media file, independent of whether or not it's in the XML. Putting chapter information in the XML file with timestamps breaks dynamic ad insertion (unless users get dynamic RSS feeds, which breaks caches, and means publishers can't use Feedburner/Podtrac/etc.). If a publisher didn't care about dynamic ad insertion, it seems helpful to have in the XML, but I have to think that another format (EPUB? DocBook?) has already defined a suitable XML structure for chapters that we can borrow (via XML namespaces) without reinventing the wheel.
Different ways to do chapters in media files:
- WebM/Matroska (Opus and others)
- ID3 (MP3 and others)
- Ogg (Opus, Vorbis, others)
- Apparently MP4 is an utter mess and there's no reasonable way to do chapters that is supported everywhere, and zero of it is officially documented. I would ignore what Apple does and do what Blu-ray does. I don't know what that is. I would rather just assume that chapters can't be supported in MP4 and officially say we recommend WebM/MP3/Vorbis over MP4.
Dynamic ads are no reason not to spec chapters in XML. If you want to do it file by file you can do so. But any podcast that doesn't do this (hint: the overwhelming majority) will be happy to have a simple, straightforward, easy-to-parse way of communicating structure.
Media file metadata is a mess and will be a mess for the foreseeable future. It's making simple things complicated.
I can only hope this whole endeavour is not all about serving the ad industry and focuses on podcasters' needs.
Fair point @timpritlove. I tend to take the perspective that we're trying to help further the industry as a whole, but we're not putting the ad industry above the podcasters' needs in any way.
I agree with @timpritlove - this standard should define an optional way for chapter information to be conveyed. I think that it should do that by adopting another standard's way of providing that information, if possible. I looked into EPUB, and it's a mess and doesn't really work for us.
If we do end up having to define chapters, I would have these requirements:
- Tag must be optional.
- Chapters can be nested.
- Chapters which are nested do not necessarily require a timecode (i.e., can be an ordered list of things talked about in the chapter without having to reference timecodes)
- Timecodes can be
HH:MM:SS.MMMMor a floating point number of seconds (12345.6789)
Also, I think the most flexibility and compatibility is gained by adding attributes to XHTML's <ol> and <li> tags. By that, I mean that chapter data can be embedded in an RSS <description/> as HTML that looks something like this:
<ol sm:type="chapterlist">
<li sm:time="00:00:00.0000">
Introduction
<ol>
<li sm:time="00:01:33.1234">Live Show Update</li>
<li>Some other landmark that happens sometime in the chapter</li>
</ol>
</li>
<li sm:time="00:17:00.0000">Karen's Favorite Murder</li>
</ol>SM-incompatible clients that support HTML will render this as an ordered list. You could maybe move the times into a <span sm:type="timecode"/> for the greatest compatibility. SM-compatible clients will render this as something navigable.
There's definitely some compelling arguments to have the chapters as a separate xml-file. To me the most important point seem to be the ability to support multiple file formats. There are however a few drawbacks with this approach that would be nice to somehow address:
- A downloaded file would lose the chapter data. Maybe it would be possible to add a reference to the xml in the tags but there at least in id3v2 doesn't seem to be an obvious way to do this.
- Setting a new standard for chapters means starting from scratch when it comes to support in apps. I'm not sure how widespread the support is for the podlove chapters? The id3v2.4 standard is 16 years old and there's still a lot of people using the 2.3 version.. Id3 chapters already have a fairly widespread support. There are already a couple of tools to make the editing of chapters fairly straight forward (http://chaptersapp.com and https://kid3.sourceforge.io for example)
-It makes dynamic ad insertion a bit more complicated, but this could be fixed using @chrisrhoden 's suggestion of using the link header (although this won't be backwards compatible). It's true we shouldn't set a standard for the ad companies, but at the same time ads are what finances quite a bit of the podcasting industry so I don't think it should be neglected either. - Not all hosting companies have support for hosting separate xml-files. I think we should try to set a standard for that works for the majority of the podcasters and I would guess that most non-technical podcasters aren't running their own servers.
I don't think any of the alternatives are really good. Adding it to the rss doesn't feel really right as we're not really syndicating data at that point? Having it as a separate xml would be fine except for the multiple files delivery issues.