BITC Timecode Transcription: Match the Transcript to the Clock

Short answer: burned-in timecode (BITC) is the clock printed on the picture, usually HH:MM:SS:FF. A transcript that quotes those numbers has to use the same clock, not “time since I pressed upload.” In VideoText you do that with Calculated SMPTE: type the timecode on the first frame, confirm the frame rate, and the export computes every later timestamp from that anchor.

This is a file workflow. You upload the video you have. You do not paste an address.

What BITC is asking the transcript to do

Editors, captioners, and legal or broadcast reviewers use the on-screen clock to find a line. A transcript timestamp of 00:12:04 is useless to them if the picture says 01:12:04:12, because the program started at one hour. The transcript has to add that hour, and it has to count frames the way the master did.

Two formats show up constantly:

Drop-frame does not drop picture frames. It skips some frame numbers (two at the start of each minute, except every tenth minute) so the displayed clock does not drift away from real time. The drop-frame timecode and SMPTE timecode glossary entries are the references. If you pick the wrong one, every timestamp after the first minute is a different number from the window burn, even when the words are right.

Calculated SMPTE in VideoText

On the Video to Transcript result, Timestamp format includes Calculated SMPTE. It is off until you select it. The control is the same idea as typing a start timecode into a transcription player: you enter it once, and the document uses it everywhere.

What you enter:

• Timecode on first video frame. Four numbers: hours, minutes, seconds, frames. The label says to enter the timecode visible on the first frame of the uploaded video. If the file was trimmed, the label changes to the first frame of the trimmed clip, and the page says frame-exact alignment is not guaranteed for trimmed clips.
• Frame rate. The menu lists 23.976, 24, 25 (PAL), 29.97 non-drop, 29.97 drop-frame, 30, 50, 59.94 non-drop, 59.94 drop-frame, and 60. If the file’s own metadata shows a rate, that rate is the starting point. For 29.97 and 59.94 the page asks you to choose drop-frame or non-drop when the file does not already say. An explicit choice wins over the detected rate.
• Interval. Calculated SMPTE still uses the interval control, the same idea as per-interval timestamps (the default interval is 30 seconds). You get a timecode on that cadence, written from the anchor, not a wall-clock guess.

The page states that those timestamps are computed from the anchor and the frame rate, and are not rewritten by formatting. Full verbatim and clean verbatim still apply to the words. Clean verbatim removes only explicit standalone hesitations. Ambiguous words and repetitions stay for you to review.

Speaker labels are separate, and they are Pro. Turn on Speaker labels (who said what) before you transcribe if each turn needs a name. You can rename the detected labels before export. Timestamps and names are independent: a wrong anchor is still wrong if the names are right.

A practical order

1. Watch the first frame and write down the burn, including the colon or semicolon.
2. Upload the file. Free speech files are up to 30 minutes and 2 GB. Pro is up to 4 hours and 10 GB, with 30 hours of speech a month. Pro is $14.99/month or $120/year.
3. Add names and terms if the speakers use them (up to 1,500 characters).
4. Generate, then open Calculated SMPTE. Enter the first-frame timecode and the frame rate that matches the burn.
5. Export TXT, DOCX, PDF, or the 3-column layout when the reader needs time, speaker, and text in separate columns. SRT and VTT from the same job use subtitle timing. They are not a substitute for an SMPTE document if the client asked for frame timecode in the transcript.
6. Spot-check the burn at a few places you choose (early, middle, late). The calculation follows the anchor you typed. If the first frame was wrong, or the file is drop-frame and you chose non-drop, the later numbers will not match the window. Fix the anchor and export again. Do not hand-edit a hundred timestamps.

That spot-check is the job. Calculated SMPTE does not look at the pixels of the burn. It does arithmetic from what you typed and from the frame rate. If those inputs match the master, the document matches. If they do not, the document is consistently wrong, which is easier to see than random drift, and it is still wrong.

Where a transcription player still fits

Express Scribe and tools like it are for people who type while they play the file, often with a foot pedal, and who type the on-screen timecode as they go. Stay with the player when the words must be typed by a person and the pedal is how you work.

Use Calculated SMPTE when you want a draft of the words from the file, then a document whose timestamps start from the same clock. You still read the burn. You stop retyping the whole program to get the numbers.

Drift you should not blame on the transcript

SRT time is real elapsed time in milliseconds. It stays in sync at any frame rate as long as the program speed did not change. The usual break is a conform (a 25 fps master played as 23.976, or the reverse). The import SRT into DaVinci Resolve note covers that case. Calculated SMPTE is the other problem: the transcript must display the production clock, including an hour start and drop-frame numbering. Fixing one does not fix the other.

If the burn and the transcript disagree by a constant amount, the anchor hour or the start frame is off. If they disagree more as the file goes on, the frame rate or the drop-frame flag is off. Those are the two checks. A third cause is a trimmed file: the page already warns that frame-exact alignment is not guaranteed after a trim.

What to deliver

Guideline Format keeps timestamps and speaker labels while it applies a style. Do the SMPTE check first, so a formatting pass is not papering over a wrong clock.