TL;DR: Auto-transcription mangles product names, jargon, and acronyms because speech models are trained to favor common everyday words, so a rare term loses to a familiar-sounding one. The fix has two layers: feed the recognizer a list of your terms before it transcribes (a recognition-time prompt, sometimes called a vocabulary or hotword list), and keep a small find-and-replace map for the few that still come out wrong the same way every time. In a controlled test on a base-size model, feeding the names took a transcript from 6/10 technical terms correct to 9/10; adding one map entry took it to 10/10.
The reason you can't already do this in most video editors is that their built-in transcription hides the vocabulary input. Premiere Pro's and DaVinci Resolve's built-in speech-to-text give you no place to pre-load your terms, so the model re-guesses "Nginx" or "Supabase" from scratch on every project and you re-fix the same words forever. The capability exists in the underlying speech models — it's just not exposed.
This guide explains why the errors happen, why the common workarounds (feeding it your old subtitles, or blind find-and-replace) don't hold up, the two-layer method that does, a reproducible before/after test with real numbers, and how to build a term list that fixes terms without corrupting the rest of your transcript.
Why does automatic transcription get technical terms and product names wrong?
Speech recognition models like Whisper predict the most likely words for a stretch of audio based on everything they were trained on. Because the training data is mostly ordinary speech, the model is biased toward common words — so an uncommon product name, an internal acronym, or a piece of industry jargon is fighting against a strong prior that pulls it toward a familiar-sounding alternative.
The failures are not random; they cluster in predictable categories:
- Product and tool names — "Supabase" becomes "Superbase," "Nginx" becomes "engine X" or "in Ginks."
- Acronyms spoken as letters or words — a three-letter internal query language, an API name, a framework abbreviation.
- Domain jargon — terms of art that are common in your field but rare in general speech.
- Proper nouns — people's names, place names, brand names the model has never or rarely seen.
These are exactly the words that carry the meaning of a technical video, which is why a single wrong term reads as sloppy even when the surrounding sentence is perfect. A viewer forgives an ordinary typo; they do not forgive your product's name spelled three different ways in one tutorial.
Why doesn't feeding it your old transcripts or subtitles fix it?
A natural instinct is: "I have clean subtitles from past videos with all the right spellings — can't the tool learn from those?" In almost every consumer transcription tool, no — there is no place to hand the recognizer prior transcripts, and even where there is, dumping whole SRT files in as context tends to confuse the model more than it helps.
The models don't fine-tune on your handful of files at recognition time. What they can accept is a short bias signal — a compact list of the exact terms and spellings you want favored. A wall of full sentences dilutes that signal; a tight list of proper nouns sharpens it.
The other common workaround — running a blind find-and-replace over the finished transcript — is risky because a rule that helps one video can quietly corrupt an unrelated one. A replace rule that rewrites a common syllable into your brand name will fire in the middle of ordinary words, or in a different video where that sound meant something else entirely. We learned this the hard way shipping preset correction rules: a global rule tuned for one context produced confident, wrong "corrections" in unrelated footage, and we ended up removing the presets entirely in favor of user-scoped lists. The lesson: corrections have to be scoped to terms you actually use, and applied precisely, or they trade one class of error for another.
What actually fixes it: a recognition-time term list plus a find-and-replace map
The durable fix is two complementary layers, in this order:
Layer 1 — a recognition-time term list. Before transcription runs, you hand the model a short list of your terms ("PostgreSQL, Nginx, Supabase, GraphQL…"). This is a standard capability of Whisper-family models, usually called an initial prompt, vocabulary, or hotword list. It doesn't force those words in; it tilts the model toward them when the audio is ambiguous, which is precisely when these errors happen. This catches the majority of cases.
Layer 2 — a find-and-replace map for the stubborn ones. Some terms come out wrong the same way every time — the model consistently writes "Svelt" for "Svelte." For those, a deterministic map (misheard → correct) applied after recognition cleans them up in one pass, and because it's scoped to your own terms, it doesn't touch anything else.
| Approach | Fixes | Risk |
|---|---|---|
| Blind find-and-replace only | Known exact mistakes | Fires inside unrelated words; corrupts other videos |
| Recognition-time term list only | Most ambiguous cases, up front | A few stubborn terms still slip through |
| Both layers together | The list catches most; the map cleans the rest | Lowest — each layer covers the other's gap |
Neither layer alone is enough, which is the whole point: the prompt handles the many, the map handles the few, and together they get you to a clean transcript without re-checking every line.
How much does a custom term list actually help? A before/after test.
To put a number on it, we ran a controlled test. We synthesized a 23-second narration of a software walkthrough containing 10 technical terms — PostgreSQL, Redis, GraphQL, Nginx, OAuth, Svelte, Tailwind, Webpack, Kotlin, and Supabase — and transcribed the exact same audio twice with a base-size Whisper model. The only variable changed between runs was whether the term list was supplied as a recognition-time prompt.
Svelt → Svelte map entry takes the result to 10/10.Feeding the recognizer the names took a base-model transcript from 6 of 10 technical terms correct to 9 of 10 — a single input change, no re-recording, no manual editing. The three it fixed (PostgreSQL, Nginx, Supabase) were the classic product-name manglings that would otherwise need hand-correction in every video.
The one it missed is the honest part of the story. "Svelte" kept coming out as "Svelt" even with the prompt, because the pronunciation is genuinely close and the model settled on the shorter spelling. A recognition-time list is a nudge, not a guarantee — which is why the second layer exists. Add "Svelt" as a known mishearing of "Svelte" once, and every future transcript is corrected automatically, taking the same clip to a full 10/10.
Method, so you can reproduce it: identical 23-second audio, one base-size Whisper model, single variable = the term list passed as the recognition prompt; a term counts as correct only on exact spelling. A larger model makes fewer mistakes to begin with, but the same bias-and-clean-up pattern holds — the smaller the model, the more the term list buys you.
How do you build a terminology list that actually holds up?
A good term list is short, specific, and scoped to what you actually say. A few rules from experience:
- List the canonical spelling, not sentences. "PostgreSQL, Nginx, Supabase, GraphQL, Kotlin" beats pasting whole paragraphs. The recognizer wants the target words, not context.
- Add known mishearings as explicit map entries. When a term comes out wrong the same way twice, record it:
Svelte ← Svelt,Nginx ← engine x. That converts a recurring error into a one-time fix. - Mind casing and punctuation. "OAuth," "GraphQL," and "PostgreSQL" have internal capitals that a model won't infer from audio; the map is where you enforce them.
- Keep it to your terms. Don't add common words or single syllables to a replace map — that's how you corrupt unrelated lines. Scope beats aggression.
- Build it once per project, reuse it forever. Transcribe episode one, collect the terms it got wrong, add them, and the rest of the series comes out consistent.
The payoff is not a magically perfect first pass — it's that the same term never costs you correction time twice.
Doing both layers automatically, and exporting back to your editor
You can do all of this by hand if you run a Whisper model on the command line: pass an initial prompt, then post-process with a script. Most people editing video won't. The practical version is a tool that keeps one term list, applies it as the recognition prompt and as the post-recognition map, and hands you back a standard SRT you drop into your editor.
That's what we build. GeekLink is a Mac app (Windows too) that runs speech recognition locally on your computer. You keep a single terminology list; it's used both to bias recognition up front and to normalize known mishearings afterward, then you export a standard .srt and import it into Premiere Pro, DaVinci Resolve, or any editor — the transcription your built-in tool couldn't get right, done once and reused across the whole series. It runs offline, so your footage never leaves your machine.
Once the terms are right, the remaining review is finding the ordinary mishearings that aren't in your list — a separate, smaller job covered in our guide to fixing AI subtitles by checking only the lines the model was unsure about.
FAQ
Why does my transcription keep spelling product names and jargon wrong?
Because speech models are trained mostly on everyday speech, so they favor common words over rare ones. When your audio contains an uncommon product name or acronym, the model often picks a familiar-sounding alternative — "Superbase" for "Supabase," "engine X" for "Nginx." The fix is to give the model your terms in advance as a recognition-time vocabulary list, and to keep a find-and-replace map for the ones that still come out wrong the same way each time.
Can I add a custom vocabulary or glossary to video transcription?
Yes — the underlying Whisper-family models accept a term list (an "initial prompt" or "hotword" list) that biases recognition toward your spellings. The catch is that most built-in editor transcription, including Premiere Pro and DaVinci Resolve, doesn't expose that input, so you need a transcription tool that does. In a base-model test, supplying the term list took a transcript from 6 of 10 technical terms correct to 9 of 10.
Why can't I just feed it my old subtitles or transcripts?
Speech models don't fine-tune on a few files at recognition time, and pasting whole transcripts in as context usually dilutes the signal rather than sharpening it. What works is extracting the exact terms and spellings you want favored into a short list, and adding recurring mistakes to a find-and-replace map. A tight list of proper nouns helps far more than a wall of full sentences.
Does Premiere Pro or DaVinci Resolve let you fix technical vocabulary in transcripts?
Their built-in speech-to-text does not offer a custom vocabulary input, so the model re-guesses your terms every project and you correct the same words repeatedly. A practical workaround is to transcribe in a tool that supports a term list, export a standard SRT, and import that into Premiere or Resolve for styling and layout.
Is a bigger model enough to fix technical terms on its own?
A larger model makes fewer mistakes to begin with, but it still favors common words and mishears rare product names and acronyms. A term list helps at every size; the smaller the model, the more it helps. Even on a large model, a find-and-replace map is worth keeping for terms that mishear consistently.
Will a find-and-replace correction break other parts of my transcript?
It can, if the rules are too broad. A replace rule built around a common syllable will fire inside unrelated words and in other videos. Keep the map scoped to your actual terms with their exact spellings, and lean on the recognition-time list for the gentle nudging — that combination fixes your terms without trading them for new errors elsewhere.
Disclosure: GeekLink is our own desktop app. The custom terminology list and mishearing-correction behavior described here are GeekLink features. Whisper is an open speech-recognition model family; Premiere Pro and DaVinci Resolve are third-party editors we export to, not affiliated with us. The before/after numbers come from our own reproducible test as described above.