How to search a transcript for a word that was misheard or misspelled

StoryFolder —

Part of: How to search footage by what's in it and what's said

Last updated: 2 September 2026.

Somebody in the interview says TikTok. You go looking for that line later and type tick tock, because that's the spelling you'd guess if you weren't sure. An exact search dies right there. The transcript reads TikTok, one word, capital T, capital T again, and tick tock is not a substring of it. StoryFolder's transcript editor doesn't die there. It searches around the mismatch: type it however you remember hearing it, and the line still comes up, marked approximate so you know it wasn't a literal hit. The spelling you are searching against came from the local engine that produced the transcript, not from you.

The failure this page is named for runs the other way. Whisper splits one word into two transcript tokens, so rest and ock sit on their own lines and a search for restock finds nothing without a matcher built to rejoin them. That join logic hasn't changed. What's changed is which real transcripts still produce the split: current normalization rarely leaves a word broken that cleanly anymore, so tick tockTikTok is the fixture that reproduces today.

New in 0.4. The transcript this page searches is produced on your own machine, by an engine and model StoryFolder downloads once. How local transcription works.

Why does exact transcript search fail on a word you heard correctly?

Because the recognizer's spelling of a word doesn't have to match yours, and substring matching treats every character as load-bearing. Whisper can spell a brand name in a way you wouldn't guess, drop a letter, transpose two, or write two words where you'd write one. A search box that only checks "does this exact string appear" returns nothing on all four, even though the word is sitting right there in the transcript.

Every exact-match search box does this to every misheard word. The difference is what happens next.

How does the matcher decide a near-match is close enough to trust?

It scores candidates, and it doesn't trust every near-match equally. An exact match scores highest. A partial match ranks next: you've typed the start of a word and haven't finished it, which is literally what you asked for, only incomplete. Below that sits a fuzzy match, a word within a small edit distance of your query. Lowest of the four is a joined or split match, where your query's two words correspond to the transcript's one, or the reverse. So a phrase that matches exactly always outranks anything approximate.

The fuzzy budget is tied to word length, on purpose. The shortest words get no slack at all, because at four letters one changed letter reaches a different real word rather than a mishearing. That's why cute never matches cube. Longer words get progressively more room, which is what lets komfort find comfort and hoodee find hoodie: one substituted letter each, comfortably inside the budget a word that length carries. Short words are exactly where a "close enough" search would generate the most false positives, so the shortest words get the least.

The distance check also counts a pair of swapped adjacent letters as one edit rather than two, so Pacfiic still reaches Pacific. Before any of that, the matcher lowercases everything and strips punctuation from the edges of a word while leaving internal apostrophes and hyphens alone, so restock. compares cleanly against restock and t-shirt stays one word.

Can a phrase cross a line or a pause in the transcript?

Yes. The matcher flattens the whole transcript into one stream of time-stamped words first, then searches that. So a phrase like "restock this brand" can span a cut in the transcript, or even a change of speaker, and still light up as one hit across both segments.

One thing it never touches: speaker names. If you're looking for something a specific person said, that's a visibility filter you set before you search, not something the query itself can match.

Why not just use a phonetic dictionary for English homophones?

Because it would only work for English. A table of how English words sound is a real technique and would catch some of these cases, but it does nothing for a transcript in Japanese or Russian, and this matcher has to work in any script. Edit distance and token joining don't care what alphabet they're looking at. A phonetic table would have made English-language transcripts the first-class case and everything else an afterthought. Normalization has been checked against Cyrillic («здравствуйте») and Japanese (こんにちは。) transcripts, and both match the same way an English one does.

What do you actually do when you get an approximate hit?

Read it before you trust it. An approximate match carries a visible pill and a tooltip saying exactly what the transcript has. For tick tock, that's The transcript says "TikTok." The word itself gets a dashed outline in the transcript line, so you're not hunting for what changed.

Search also opens on the best hit, not the first one in time. With fuzzy matching the earliest match in the file is routinely the weakest one, and landing there would make a search that actually worked look like it failed. You can still step forward and backward through every hit once you're there.

Where does this fuzziness stop working?

At the edge of the transcript editor. This matcher lives in one box: the transcript editor's own search. The Library and board search boxes, which is what you use to search shot metadata alongside the transcript across a whole project or your whole library, run plain case-insensitive substring matching, with no fuzzy budget and no split or join. Type tiktok there against a transcript that reads tick tock, and it finds nothing. That's a different search doing a different job. CL07-P1 covers what each box searches and why there are two.

FAQ

Can tick tock find TikTok? Yes. Typed as two words, it matches the transcript's single word TikTok through the matcher's split/join comparison, flagged approximate.

Can restock still find rest ock? Yes, the join logic that handles it hasn't been removed. What's changed is that current transcripts rarely produce a split that clean anymore, so it's not the demo to build a workflow habit around.

Will cute match cube? No. The shortest words get no fuzzy tolerance at all, because at four letters one changed letter reaches a different real word.

How much tolerance does a longer word get? More, in proportion to its length. komfort finds comfort and Pacfiic finds Pacific, each one edit away from the word you meant.

Does transcript search search speaker names? No. It searches spoken words only; which speakers you see is a separate filter you set before searching.

Is the Library search box fuzzy too? No. Library and board search use plain case-insensitive substring matching. The fuzzy matcher lives only in the transcript editor's search box.

Does StoryFolder use a phonetic dictionary for English? No, deliberately. A phonetic table would only help English transcripts, and this matcher has to work in any script.

← All articles