Your TTS Captions Should Come From the Render, Not From a Transcript of It

Tim — Tue, 10 Nov 2026 16:49:43 +0000

If you generate voiceovers with text to speech, you already have the two things a caption file needs: the exact text and an engine that knows when each word is spoken. Yet a lot of pipelines throw both away, export an MP3 and then run speech recognition on it to get captions back. You can use a tool that returns SRT and VTT subtitle files from the same TTS render instead. This post explains why that's better, what the two formats look like and what tends to break when captions come from transcription.

Two pipelines, one of them backwards

Here's the common setup:

script.txt -> TTS -> voiceover.mp3 -> ASR -> captions.srt -> manual fixes

And here's the one to aim for:

script.txt -> TTS -> voiceover.mp3 + captions.srt + captions.vtt

In the first pipeline the speech recognition step is solving a problem you created. You had the ground truth text in script.txt. The ASR model has to guess it back from audio, and it also has to guess the timing. In the second pipeline nothing is guessed. The text comes from your script, and the timing comes from the synthesis.

What goes wrong with transcription-based captions

None of these are exotic. You'll hit all of them on a normal week of videos.

Proper nouns and jargon. Names, numbers and technical words are exactly where recognition fails. A library name, a CLI flag or a version number gets turned into the closest common word. You wrote it correctly once in the script, and now you're correcting it again in the captions.

Pronunciation overrides make it worse. If you respell a word so the voice says it right, a transcriber will write down the respelling. With same-render captions the override lives in a tag, and the subtitle keeps your written spelling:

The team at <say:en-jin-ex>Nginx</say> shipped the fix overnight.

The audio says "en-jin-ex". The caption says "Nginx".

Cue boundaries in the wrong place. A transcriber has to decide where one caption ends and the next begins. When that's done on fixed or estimated intervals, cues split mid-phrase and readers lose the thread. TTSLark writes cues from the synthesis timeline, so cue boundaries land on real pauses, with lines capped at 42 characters so they fit a phone screen.

Drift on long files. A subtitle file generated separately from the audio drifts a little more with every minute. Minute one looks fine in review. Minute twenty doesn't. When both files come out of one job, minute twenty lines up as well as minute one.

Edits mean redoing the whole chain. Change a sentence, and the transcription pipeline needs a new ASR pass plus another round of fixes. With same-render captions you edit the script, render again and the cues move with the audio.

How the timing actually gets produced

On TTSLark's standard English voices, the engine reports the start and end of every word while it renders. Cues are built from those word timings, so a caption changes exactly when its first word is spoken. This also holds for blended voices, because the English primary voice sets the timing while the second voice only contributes timbre.

For Japanese and Mandarin voices the approach differs a bit: a worker detects the pauses in the finished audio and anchors each cue to them, so a caption changes as each sentence begins. Either way, the text is yours and the timing comes from the actual audio file you'll ship, not from a separate guess.

Long scripts don't change this. There's no per-job character cap, and the engine works through the script in blocks and stitches them into one MP3 with one continuous subtitle track.

SRT vs VTT, briefly

You get both formats from every job, so the question is only which one to hand to which tool.

SRT is the plain, widely supported one. Numbered cues, a timestamp line with a comma before the milliseconds, the text, then a blank line:

1
00:00:00,000 --> 00:00:02,640
Every caption in this file

2
00:00:02,640 --> 00:00:05,180
was timed during synthesis,

3
00:00:05,700 --> 00:00:08,320
not guessed from the audio later.

WebVTT is the web format. It starts with a WEBVTT header, uses a period before the milliseconds, makes cue numbers optional and supports cue settings for position and alignment:

WEBVTT

00:00:00.000 --> 00:00:02.640
Every caption in this file

00:00:02.640 --> 00:00:05.180
was timed during synthesis,

A simple rule of thumb:

Video editors and YouTube Studio: SRT. Premiere Pro, DaVinci Resolve and CapCut all import it, and YouTube Studio accepts it when you add subtitles with timing.
Your own site: VTT, because the HTML <track> element expects it.

<video controls src="/media/episode-12.mp4">
  <track kind="captions" src="/media/episode-12.vtt" srclang="en" label="English" default>
</video>

Don't convert one into the other by hand when you already have both. Every manual conversion is one more chance to break a timestamp.

A short checklist before shipping

Run these checks on every new render. They take a minute.

Align at zero. Put the MP3 and the SRT on the timeline at the same start point and don't nudge either one. If you find yourself sliding captions around, something upstream is wrong.
Compare the last cue to the audio length. The end time of the final cue should sit right at the end of the speech.

   ffprobe -v error -show_entries format=duration \
     -of default=noprint_wrappers=1:nokey=1 voiceover.mp3
   tail -n 4 voiceover.srt

Spot check names. Listen to the first few minutes and every section with proper nouns. If a name sounds wrong, fix it with a pronunciation tag in the script and render again. Don't patch the caption text.
Pauses are part of the script. A <pause:2> tag (up to five seconds) creates real silence, and the next cue starts after it. That's better than stretching a cue to cover a gap.
Re-render, don't re-time. If the script changed, render the changed chapter again. Hand-shifting cues is how drift gets back in.

Cost, since someone always asks

Each credit covers 10,000 bytes of text on standard voices and makes up to 10 minutes of audio, with SRT and VTT included. English takes one byte per letter, while Chinese, Japanese and Hindi characters take three, so the same length of speech costs more bytes in those scripts. Free accounts get 5 credits that never expire, and commercial use is included on that plan too, with no watermark. For long narration, the narrator text to speech page covers the one-job long render in more detail.

The general point stands no matter which tool you use. If your TTS engine knows when each word was spoken, ask it for the captions. transcribing your own synthetic audio is extra work that makes the captions worse.