See the entire conversation

In yesterday’s thread about the future of podcast transcripts, I had to cut out a tangent about the history of podcast chapters. I think the path to adoption for podcast chapters is instructive as a roadmap for encouraging transcripts, so, you’re getting it today. 🧵 #tweet100
17 replies and sub-replies as of Dec 21 2021

For years, Apple Podcasts (and others) only supported chapters in their own undocumented AAC “Enhanced Podcasts” format. Encoding chapters in MP3 was patent-encumbered by the Fraunhofer Society. (People joked that all the podcast chapter advocates were from Germany. 🇩🇪)
An abbreviated history: Jan 2015: @marcoarment writes, "Why Overcast doesn’t support chapters" Oct 2015: @OvercastFM adds chapter support, "Turns out that chapters are pretty nice. Don’t doubt the Germans." Jan 2016: @tpritc releases @AppChapters (later adopted by @bjoreman)
Apr 2017: MP3 patents expire Nov 2017: Marco releases Forecast Dec 2017: @Podnews calls MP3 chapters "a waste of time" citing visibility in just 2 apps, representing "6.2% listening share" Jun 2018: @ApplePodcasts adds support for MP3 chapters (a major lift in listening share)
Now, I’d say MP3 chapter support is an expected feature of any serious podcast app. With enough momentum, the flywheel for podcast chapters is spinning in full force.
With a groundswell from any of the three, you can kickstart the flywheel. With broad app support, listeners can evangelize transcripts to podcasters, podcasters enrich their podcast experience for everyone, new listeners discover the value of transcripts, and the cycle repeats.
So what can we learn from this? • start by providing value to the listener • remove roadblocks for adoption with free and easy tools • help listeners/podcasters/apps create a virtuous cycle of adoption • don’t wait for the biggest player to get on board
Now, the single biggest blocker to widespread adoption is the dynamic ad insertion tech used by all the big media companies. Since those media companies are the most exposed to accessibility lawsuits, DAI providers are more incentivized to support transcripts than chapters.
If they want to support the <podcast:transcript> tag, they’d have to ensure that separate file requests (audio + transcript) receive the same version of the episode. Alternatively, they could encode them in the MP3’s metadata, but no apps (besides @StenoFM 😅) support that yet.
I'd love if more apps/tools supported that. They’d just have to read/write the SYLT header described in the ID3v2 spec. It adds a negligible difference in file size, especially compared to the images that get encoded in these MP3s. id3.org/id3v2.3.0#sec4…
The lack of SYLT encoding options is why I’m building Caption Studio. This would allow podcasters to upload MP3s with transcripts to hosts like @anchor, @libsyn, @Simplecast, etc. that don’t yet support the <podcast:transcript> tag directly.
Does anyone want a sneak peek at what we’ve been working on? 👀
Hopefully, we can build sufficient momentum to get all the tools in the ecosystem to support some form of transcription. If you’re interested in working on this problem, get in touch! twitter.com/messages/compo…
I could easily support SYLT in Forecast and Overcast if demand is there. My biggest hurdle with transcripts, as a podcaster, isn’t data formats — it’s how to get them made quickly and economically. What good options have you found for that?
How about supporting the @PodcastindexOrg transcript tag? Then podcasters can use whatever transcription service they want.
I’ve tested that API in development. It still has a lot of compromises, unfortunately, and I don’t think the output is particularly useful as an equivalent text alternative to the audio.
If the DAI component is always, say, 60" long then the transcript should work fine, with a gap (or filler) during the DAI component.
That’d be ideal for more than just transcripts! I'd love for timestamped links to be reliable too.