Transcribing a podcast episode, start to finish

Audio is a first-class input

Podcast recordings arrive as audio, and plenty of tools treat that as a degraded case. Here the file is probed the way a video is, the absence of a picture is detected, and the interface adapts: an audio player with a waveform, no caption styling panel, and no burn-in button, because there is no picture to burn anything into.

Everything else is identical. Same decoder, same model, same windowed transcription, the same editable list of lines and the same exports. If you later want captions for a video version of the episode, the transcript you already made is the caption file.

What an hour of audio costs

Time first, with a caveat attached. The measured figure is 8.6x faster than realtime for transcription and 7.1x end to end, measured on a 31-minute recorded lecture, Chrome, 16GB Windows laptop with the WebGPU backend on 2026-09-26. That puts an hour-long episode at about 8 minutes. On a machine with no WebGPU the model falls back to the CPU, which is substantially slower and has not been measured here, so treat the figure as the good case rather than the typical one.

Then the download. The speech model is 45MB for the faster size or 80MB for the more accurate one, fetched once from a CDN and cached by your browser. Every episode after the first skips it.

Then the ceiling. The whole recording is held in memory as audio samples alongside the model, so there is a hard limit of 2 hours per file. A long interview episode fits comfortably. A three-hour show has to be split in two, and the tool says so before you start rather than failing partway through.

Turning the transcript into show notes

Export as Markdown and the text comes out grouped into paragraphs rather than caption-length fragments, which is the form worth pasting anywhere else. Plain text and .srt are also there if you want the timings kept.

There is also a copy-for-assistant export, which prefixes the transcript with a short note saying the text is machine-transcribed and where the errors tend to cluster. That preamble is not decoration. A model handed a bare transcript treats a misheard guest name as fact and builds a confident summary around it, where the same model told the text may contain recognition errors hedges on exactly the right things.

Chapter timestamps come out of the line list, since every line carries the second it was spoken at. Scan for the topic changes, note the timestamps, and you have chapter markers without listening through again.

The five things to fix before publishing it

A podcast transcript fails in a predictable set of places, and most of them are specific to the format rather than general transcription problems.

• Guest names. Almost never right, confidently spelled, and the one error your guest will notice
• Sponsor and product names. The same problem, and the one your sponsor will notice
• The intro and outro music. A long stretch with no speech is where the decoder gets stuck repeating a phrase, so check the first and last thirty seconds specifically
• Numbers and dates mentioned in passing, which transcribe by sound and can land an order of magnitude out while reading fluently
• Who is speaking. Switch identification on and a two-person interview arrives with Speaker 1 and Speaker 2 suggested; check them at the handovers, rename them once, and split any line the model left blank

Why publish it at all

An episode page with a transcript is a page with several thousand words on it instead of an embedded player and a paragraph. Everything said in the episode becomes findable, including the parts you would never have thought to put in the description.

It is also the version of the episode that people who cannot or will not listen can use: deaf and hard of hearing listeners, people who read considerably faster than you talk, and anyone trying to find the one thing you said about a topic in a ninety-minute conversation.