Why does my iPhone transcript mix up similar-sounding words?

It is a specific kind of transcript mistake, and it feels different from the others. The sentence is not garbled, the rhythm is right, every other word is correct — and then "there" sits where "their" belongs, or a transcript about baking reads "flower" instead of "flour." Nothing about the recording sounds wrong when you play it back, which is exactly what makes this error pattern confusing the first time you notice it.

The sound genuinely does not tell them apart

A mumbled word or a word lost to background noise is a signal problem — the audio carried less information than usual, and recognition had to guess with a thinner signal. Homophones are a completely different situation: "there," "their," and "they're" do not sound similar, they sound identical. There is no version of speaking any of them more clearly that changes the sound wave being captured, because the difference between them was never acoustic in the first place. It lives entirely in spelling and grammar — things a microphone has no access to.

Near-homophones work the same way with a little more wiggle room: "affect" and "effect," "whether" and "weather," "compliment" and "complement" differ by a sound so small that everyday speech routinely erases it. A recognizer working from audio alone is starting from the same impossible position a person would be in if they could hear the sentence but not see it written down.

What actually resolves the tie

Speech recognition does not stop at matching sounds to words — it also scores which sequence of words is more likely given ordinary language use, which is how it gets "recognize speech" right instead of "wreck a nice beach" most of the time despite the two sounding almost the same. That scoring is doing real work, and it is why homophone mistakes are the exception rather than the rule in a working transcript rather than the norm.

But that scoring is still a statistical habit learned from huge amounts of ordinary text, not an understanding of the specific sentence you said. It reaches for whichever word shows up more often in that grammatical slot across everyday language — and for a genuine homophone pair, both words are often common enough, in similar enough slots, that the odds are close. A person reading the sentence back resolves it instantly because they know what they meant. A statistical model has no version of "what you meant" to fall back on — only what is typical.

This is the flip side of the names problem, not the same problem

A name gets mangled because it is rare — the model has almost never seen it, so it substitutes something common instead. A homophone mix-up is the opposite: both candidates are usually ordinary, ordinary words, and the model is genuinely torn between two things it knows well rather than reaching for a stand-in. That is also why the fix is different. A wrong name tends to repeat the same way every time it comes up, once you notice the pattern. A homophone slip is decided sentence by sentence, based on which reading scored slightly higher for that specific bit of context — so the same word pair can land correctly in one sentence and wrong in the next within the same transcript.

Why quality settings and which recognizer ran do not change this

It is worth ruling out the usual suspects, because this error does not come from either of them. A higher sample rate captures more detail in the sound itself, which helps with a quiet or distant voice — but "there" and "their" produce the same sound at any sample rate, so more detail does not create a difference that was never there to capture. And on-device recognition and the server-based fallback are both scoring word sequences the same statistical way, on the same kind of ordinary training language, so neither pass has a meaningful edge over the other here. A transcript recorded in perfect conditions, at the highest quality setting, through either recognition path, can still land on the wrong half of a homophone pair — because the problem was never in the audio to begin with.

Fixing it means reading, not re-listening

Playing the audio back again does not help the way it does for a genuinely unclear word, because there is nothing to listen for more carefully — the sound is the same either way. What actually works is reading the transcript the way you would proofread any piece of writing: at a normal pace, following the meaning of each sentence rather than checking it against the recording word by word. You already have the one piece of information the recognizer never had — what you actually meant — and that is enough to catch a wrong "its" or a swapped "whether" almost as fast as you can read the sentence.

It helps to expect these mistakes in specific places rather than treating every sentence as equally suspect: the small, extremely common function words — there/their/they're, its/it's, to/too/two, your/you're — are where this shows up most, simply because those are the pairs with the highest number of everyday, similarly likely uses on both sides. A rarer, more distinctive homophone pair trips this far less often than the handful of short words almost every sentence relies on.

How Voice Studio fits into this

Voice Studio transcribes through Apple's Speech framework the same way for every recording: on-device recognition first, and only a retry with on-device recognition switched off — sending the audio to Apple's server — if that first pass comes back empty or errors. Both passes are general-purpose language models scoring word sequences by how ordinary language is normally used, not a system that has any access to what a specific sentence was actually about, so a homophone slip can show up either way and is not a sign either pass did something wrong. The transcript on any recording stays editable text, so correcting a swapped word is the same simple edit as fixing anything else in it, and exporting afterward as TXT or JSON carries whatever the transcript reads at that moment.

Common questions

Does mixing up "there" and "their" mean the app misheard me?

No. The two words sound identical, so there is nothing in the audio itself that could have told them apart. Recognition scores which word is statistically more likely in that sentence, and occasionally picks the wrong half of a genuinely identical-sounding pair.

Will re-transcribing the same recording fix it?

Usually not. The audio has not changed, and both recognition passes score word sequences the same statistical way, so the same close call tends to land the same way again unless something else changes.

Does a higher quality setting help with this kind of mistake?

No. A higher sample rate captures more detail in the sound, which helps with a quiet or unclear voice. It does not help here, because homophones produce the same sound regardless of how much detail is captured.

Is this more common with on-device recognition or the server-based fallback?

Neither has a real edge. Both are general-purpose language models scoring word sequences the same statistical way, so a homophone mix-up is about equally likely through either path.