Vertical Video Captions That Don't Break: Overtone Cuts One Transcript Into 16:9 and 9:16
Scroll through any feed of interview clips and you will see the same small failure over and over. A line of caption ends on "the." A guest's name gets split across two cards. A number like "4.2 million" lands with "4.2" on one line and "million" on the next. Almost always, the clip started life as a wide video, someone cropped it to vertical, and the captions came along for the ride.
The captions were not wrong in the original. They were written for a frame twice as wide.
That is the problem a small open-source tool called Overtone is built around, and its answer is more interesting than "better captions." It argues that a caption file is the wrong thing to save in the first place.
The caption file is a layout, not a transcript
An SRT or VTT file, the two formats nearly every editor and platform reads, does not store what was said. It stores a list of boxes: this text, from this time to that time. The line breaks are baked in. So the moment you change the shape of the screen, every one of those decisions is wrong, and you either live with it or redo the captions by hand.
Most creators redo them by hand, or more often, don't.
Overtone flips the order. It keeps each spoken word once, with its time and who said it, in its own file (.overtone.json). Then it makes a separate "cut" of captions for each screen shape you need: 16:9 and 9:16 by default, or any shape you name. Each cut is drawn from the same words, so the wide version and the vertical version always agree on what was said and when. They just break the lines differently.
That sounds like a format nerd's detail. It is actually the whole point. When the words are the source and the layouts are disposable, adding a square version for one platform or a narrow one for a phone story costs nothing.
The rules a good captioner follows, written down
The second half of the idea is that line breaks should follow rules a person would agree with. Overtone's README spells them out, and they read like a style guide from a subtitling house:
- Lines avoid ending on weak words like "the," "of" or "and."
- Names and numbers stay together.
- Each speaker gets their own caption.
- A pause in the speech becomes a line break or a new caption.
The rules are versioned, so the same words with the same rule set always give the same captions. That matters more than it sounds. If you fix a misheard word and re-run, you get the same layout back with one word changed, rather than every caption shifting under you.
The maker, a company called Lont, published a small benchmark to back this up. On three English clips totalling about 21 minutes, 0.3% of Overtone's line breaks fell after a weak word with no pause in the speech. Filling each line to the character limit, the way many simple tools do, produced 28.8%. The SRT export from ElevenLabs produced 16.1%. Those are the maker's own numbers on a test set it chose, so treat them as a sign of intent rather than a verdict. Still, the gap is large, and the method is public enough that you could check it on your own footage.
The free part: re-cutting subtitles you already have
Here is where it gets practical. Overtone has two very different ways in, and the first one costs nothing.
If you already have an SRT or VTT file (from your editor, from YouTube's automatic captions, from a transcription service you already pay for), the recut command reshapes it into new layouts. It runs on your own computer, needs no account and no API key, and does not even need ffmpeg, the video tool most caption utilities depend on. You need Node.js, version 22.12 or newer, and one line:
npx overtone-captions recut interview.srt
That writes caption files for each shape. Drop the vertical one onto your 9:16 edit and the wide one onto your 16:9 edit.
There is one honest catch here, and it matters. An SRT file does not know when each individual word was spoken, only when each box starts and ends. So in recut mode, Overtone estimates word timing by spreading the words across each original caption. Its README says so plainly: "Word times are estimated from the cues." If your original captions were sloppy, the new ones inherit that sloppiness. Clean source in, clean cuts out.
The paid part: transcribing from scratch
The second way in is to hand Overtone the video or audio and let it transcribe. This is where it gets ambitious.
It sends the audio to two speech services by default: OpenAI's transcription model for the words, and Microsoft's Azure Speech for word timing and who is speaking. You can add ElevenLabs Scribe as a third listener. Where the services disagree on a word, Overtone plays that snippet to a model again and has a language model choose. Then a separate pass corrects misheard names and terms using context and a glossary you give it, so a guest's surname or a product name has a fighting chance of coming out spelled right.
Two design choices stand out.
The language model never sets times. Every word's timing comes from the speech services, which are built for that job. The language model only fixes spelling and labels speakers. That keeps the sync honest.
And edits the model is unsure about go on a review list for you to check by ear. That is the right instinct. A caption tool that silently "fixes" a guest's name into a different name is worse than one that leaves the typo.
On cost, the maker's benchmark puts transcription at about 2.3 to 2.5 cents per minute of audio at list prices, or about 2.9 cents with Scribe added. A one-hour podcast lands around a dollar fifty. You pay those services directly with your own keys, and a --dry-run option shows where the audio will go and what it will cost before anything is sent.
If you would rather nothing leave your machine, a --local flag runs the whole thing offline with whisper.cpp for the listening and Ollama for the correcting. The published accuracy numbers cover the paid route, not this one, so test it on your own audio before trusting it.
Put this into practice
The cheapest useful test takes about ten minutes.
- Pick one clip you have already published in two shapes. An interview you cut for both YouTube and Reels is ideal, because you already know where the vertical captions went wrong.
- Export the SRT from the wide version. Whatever tool made it is fine.
- Run recut.
npx overtone-captions recut yourfile.srt. No key, no account. - Lay the 9:16 output over your vertical edit and watch it with the sound off. Look for the three classic failures: lines ending on "the" or "of," split names, split numbers.
- Compare against what you shipped. If the new version is clearly better, you have found a step worth adding to every edit. If it is a wash, your existing captions were already decent and you can stop here.
If the test goes well and you transcribe a lot, try the paid route on one episode with --dry-run first, and pass a --context line describing the show ("Panel about urban cycling") so the correction step knows what names to expect. Then sit with the review list. That list is the part of the job no tool should do for you.
For anyone who publishes video on their own site, there is a third option: a plugin for video.js, a common web video player, that reads the .overtone.json file, so the same words can play as a wide cut or a vertical one. One file serves every screen. You can see it working in the browser demo, which plays Blender's open movies and a NASA interview in a wide player and a vertical one.
Where it falls short
Two languages get the full treatment. The line-breaking and number rules are written for English and Dutch. German, French, Spanish, Italian and Portuguese get language detection, and everything else gets neutral rules. In languages written without spaces, like Chinese, Japanese and Thai, a "word" becomes a whole phrase, so timing is per phrase rather than per word.
There is no editor. Overtone is a command-line tool and a player plugin. If you want to drag a caption boundary with a mouse, you will still do that in your video editor after export.
No translation, no sound tags. It will not make Spanish captions from English audio, and it does not write "[music]" or "[laughter]," which some platforms and accessibility standards expect.
Two-hour limit. Media longer than two hours is out of scope.
The benchmark is small and self-run. Three clips for line breaks, six clips in four languages for accuracy. That is enough to show the method works on the maker's examples. It is not enough to promise it works on your noisy location audio.
It is new. The repository went public at the end of October and had a couple of dozen stars when this was written. MIT licensed, so you can use it commercially and keep it running yourself if the maker loses interest, but expect rough edges.
Why this is worth your ten minutes
The real idea in Overtone is bigger than the tool. Captions have been treated as a finished layout for so long that nobody questions it, even as every piece of video now ships in three or four shapes. Saving the words and throwing the layouts away is simply the correct way to store this information, and once you see it, re-typing vertical captions by hand starts to look like retyping a document because you changed the font.
Whether Overtone itself becomes your caption tool or just changes how you think about the step, run recut on one clip you have already shipped. The comparison will tell you in a single viewing whether your vertical captions have been costing you watch time.
- Sources: Overtone on GitHub · Overtone README · Overtone demo