Cleaning up an automatic transcript: fillers, timestamps and chapters

Automatic transcription got good enough that everyone has transcripts now — of meetings, interviews, lectures, podcast episodes, voice notes. What nobody warns you about is that a raw transcript is not a document. It is a record of speech, and speech contains an enormous amount of material that exists only to buy the speaker half a second of thinking time. Turning that record into something a person will actually read is a short, repeatable job.

What the machine gives you

Depending on the tool, a raw export contains some mix of: filler words (um, uh, like, you know, I mean), false starts and stutters where the speaker restarted a sentence, bracketed annotations such as [inaudible], [laughter] or [crosstalk], speaker labels of varying consistency, and timestamps — either as a subtitle file with numbered cues, or inline every few seconds.

Each of these needs a different decision, which is why a single "clean up" button rarely produces what you want. The voice transcript cleaner separates them: fillers, stutters and annotations are individually switchable, so you can strip um from an interview while keeping [laughter] that matters to the transcript, or the reverse for a technical talk.

Decide what the transcript is for first

This determines everything else, and doing it after the editing means doing the editing twice.

A record. Legal, medical, research, or anything where what was said matters more than how it reads. Keep the fillers, keep the false starts, keep the annotations, keep the timestamps. Clean nothing but the obvious tool artefacts. Editing a record for readability destroys the thing that makes it a record.

Something to read. Show notes, an article draft, meeting minutes, a summary you will hand to someone who was not there. Strip all of it. Fillers carry no information on the page, even though they carried plenty in the room.

Input to a model. Strip aggressively — every filler is a token you pay for, and a page of um genuinely degrades the summary you get back as well as costing money.

Getting from subtitles to prose

Half of all transcripts arrive as SRT or VTT because that is what the transcription tool exports. That format is cue numbers, timecodes and text fragments broken at display width rather than at sentence boundaries — unreadable as a document.

The SRT to text converter drops the numbering and timecodes and rejoins the fragments into continuous prose. Do this before the filler pass, not after: cleaning a file while the timecodes are still interleaved leaves you re-checking every cue, and it is easy to strip a line that was actually a timestamp.

Going the other direction matters too. If you are producing subtitles rather than consuming them, check the result with subtitle reading speed, which measures characters per second per cue and flags the ones nobody can read in the time they are on screen. Broadcast practice sits around 17 characters per second for adult programming and lower for children's; automatically generated subtitles routinely exceed both, because the machine has no concept of a viewer.

Chapters

Once you have a clean transcript you have the raw material for chapter markers, which are the single highest-return addition to a long video or podcast episode: they get you a table of contents in the player, deep links people can share, and text that search engines can read.

The podcast chapter generator takes a list of chapter titles and their durations and produces the timestamped markers in the format players expect — cumulative offsets calculated for you, which is the part that is fiddly by hand and easy to get wrong by one segment. Write the titles from your cleaned transcript, put the segment lengths beside them, and paste the result into your description field.

Write chapter titles as descriptions, not labels. "Why the migration failed" earns a click; "Part 3" does not.

Text going back out as speech

The reverse trip has its own hazards. Feeding a document to a text-to-speech engine — for an audio version of an article, a voice interface, or an accessibility pass — produces strange results when the text contains things nobody would say aloud: markdown syntax read as characters, URLs spelled out character by character, emoji announced by name, tables read as a stream of pipes.

The TTS sanitizer handles that pass — stripping markup, converting or removing URLs and emoji, and normalising the punctuation that makes engines pause in odd places. Run it on the final text, after all other editing, since anything that reintroduces formatting undoes it.

The order that works

1. Convert subtitle files to plain prose.
2. Decide which category the transcript belongs to.
3. Run the filler, stutter and annotation passes you chose.
4. Read it once end to end and fix the speaker attribution, which no tool can verify for you.
5. Pull chapter titles out of the cleaned text and generate the markers.
6. If it is going to a speech engine, sanitise last.

One habit worth keeping: retain the raw export. Cleaning is lossy, and the first time someone disputes what was said in a meeting you will want the version with the false starts in it. Keep the original file next to the edited one rather than editing in place.

Transcripts of meetings and interviews are frequently confidential — legal calls, medical appointments, salary discussions, private interviews — and uploading one to a web service to have its filler words removed is exactly the wrong trade. Every tool here runs locally in your browser; the transcript never leaves your machine.