How to Edit and Proofread a Video Transcript

Why AI transcripts need editing and where the errors actually are

AI transcription tools using Whisper large-v2 or similar models typically produce 3–8% Word Error Rate on clean English audio, meaning 3 to 8 wrong words per 100. On a 20-minute video, that is roughly 28 to 75 words that need correction before the transcript is accurate enough to quote, publish, or formally use.

The distribution of those errors is not random, which is what makes systematic editing efficient. Proper nouns — speaker names, product names, company names, technical terms — are consistently the highest-error category because they are underrepresented in training data. The model has seen the word "transcription" millions of times. It may have seen the founder's name twice. The founder's name will be wrong; the generic word will not.

This pattern has a practical implication: before doing any linear read-through, search for all the proper nouns in the transcript first. Write down the 10–15 names, product names, and technical terms you expect to appear. Do a Ctrl+F search for each one. Fix the misspellings before you start reading. This targets the highest-error category in five minutes and leaves the linear read-through to catch the contextual errors — plausible-but-wrong substitutions — that search alone cannot find.

Proofreading versus editing: different tasks, different modes

Proofreading a transcript and editing a transcript are different jobs that require different mental modes. Mixing them in a single pass produces slower work overall and worse output on both tasks.

Proofreading is verification: you are checking what the transcript says against what was actually said in the video. For any transcript that will be quoted, published, or formally cited, this requires listening against the audio. Reading the text cold catches obvious errors and typos, but it misses plausible-but-wrong substitutions — words that fit grammatically and make approximate sense but are not what was said. The model is good at producing words that fit the surrounding context. That is exactly what makes its substitution errors hard to catch without the audio.

Editing is rewriting: you are changing the transcript's wording, structure, and flow to produce better written content. This is the right approach when converting a transcript to a blog post or article. For casual internal notes, editing is optional. For publication, it is necessary — spoken language, verbatim, reads badly. Filler words, false starts, sentence fragments, repetition — all of it needs to be cleaned up for written publication, and none of it is an error in the proofreading sense.

The most efficient approach: do a targeted proper-noun search pass first (5 minutes), then a linear proofreading pass against the audio (one-third of video duration), then an editing pass if the output is going to written publication. Three separate passes are faster in total than one pass trying to do all three things simultaneously.

Handling inaudible sections

Every AI transcript on real-world content contains sections where the audio is genuinely inaudible or too distorted for reliable transcription. The worst approach is to leave the model's hallucinated guess as if it were accurate — the model frequently produces a confident-sounding phrase over inaudible audio without any uncertainty flag. I've seen this cause real problems in research contexts: a transcript passed along as reviewed that contained a confidently wrong name, caught only because someone happened to know the speaker personally. Marking inaudible sections explicitly prevents exactly this.

Standard notation for genuinely inaudible content: [inaudible] in square brackets. For uncertain transcription where you can approximately hear what was said but cannot verify it: a question mark in parentheses after the uncertain word — (word?). A transcript with [inaudible] markers is more useful and more trustworthy than one with plausible-sounding but wrong words in those positions. If inaudible sections contain critical information, ask the original speaker to confirm the content in writing.

Find-and-replace: safe uses and dangerous uses

Find-and-replace is a powerful shortcut when used correctly and a source of new errors when used carelessly. The safe use: replacing a consistently misspelled proper noun with the correct version across the entire document. If the model has spelled a product name incorrectly throughout, one operation corrects every instance.

The dangerous use: replacing a string that appears in multiple contexts with different meanings. Replacing a common word that happens to also be part of a name will corrupt every instance of its legitimate use. The safe rule: only apply find-and-replace to strings that are unambiguous — proper nouns, technical terms, brand names. Use "match whole words" and "match case" options where available. For anything that could plausibly appear in multiple senses, correct manually.

Caption editing vs prose editing: different standards apply

If the transcript will be used as a caption file (SRT or VTT), the editing standard differs from prose editing. Caption text should match what was said verbatim — removing filler words is inappropriate because it creates a mismatch between what the viewer hears and what they read. That mismatch is disorienting and reduces usability.

For caption editing: fix errors (wrong words), check timing for synchronisation, ensure line lengths are manageable (42 characters per line is a reasonable online maximum). Do not rewrite or tidy the language. For prose editing: remove filler words, false starts, and repetitions; break long spoken sentences into shorter written ones. This is appropriate for blog posts and any written publication derived from a transcript. The transcript-to-blog-post workflow guide covers the full process from AI transcript to publishable article.

Verifying timestamp accuracy

For caption files, timestamps off by more than 0.5 seconds produce visible caption-to-speech desynchronisation. The fastest check: spot-verify 5–6 timestamp positions through the SRT file by jumping to those points in the video and confirming the caption matches the audio. If the first five checks are within half a second, the timing is almost certainly acceptable throughout.

If you find consistent drift — captions always appearing 1–2 seconds late — the SRT file may need a global offset adjustment. Most captioning tools and video editors can apply a constant offset to all timestamps in a file without requiring manual correction of each individual line.