Create subtitles

What this is about

Automatic transcription has removed the typing work and left the editorial work untouched. Machines guess badly at product names, they punctuate by pause rather than by meaning, and they break lines wherever the buffer fills up. The result reads as a wall of words that arrives faster than anyone can follow. Good subtitles are edited: condensed where speech is redundant, broken at grammatical joints, and timed so a viewer can read the line and still look at the picture. That editing pass is short, but it is the whole difference.

The order matters more than the tools. Skip a step and you usually notice two steps later — by which point the fix costs several times as much.

What runs differently here

In planning terms, that means:

• Two lines maximum, broken at a grammatical joint, never in the middle of a name or a preposition and its noun
• Condense rather than transcribe: filler words and false starts belong in the audio, not on screen
• Burned-in subtitles guarantee display and block translation; a sidecar file allows both and can be switched off
• Check product names, place names and abbreviations by hand — machines get exactly these wrong
• Position matters: lines that cover lower-third graphics make both unreadable

Step by step

This order gets you there fastest:

1. Decide the purpose first: accessibility, sound-off viewing, or a base for translation. Each pushes a different choice about burning in, wording and how strongly you condense.
2. Generate the transcript automatically, then read it against the audio once from start to finish. The pass costs minutes and catches the errors that would otherwise be published.
3. Condense each cue so the line can be read comfortably in the time it is on screen. If a viewer has to choose between reading and watching, the subtitle is too long.
4. Break lines at meaning, not at width. Keep the article with its noun, the name in one piece, and the negation with the verb it negates.
5. Correct every proper noun, product name and abbreviation against the client's own spelling. This single pass prevents the most visible and most embarrassing kind of error.
6. Style for legibility: a clear typeface, a solid or shadowed background behind the text, and a safe area that keeps the lines clear of platform interface elements.
7. Deliver both forms when in doubt — a version with burned-in subtitles for social, plus the sidecar file for platforms that display their own. Producing both later means exporting twice.
8. Play the finished film muted on a phone before delivery. Anything you cannot follow that way needs shorter lines, longer timings or a bigger type size.

Common pitfalls

What most often goes wrong in practice:

• Publishing the raw automatic transcript because it looked close enough in the preview
• Three-line blocks that cover the picture and change faster than anyone reads
• Burning in subtitles on the master and then being asked for an English version
• Subtitles that sit exactly where the platform puts its own interface elements

With TillyGen

When subtitling and language versions are listed as deliverables in the TillyGen plan from the start, the edit leaves room in the frame for text and the budget carries the extra export rounds instead of absorbing them.

Change one constraint and the consequences travel through the whole plan: affected shots are flagged, the call sheet is regenerated, and nobody keeps working from yesterday's version.