Replies: 7 comments 18 replies
-
|
I think it's an interesting idea, especially since they also have a way to for metadata, but I recommend against this for three reasons:
|
Beta Was this translation helpful? Give feedback.
-
|
Reading the transcript text - https://github.com/Podcastindex-org/podcast-namespace/blob/main/docs/examples/transcripts/transcripts.md "Want to support only one format? WebVTT is used by Apple Podcasts for ingest, and also natively supported by web browsers. Because the WebVTT format is the most flexible, it's an ideal choice if you can only support one format." The JSON representation is a flexible format that accomodates various degrees of fidelity in a concise way. At the most precise, it enables word-by-word highlighting. This format for podcast transcripts should adhere to the following specifications. Apple uses the VTT format with accurate word highlighting. |
Beta Was this translation helpful? Give feedback.
-
|
I think there are three proposals here from @dascritch - let's see if I can help unpack them: 1. "Use WebVTT standard" I agree with this part of the proposal. I'd like to propose that we retire SRT/TXT/HTML format to simplify the specification. WebVTT is a standard for browsers, which supports VTT files out of the box for video, and supports VTT files for audio quite simply as well. Here's use of an AUDIO player with VTT support. SRT files are much less well supported by the web. If you have to have an SRT file for your application, then it's an easy transform from a VTT file. They're almost identical in nature. Similarly, a TXT or HTML transcription can be built from a VTT file as well. Removing complexity from the 2. "Use WebVTT chapters" WebVTT has chapter support. However, podcasting uses four chapter formats currently - "chapters in descriptions" (Apple, YouTube, Spotify); "chapters in podlove format" (Spotify?); "JSON chapters" (Apple); ID3 tags (Apple). I would be keen to avoid adding a fifth chapter format without a clear understanding of the benefits. I don't believe that chapters are in-use by browser implementations. 3. "Improve the "cooked-up" JSON file" I do see the benefit of offering a word-by-word format (which VTT isn't). Is there any prior art in word-by-word format? Should we be aligning with a standard? Next stepsDo we split out the three parts of this proposal? |
Beta Was this translation helpful? Give feedback.
-
Which complications ? It's perfectly used in browsers and webview, that fire events. I'm using webvtt for my JS player for years, and it's far more practical to use those native standards instead to recreate a whole event controller that would be fatally buggy. The BBC on a (retired and no more available) test site used those native chapters events for their archived "Tomorrow's World" tv show even used those events to fire chapter highlights and trigger graphisms. We're only in a “Not Invented Here” syndrome. |
Beta Was this translation helpful? Give feedback.
-
|
I may be missing something here, so I want to sanity check my understanding. I share the interest in supporting web standards, but as I understand it, the browsers only recognize chapter title text, not the richer metadata we already have in ID3 tags and the JSON format. As I understand it, the only way to include things like images, links, hidden toc markers, would be metadata cues, but those don't share the same broad support. So I think the practical question is:
If I’m missing existing support for rich metadata VTT chapter payloads, I’d genuinely love to see examples. That may change the tradeoff quite a bit. |
Beta Was this translation helpful? Give feedback.
-
|
I think that chapters should be in the RSS field itself. The only times to link to external media are the podcast audio itself, the image for channel (and the item, if different), and transcripts (which can be very long).
Maybe I do not understand the likelihood, implications, or length of the potential JIT metadata, but wouldn’t this same argument also hold for everything in the RSS file? As it is, episode The link to an external text file that itself writes another link to an image and contains less overall text than a description . . . I do not understand the justification for the technical hurdles. (Just means that I do not get the reasons, not that the reasons do not exist.) A major caveat, however: Does the current way of doing chapters (external file) help in accessibility in the same way that transcripts do? Could they? The insistence of YouTube videos and Spotify podcasts for info in I am missing something, and I would appreciate learning what plans or predictions may be. If, as James Cridland wrote above, the project wants to avoid NIH Syndrome, then what was the impetus behind the creation of a JSON-based standard instead of doing what YouTube, Spotify (and others?) did with chapters in the description. Again, I am just unable to see it. Please forgive my inability to see the greater implications. I am also unable to see it “in action.” I readily admit a chicken-egg problem exists where low support in apps means low implementation by podcast creators, which itself results in low support in apps. |
Beta Was this translation helpful? Give feedback.
-
|
Apologies for not writing this in the original post . . . I am still too old-fashioned to read threaded and sub-threaded as well as I do flat forums. A detail I liked, and compliments to the chef, er, thinker: The proposal to bake chapter information into WebVTT files It seems that the transcripts are a thousand times better for accessibility, and that such a standard change could encourage people who create transcript files with chapter information to also put in subtitles. (My hope is that people think Why not, eh?) I will allow that this is one area where GenAI saves energy today—as manufacturing time-stamps for captions means your computers run way longer than they otherwise. (People just have to skim/proof the transcripts so that proper nouns are correct.) |
Beta Was this translation helpful? Give feedback.


Uh oh!
There was an error while loading. Please reload this page.
-
WebVTT is a standard well implemented in browsers for chapters, annotations and captions because it is in WhatWG and W3C recommended implemntations for the Media objects .
In https://github.com/Podcastindex-org/podcast-namespace/blob/main/docs/1.0.md#user-content-chapters , for the tag
<podcast:chapters>, it states that browsers aren't supporting ID3 chapters tags. This is true. But instead the proposal use a less standard solution, a brand new json file.Support for WebVTT files is nearly complete on web browsers and are a W3C standard.](https://www.w3.org/TR/webvtt1/), works smoothly in 99% market-share browsers, are exposed and used in accessibility tools. So why preconize a new file format without native implementation instead to use one perfectly used now for 10 years (in subtitling, but it works perfectly too for chaptering, i'm using it) ?
I suggest to change this to recommend WebVTT as a preferred solution, mime type
text/vtt, documentation https://www.w3.org/TR/webvtt1/, and alternatively to suggestapplication/json+chapters.cf #315
Beta Was this translation helpful? Give feedback.
All reactions