A time-coded transcript is a transcript in which the text is anchored to the audio by timestamps. Instead of a plain page of words, every segment (and sometimes every word) carries the time at which it was spoken. That anchoring is what makes a transcript useful beyond reading: it lets you jump to the audio behind a sentence, cut video to speech, display captions in sync, and train speech models that must learn exactly when words happen.
This guide covers how time-coding works, the levels of timestamp granularity, the common file formats, the difference between verbatim and cleaned-up transcription styles, and what to require when transcripts are destined for AI training rather than human reading.
What time-coding adds to a transcript
Timestamps turn a transcript from a document into an index of the audio. For a video editor, that means finding a quote in seconds. For a captioning workflow, it means text appearing when the words are spoken. For a machine learning team, it means every training example can be traced to the exact audio it describes, and long recordings can be cut into aligned audio-text pairs automatically. The transcript itself may be identical; the timestamps are what make it machine-usable.
Timestamp granularity
Time-coding exists at several levels, and the right one depends on the use:
- Segment or utterance level. A start and end time per sentence, turn, or caption block. Standard for captions, interviews, and most transcription deliveries. Typical accuracy expectation is within a few tenths of a second.
- Word level. A timestamp per word, usually produced by forced alignment (software that snaps a verified transcript to the audio). Needed for karaoke-style captions, precise editing, and many ASR training pipelines.
- Phoneme level. Timing per speech sound, used in TTS voice building and pronunciation research. Almost always machine-aligned, spot-checked by humans.
Cost scales with granularity. Human-verified segment timing is cheap; human-verified word timing is not, which is why the standard pattern is human-verified text plus machine word alignment.
Common formats
The same content ships in different containers depending on the consumer:
- SRT. The plain-text subtitle standard: numbered blocks with start and end times. Universally supported, minimal structure.
- VTT (WebVTT). The web-native caption format, similar to SRT with styling and positioning options. What HTML5 video expects.
- JSON. The format of choice for AI training data: segments with times, speaker labels, word-level alignments, confidence scores, and any metadata, all in one structured file.
- CSV. Rows of start, end, speaker, and text. Crude but convenient for analysis in spreadsheets and dataframes.
- TextGrid. The Praat format used in phonetics work, supporting multiple aligned annotation tiers.
A capable transcription pipeline treats these as export targets from one internal representation, so you should not pay extra for format conversions. For a Spirelight project, JSON, SRT, VTT, or CSV delivery can be included when the required format is written into the scope.
Verbatim, clean verbatim, and edited transcription
Time-coding says when; transcription style says what gets written down. Three styles cover most work:
- True verbatim. Everything as spoken: fillers (um, uh), false starts, repetitions, backchannels, and notated non-speech events like laughter. This is what ASR training data needs, because the model must learn what people actually say, not an idealized script.
- Clean (intelligent) verbatim. Fillers, stutters, and false starts removed; wording untouched. The default for interviews, research, and meeting records meant for humans.
- Edited or non-verbatim. Grammar corrected and phrasing tightened. Fine for publishing, useless for model training.
The most common specification mistake in AI data projects is ordering clean verbatim out of habit. An ASR model trained on transcripts with fillers deleted learns to hallucinate their absence; disfluencies must be in the text if they are in the audio. TTS work, by contrast, often wants clean scripts aligned to fluent readings. State the style explicitly in the spec; the difference is invisible in a casual review and decisive in training. Our guides to ASR training data and TTS training data cover the respective requirements.
Quality checks for time-coded transcripts
Before accepting delivery (or training on what you accepted), check:
- Alignment accuracy. Sample segments and confirm the timestamps hit the audio, including at the end of long files where drift accumulates.
- Boundary sanity. No overlapping or zero-length segments, no text outside any segment.
- Style compliance. If the spec says true verbatim, the fillers must be there; count them in a sample.
- Speaker label consistency on multi-speaker audio, covered in our speaker diarization guide.
- Format validity. Files parse, times are monotonic, encodings are declared.
These checks belong in the acceptance workflow, not after training has already burned the budget. Our speech data quality guide covers the wider QA pass, and Spirelight can assess requested formats, timestamp granularity, and QA checks through the transcription and annotation brief; inclusions are confirmed in writing.