Transcript timecodes that match the clip.
A transcript cuts footage only when its timecodes match the clip you are cutting. Word-level timing, elapsed time versus source timecode, burned-in windows and frame rates.
Transcript timecodes work for editing when three things match the clip: the timing is on every word, not every paragraph; the clock is the clip's, whether elapsed time from the first frame or the camera's source timecode; and the seconds are turned into frames at the clip's frame rate. Get one wrong and every mark you take from the transcript lands a few seconds off the line.
What does a transcript timecode point at?
A timestamp in a transcript is a position in one media file, counted from that file's first frame. It knows nothing about your timeline, your other camera or the number painted on the screener.
Density matters as much as the clock. A transcript made for reading has a stamp at every paragraph, which tells you a line is somewhere in the next forty seconds. A transcript made for editing has a start and end time on every word, which puts the playhead on the frame where the word begins. The second kind is what transcript-based editing runs on: click a word and you are there, and a paper edit built from it conforms itself.
Elapsed time or source timecode?
Two clocks run on every clip. Elapsed time starts at zero on the first frame of the file. Source timecode is the number the camera or recorder wrote into the file as it rolled, often time of day, so the first frame reads something like 14:22:07:12. Your editor shows source timecode by default; a transcription tool reports elapsed time, because it was handed a file and counted from the top.
So a stamp of 00:12:34 is the clip's start timecode plus 00:12:34 in the viewer. Write the start timecode at the top of the transcript and the arithmetic is one line, or switch the viewer to count from the first frame and the two clocks agree.
Burned-in timecode or embedded?
Embedded timecode is metadata inside the file. Burned-in timecode is a number painted into the picture of a screener so a producer on a laptop can write "the flood line at 01:14:22". A screener exported from a sequence usually starts at 01:00:00:00, which matches neither the camera's source timecode nor the transcript's elapsed time.
That leaves three clocks on one interview: notes in screener time, the transcript in elapsed time, the viewer in source timecode. Decide on one before anyone takes a note: burn the source timecode into the screener so notes match the viewer, or transcribe the screener the producer watched so notes match the transcript. If the clocks are already mixed, write the offset on the first page and apply it once.
Why does the frame rate matter?
Transcription tools store time in seconds; timecode counts frames, so turning 754.32 seconds into a timecode needs the clip's frame rate, and the frame at 25 is not the frame at 23.976. One stamp converted at the wrong rate is a frame or two off, but the error grows with the clock: non-drop timecode at 29.97 and timecode at 23.976 both fall behind real time by about 3.6 seconds an hour, so a two-hour interview matches at the top and is seven seconds off at the end.
Convert at the clip's rate, know whether 29.97 material is drop-frame, and transcribe constant-frame-rate files only: a phone or screen recording with a variable frame rate drifts against its own audio.
What do the editors' own transcripts do about this?
Inside an editor the clocks agree, because the transcript is attached to the clip it came from. Premiere Pro's Speech to Text transcribes the clip or sequence you have open, and a click on a word in the Text panel moves that clip's playhead. DaVinci Resolve Studio's Transcription window shows one clip's text and turns a selection of words into an In and an Out on that clip; the free edition does not transcribe. Final Cut Pro 11's Transcribe to Captions writes a caption track, each caption a reading-length chunk timed for display, so a Timeline Index search lands at the start of a caption and your ears find the word.
The problem appears the moment a transcript leaves the editor: a document from a transcription service, notes from a screener, a transcript of the recorder's audio when you are cutting the camera's picture. Then the clocks are matched by hand.
How do you get transcript timecodes that match the clip?
- Transcribe the file you will cut, not a copy with a different start. Transcribe the recorder's WAV and cut the camera's clip, and every stamp is in the recorder's time. Sync, then transcribe the synchronized or multicam clip or the camera file, so transcript and picture share a first frame.
- Write the clip's start timecode at the top of the transcript. Park the viewer on the first frame and put its timecode in the header with the clip name. Every stamp is then start plus elapsed; if the clip starts at zero, write that too.
- Ask for word-level timing. If the tool offers an export with a time on every word, take it. A stamp every paragraph is a reading copy; it finds the paragraph and leaves the word to you.
- Match the frame rate and the drop-frame setting. Convert seconds to frames at the clip's rate, and on 29.97 material check the drop-frame flag in the clip's properties. Convert variable-frame-rate files to a constant rate first.
- Check three stamps against the picture before you trust the rest. Start, middle, end. If all three are off by the same amount, the start timecode is wrong; if the error grows toward the end, the frame rate is.
- Carry the stamps into the cut as marks, not retyped numbers. Markers, keyword ranges or subclips in the editor, or an EDL or XML generated from the transcript, keep the numbers in one program. A paper edit listing clip name, In, Out and the first words is the readable version.
When the transcript is already someone else's
When the transcript arrives finished, from a service or a producer, you cannot change how it was timed, only how you read it. Find its zero by matching the first spoken line to the clip, write the offset down, and spot-check the end. If the stamps are per paragraph, each is the start of a search, not a frame, and across a dozen interviews that hunt is where the transcript stops saving time.
Doza Assist is a local-first AI editing assistant for interviews and dialogue, and its transcripts are timed on every word: click any word and the playhead lands on that frame. Fixing the text never moves the timing, so a corrected name or a reassigned speaker still lands every clip where the words are. Bring a Final Cut Pro project in as FCPXML, multicam and synchronized clips included, and the selects go back to Final Cut Pro as a pre-cut timeline, to Premiere Pro as an XML with markers and notes, and to DaVinci Resolve as an EDL or FCPXML, so the frames are counted once and never retyped. Nothing uploads, and the free trial runs every feature on the first 2 minutes of each file; the documentary editors page shows the whole pass.
Common questions
Why are my transcript timecodes off by exactly one hour?
Because the two things you are comparing start on different clocks. A screener or sequence that begins at 01:00:00:00 is an hour ahead of a transcript that counts from zero. A constant offset of any size is a start-time mismatch. Write it at the top of the transcript and apply it once.
Why do the timecodes drift further off the longer the interview runs?
An error that grows with the clock is a rate problem. The stamps were converted at the wrong frame rate, the drop-frame flag was wrong on 29.97 material, or the file has a variable frame rate. Check the clip's properties and reconvert at the clip's rate.
Do I need word-level timecodes for a paper edit?
Not to read and mark it. You need them to conform it. With a time on every word, each entry in the paper edit is an In and an Out you can type or import; with a stamp every paragraph, each entry is a search through forty seconds of footage, for every line in the cut.
Doza Assist transcribes every interview locally, finds the strongest moments across all of them, then sends your chosen ranges to Final Cut, Premiere, or Resolve. Your video never leaves your Mac.
Free trial: every feature on your first 2 minutes — no account, no card · 30-day money-back guarantee · Requires a Mac with Apple Silicon (M1 or later)