The bug wasn't in the subtitle renderer. It was in how I was testing it.

An Electron app is the shell. When you press Generate, it asks ffmpeg to pull the audio out of the video as a 16 kHz mono file, then starts a Python subprocess running faster-whisper, which is Whisper on the CTranslate2 engine. The script reports progress as lines on its error stream and prints the finished transcript as one block of JSON, with a timestamp for every word, not just every sentence. Those word times are what make the fancy animations possible.

The window turns the edited transcript into an .ass file (Advanced SubStation Alpha) and ffmpeg burns it into the video through its bundled libass renderer. ASS is the one common subtitle format that supports custom fonts, pixel positions and per-word timing, and it's the same format hand-made subtitles use. Nothing is composited on a timeline afterwards: every animation is just a different recipe of ASS override tags.

The preview caption is an ordinary web element measured in screen pixels. The export is rendered against the video's real resolution, often a lot larger. Left uncorrected, a caption that looks right in the preview comes out a completely different size in the exported video. The cause is simple: the video is shown at a fraction of its real size, and that fraction has to be applied to every size in the style.

Now the preview works out how much smaller than the real video it is showing (the displayed width divided by the true width) and scales the font size, outline, shadow and letter spacing by it. On the export side, the subtitle file declares the video's real width and height as its canvas, and positions are stored as percentages and turned into pixel coordinates at export time. So a caption set to size 84 on a 1080 by 1920 reel is the same proportion on screen as in the final file.

Transcription is much faster on an NVIDIA card, so the script asks for the GPU first. The first trap was that the CUDA libraries installed from pip are not on Windows' DLL search path. The model loads happily, so nothing looks wrong, and then the first real transcription fails silently because the GPU libraries can't be found. The engine searches the system path, not the mechanism Python offers for adding folders, so the library folders are put on the path itself before anything is loaded.

The rule everywhere is the same: try the fast way, and fall back without asking. If loading the model on the GPU fails, the script switches to the CPU with 8-bit weights and says so in the progress line. For export, it asks the card's hardware H.264 encoder first. If the encoder isn't there, the output is retried with the CPU encoder, so a machine without a GPU still gets the same captions on the same video, only slower.

To make honest screenshots I drove the finished app end to end without changing it: a generated voice reading three sentences over a vertical 1080 by 1920 gradient, the real Generate button, then six real exports with a different animation each, and a frame cut from every result. It worked. The model loaded on the GPU in a few seconds, the 10-second clip came back as five captions with word timing in about four seconds, and each export took under a second. I also ran the transcription script with the Hugging Face hub switched to offline mode, and it loaded the cached model and finished normally, which confirms the model downloads once and then works without internet.

Looking at the results next to the preview turned up what no earlier test had. The karaoke colours are reversed in the export. In the preview, words light up as they're spoken. In the exported video the words still to come are the highlight colour. The cause is the way the subtitle format names its two colours: karaoke text starts in the secondary colour and changes to the primary as each word is sung, and the style puts the plain text colour in the primary slot. Swapping the two for the karaoke animation is the fix, and it's still on my list. Word-by-word animations ignore edits. Karaoke and word pop are built from Whisper's own words, so a correction typed into the transcript changes every other animation but not those two. And the preview wraps differently from the file: a long caption breaks onto two lines in the preview and sits on one line in the export, so the exported video is the thing to judge.

It transcribes, edits, styles, animates and exports end to end on a machine with or without a graphics card, and nothing about your video leaves the computer. It's what captions the reels and clips of Hamrah Podcast. Because it already worked, it's free for anyone who needs it: email me and I'll send the installer.

What it isn't yet: it's Windows only, it handles one video at a time, and it exports a burned-in video but not a separate subtitle file. The installer is about 1.3 GB because it carries a whole local speech engine, which is the point, not a compromise, but it means this isn't a five-megabyte utility. The installer isn't code-signed. The karaoke colours are the first thing I'll fix, followed by making the word-by-word animations respect corrections.