AI for Podcast Show Notes: The Full Pipeline

Most advice about AI show notes stops at one sentence: paste your transcript into ChatGPT. That advice produces show notes. It also produces timestamps that point at nothing, quotes your guest never said, and their surname spelled three different ways.

The real job is not a prompt. It is a pipeline that runs identically on every episode:

raw audio → transcript → speaker labels → chapters → show notes → title and description → transcript page

This guide builds that pipeline, and it is honest about where it breaks — because those are the parts every generic guide skips.

The Challenge

An episode does not produce one artifact. It produces six: a transcript with the speakers labelled; chapters, the timestamped topic boundaries a listener can jump to; show notes; an episode title and description; social clips, cut at the timecode of a moment that was actually good; and a transcript page on the show's own site.

Doing this by hand means a scrub pass — opening the episode and skimming an hour of audio to find where the topic changed. There is no fast way to do that. You cannot skim audio the way you skim text.

And the six are serially dependent. The chapter titles come from the transcript. The pull quote comes from the transcript. The description quotes the chapter titles. So one error at the top of the chain — a misheard company name, a quote attributed to the wrong guest — is not one error. It is six.

How AI Solves It

The most important idea on this page is that the pipeline has two layers, and they have different senses.

Layer one hears. A speech recognition system — Whisper, ElevenLabs Scribe, AssemblyAI, whatever sits inside Descript — takes audio and returns text with time codes attached. It knows when things were said, because it processed the waveform. It separately tries to work out who said them. That second task is speaker diarization, and it is a weaker model bolted onto the first.

Layer two reads. In this pipeline, a language model — Claude, ChatGPT, Gemini — receives a string of text. It never touched the audio. It is excellent at everything text-shaped: summarizing, titling, finding the topic boundary, writing the description.

Some of these models can take audio directly — Gemini accepts hours of it per prompt, ChatGPT accepts it too; Claude does not. Do not let that tempt you. A timestamp produced by a language model listening to audio is an estimate. A timestamp produced by ASR forced alignment is a measurement. The whole discipline of this guide is: take the measurement, and copy it.

Keeping the two straight is the difference between a working pipeline and a broken one:

The model that writes your chapters cannot hear your podcast. Every timestamp in the output must be copied from layer one, never computed by layer two.

Hand a model a transcript with no time codes and ask for "chapters with timestamps," and it will return 00:00, 04:17, 11:42, 23:08. Those are not measurements. They are the model doing what it always does — producing the most plausible next token. Episodes have chapters roughly like that, so it writes chapters roughly like that. Nothing checked them against the audio, and nothing will unless you do. This is hallucination in its most quietly damaging form, because a wrong timestamp does not read as wrong.

Get the layers right, though, and AI genuinely does collapse the job: layer one replaces the scrub pass entirely, and layer two turns a time-coded transcript into every other artifact in about a minute.

Recommended Tools & Models

Two purchases, not one. You need something that hears and something that reads.

Layer one — transcription and diarization. Per hour of audio, checked July 2026.

Every vendor advertises an accuracy number, and none of them measure the thing that will hurt you. Word error rate is not diarization error rate, and diarization is where podcasts break. A 2025 benchmark of five state-of-the-art diarization systems across four datasets — 196.6 hours, five languages — put the best commercial system, PyannoteAI, at 11.2% diarization error rate, and the strongest open-source alternative, DiariZen, at 13.3%. The paper's framing is blunt: diarization "remains an unsolved problem," and "errors in diarization propagate to downstream systems and cause wide-ranging failures." That is your show notes it is describing.

Layer two — the language model. Any current frontier model does this job; the prompt matters more than the choice. An hour of speech is roughly 8,000-10,000 words, so a 90-minute episode runs 12,000-15,000 words — comfortably inside any modern context window. Paste the whole time-coded transcript rather than chunking it: a model that only sees the second half cannot tell you which moment in the episode was the best one. NotebookLM is worth a look for one specific reason — it grounds answers in the documents you upload and cites the passage each claim came from, which is exactly the behaviour you want when the risk is invented quotes.

Step-by-Step Implementation

1. Write the show vocabulary file — once

Before you transcribe anything, list every word your show says that the internet does not: guest names, company names, products, the jargon of your field, your co-host's surname.

This is the highest-leverage artifact in the pipeline and almost nobody makes one. Speech-to-text mangles proper nouns it has not seen — and it mangles them confidently and consistently, so the wrong spelling appears fifty times and looks deliberate. Then it flows into your notes, your title, and your transcript page, where Google indexes it.

Every serious system takes the list as an input: keyterm prompting in ElevenLabs Scribe (+$0.05/hr), the keyterms_prompt parameter in AssemblyAI (up to 100 terms; note that the older word_boost is deprecated and is rejected outright by the current Universal-3 models), the glossary in Descript, and Whisper's initial_prompt — which is capped at 224 tokens, a real constraint. You cannot feed Whisper a 300-name glossary. Include this episode's guest plus your recurring terms, and prioritize the words the model actually gets wrong over the ones it already handles.

Add each new guest's name and company before you hit transcribe. Thirty seconds.

2. Transcribe with diarization and time codes on

Non-negotiable settings: diarization enabled, timestamps enabled, export to a format that keeps them — SRT, VTT, or JSON.

If you self-host Whisper, know that its own timestamps drift. It transcribes in 30-second windows and uses its own predicted timestamps to decide where the next window starts, so an error in one window displaces the next, and the error accumulates across a long episode. This is why WhisperX exists — it re-aligns the transcript against the audio with a phoneme model, materially improving word-timestamp precision (84.1% against Whisper's 78.9% on the AMI corpus, at a 200 ms tolerance). Note how far that still is from perfect: forced alignment is better, not exact. If your chapters need to land on the right sentence, you want it anyway.

3. Fix the speaker labels before anything else

The step to do first, and the one everyone does last or never. Diarization fails in predictable places, so check those:

• Crosstalk and interruptions — the overlap is where error rates spike.
• The first two minutes, before the system settles on its speaker clusters.
• Any point where a third voice enters. Two speakers is the easy case; error climbs with speaker count.
• Backchannel — "mm-hm," "right," "yeah" — which routinely gets assigned to whoever was already talking.

Then find-and-replace: SPEAKER_00 → the host's name, SPEAKER_01 → the guest's. Layer two is about to read this transcript and take every attribution in it at face value. Ten minutes here is what stops you misquoting a real person in public.

4. Generate chapters — from the time codes, not from the model

That "exact first sentence" column is your verification handle. Take the three most important chapters, jump to those timestamps in your editor, confirm the audio says what the model claimed. Ninety seconds, and it catches the failure nothing else catches.

The platform rules, verified July 2026:

Write to Apple's two-minute floor and one list satisfies all three. This matters because a model asked for "chapters" will cheerfully hand you nine of them on a 40-minute episode with a 45-second chapter in the middle. Apple states its floors as requirements and gives you no error message when you miss them — so write to the floor rather than find out what happens.

5. Generate the notes, title, and description

Then check the pull quotes. Actually check them — take the quoted string, search for it in the transcript, confirm it is there exactly. Under a minute, and it is the difference between quoting your guest and misquoting them.

6. Publish the transcript

To the podcast apps. Apple Podcasts auto-generates transcripts (iOS 17.4+, in eleven languages including English, French, German, Spanish and Portuguese) — but you can override them by linking your own VTT or SRT in the RSS feed and setting the show to display the transcripts you provide. If you built a vocabulary file and fixed the speaker labels, yours is better than the automatic one.

To your own website. This is the podcast-SEO asset nobody uses. Audio is not indexable; text is. An hour of speech is 8,000-10,000 words of the exact language your audience searches with, and a transcript page — episode title, chapters as jump links, transcript below — turns every episode into a page that can rank. It is also the only version a D/deaf or hard-of-hearing listener can consume at all, which is reason enough on its own.

7. Automate it once it works

With the prompts stable, n8n can watch a folder, push new audio to a transcription API, pass the time-coded result to a model, and drop the output in your drafts. Do not automate before the manual version works — you will only produce wrong show notes faster. Keep the human check on the two things that break: speaker labels and timestamps.

Real-World Examples

Example 1: The timestamps that pointed at nothing

Before. A producer exports a plain-text transcript, pastes it into ChatGPT, asks for chapters with timestamps:

00:00 Introduction 03:45 Rachel's early career 12:10 Why she left Google 24:30 Building the first prototype 41:15 What she'd do differently

It looks perfect. Right shape, real topics, numbers ascending plausibly. She publishes it.

What was actually true: "Why she left Google" starts at 09:02. At 12:10 the guest is mid-sentence about her dissertation. Every listener who taps that chapter lands in the wrong place. The transcript she pasted had no time codes, so the model had nothing to derive them from — it produced those numbers the way it produces any other token.

After. She exports SRT instead of plain text and adds one line to the prompt: "Every timestamp must be copied character-for-character from a time code in the input." The chapters now land on the sentence they name. Nothing changed about the tool or the model. The input changed.

Example 2: The quote the guest never said

Before. A 90-minute interview. The model returns a pull quote, and it is a great one:

"We were three weeks from running out of money and I still wouldn't take the deal."

It goes in the description, on the audiogram, and in the newsletter.

What he actually said, at 01:07:22: "...and, I mean, we were — what, a month out? Six weeks? — from the end of the runway, and, look, I still didn't want to take it, for reasons I'm not sure I could fully defend now."

The model did not lie. It did what summarization does: compressed the sense into the cleanest sentence carrying it. But "three weeks" is not "a month, six weeks," and the hedge — reasons I'm not sure I could fully defend — was the honest, interesting part, and it is gone. A real person is now inside quotation marks saying something he did not say.

After. The prompt requires verbatim extraction with a time code, and the producer searches the quoted string against the transcript before publishing. What survives is messier, and it is what he said.

Example 3: The mangled name that reached Google

Before. The guest works at Hugging Face and cites a paper by Yann LeCun. With no vocabulary list, the transcription hears "hugging space" and "Yan Lecoon" — consistently, in all eleven places they occur.

Layer two cannot know better. It reads "hugging space," so it writes "hugging space." The error propagates into the show notes, the description, the pull quote, and the transcript page. The episode is now indexed against a company that does not exist, and the guest's employer will notice.

After. A twelve-line vocabulary file fed in as keyterm prompting before transcription: Hugging Face, Yann LeCun, LLaMA, tokenizer, RLHF, Gradio…. The names come out right at the source, and every artifact downstream inherits the correct spelling. The fix costs $0.05 per hour of audio and thirty seconds of typing.

Industry-Specific Applications

Solo shows and two-person interviews. The easy cases. With one speaker there is no diarization at all, so the least reliable component of the pipeline is simply absent. Two speakers is what systems handle best — provided the voices are distinguishable, which two guests of similar gender, age and accent are not. The timestamp rule still applies to both.

Panels and roundtables. The worst case; plan for the diarization to be partly wrong. Error climbs with speaker count, and a panel is crosstalk by design. So record every participant to a separate track and transcribe the tracks individually — then you know who spoke because the microphone knows, and diarization leaves the pipeline entirely. This is the best fix available, and it is a recording decision, not a software one.

Narrative and heavily-edited shows. A specific and expensive trap: generate chapters from a transcript, then re-edit the audio, and every timestamp after the first cut is wrong. Always generate from the final master. This bites people who build a slick pipeline and wire it to the wrong file.

Non-English shows. Check language support at layer one before committing, and note that Apple's and Spotify's automatic chapters are English-only. Quality falls off outside high-resource languages — and if you cannot read the output, you cannot audit it.

Best Practices

• Timestamps are copied, never computed. A timestamp that did not come out of a time-coded transcript is fiction.
• Fix speaker labels first. Ten minutes at the top of the chain, or six wrong artifacts at the bottom.
• Keep a show vocabulary file and update it with each guest before transcribing.
• Pull quotes are extracted, not summarized. Verbatim, with a time code, checked against the transcript. You are quoting a real person.
• Write chapters to Apple's two-minute floor and one list works on all three platforms.
• Separate tracks for panels. Solve diarization with a microphone instead of a model.
• Generate from the final master, never the rough cut.
• Publish the transcript — for the listeners who need it, and for the search traffic audio cannot earn.
• Tell the model to mark uncertainty rather than guess. [VERIFY] on an ambiguous name is a small instruction with a large payoff.

Common Pitfalls

Invented timestamps. The defining failure of this use case. A model with no time codes produces timestamps anyway; they are plausible, ascending, and wrong, and nothing in the output signals it. See hallucinations — this is that, in a very convincing disguise.

Diarization you trusted. "Who spoke when" is an unsolved research problem, not a finished product feature — the best benchmarked system sits at 11.2% DER, and the errors bunch in exactly the crosstalk-heavy audio a good conversation produces. A quote attributed to the wrong guest is not a typo; it is something you published about a person.

Mangled proper nouns, silently propagated. The transcription mishears a name once, then mishears it identically forever, so it never looks like an error. It reaches your title, your description, and your indexed transcript page.

Hallucinated quotes. Summarization compresses; compression rewrites. Asked for a "great quote" from 90 minutes of speech, a model will produce one — cleaner and punchier than anything said aloud, because it was written rather than spoken. Extract verbatim; verify by search. Layer one hallucinates too: a 2024 study (Koenecke et al., FAccT) found roughly 1% of Whisper transcriptions contained entirely fabricated phrases present nowhere in the audio, 38% of them carrying explicit harms — and the hallucinations concentrated in segments with long silences. Read the corpus before you read the rate: it was recordings of speakers with aphasia, selected for abnormally long pauses, so 1% will not be your number. The mechanism is what should concern you, and long pauses are ordinary in an interview.

Chapters that miss the platform floor. Nine chapters with a 45-second one in the middle throws no error anywhere — you get no warning, and no confidence that it rendered. Check the floor before you publish: 2 minutes, at least 3, first at 00:00.

Chapters regenerated against stale audio. Re-cut the episode and every timestamp after the cut is off by the length of what you removed.

A house style that is the model's, not yours. Ten episodes of AI show notes start to rhyme — same three-beat rhythm, same "dives into," same tidy summary shape. Your regular listeners hear your voice every week. They will notice the notes stopped sounding like it.

Measuring Success

• The scrub pass is gone. The concrete win. Time your current pass once, before you start, so you know what you replaced.
• Chapter accuracy. Sample three chapters an episode and jump to the timestamp. Does the audio say what the chapter claims? This should be 100%. If it is not, layer two is computing instead of copying.
• Speaker-label corrections per episode. If the count is climbing, your audio setup changed — new guest, worse room, more crosstalk — and it is telling you something.
• Quote fidelity. Zero published quotes that fail a search against the transcript. Pass/fail, not a percentage.
• Transcript-page search traffic. Pages that did not exist before, ranking for the words your guests actually said. The long-tail payoff, and it accrues over months.

Cost Analysis

A weekly show, 60-minute episodes: 52 hours of audio a year.

Layer one, via API. AssemblyAI at $0.21/hr (Universal-3.5 Pro) plus $0.02/hr diarization is $0.23 per hour of audio — about $12 for the year. ElevenLabs Scribe at $0.22/hr plus $0.05/hr keyterm prompting comes to $0.27/hr — a couple of dollars a year apart. This is the striking number: the transcription is nearly free, and it is the part doing the irreplaceable work.

Layer one, via an editor. Descript bundles transcription, diarization and editing: free for 1 hour a month, $16/month on annual billing for 10 hours. You are paying for the editor, not the transcription.

Layer two. The free tiers of Claude, ChatGPT and Google Gemini handle a 90-minute transcript. A $20/month plan buys higher limits and faster models — not better timestamps.

Setup. Three to four hours to build the vocabulary file, tune the two prompts, and run one episode end to end. Then 20-30 minutes per episode, most of it on the two checks that matter.

What it does not buy. Your judgment about which moment in the episode was the good one, and your responsibility for the words you put in a real person's mouth.

Related Tools

• Descript — transcription, diarization and text-based audio editing in one place
• ElevenLabs — Scribe for transcription with keyterm prompting
• Claude — long transcripts; reliable about following the copy-the-timestamp rule
• ChatGPT — titles, descriptions and social copy
• Google Gemini — large context for multi-hour episodes
• NotebookLM — grounds answers in the transcript and cites the passage, which helps with quotes
• n8n — wiring the pipeline together once it works
• Perplexity AI — checking the claims, names and links your guest mentioned

Related Models

• Claude Sonnet 5 — careful with long, messy transcripts and literal instructions
• GPT-5.5 — strong titles, descriptions and social copy
• Gemini 3.5 — large context for full multi-hour transcripts
• Claude Haiku 4.5 — cheap enough to run across an entire back catalogue

New to writing prompts? Start with prompt engineering — the constraint separating a working chapter list from a fictional one, copy the timestamp, do not compute it, is a single sentence and it is the whole difference. For the underlying technology, see voice recognition and audio processing.