Heteronyms in Text to Speech: Why TTS Can't Tell Wind from Wind

Heteronyms are words spelled identically but pronounced differently depending on meaning and context. In text to speech, they represent one of the hardest unsolved production problems: the spelling gives the model zero signal about which pronunciation to use. "The wind will wind the kite string" contains two completely different sounds for the same four letters, and the only way to get both right is to understand the sentence.

A recent thread on r/speechtech surfaced the frustration directly: developers building pronunciation-teaching apps found that TTS engines routinely read "wind" the breeze when the script calls for "wind" the action, and STT transcription collapses both into the same token with no disambiguation. The problem compounds in production. One wrong pronunciation per hundred clips is manageable. One wrong pronunciation per hundred clips across 50,000 daily outputs is 500 mispronounced clips shipping without anyone noticing.

What are heteronyms and why do they break TTS?

A heteronym is a subset of homographs: words that share spelling but differ in both pronunciation and meaning. "Bass" the fish (/bæs/) and "bass" the musical range (/beɪs/). "Tear" the drop (/tɪr/) and "tear" the rip (/tɛr/). "Lead" the guide (/liːd/) and "lead" the metal (/lɛd/). English has at least 150 to 200 commonly cited heteronym pairs, and many appear in everyday text.

TTS systems convert text to speech through a grapheme-to-phoneme (G2P) pipeline. The G2P module maps letter sequences to phoneme sequences. For most words, this mapping is deterministic: "hello" always maps to /həˈloʊ/. Heteronyms break this because the same letter sequence maps to two or more valid phoneme outputs. The G2P module has to choose, and without context, it guesses.

Rule-based phonemizers like eSpeak-ng handle heteronyms through dictionary lookups and hardcoded rules. When a word has multiple pronunciations, the system defaults to the most common one. If your text uses the less common meaning, you get the wrong pronunciation. Neural G2P models improve on this by processing surrounding tokens, but they still fail on edge cases, low-frequency meanings, and sentences where syntax alone does not resolve the ambiguity.

The W3C Specification for Spoken Presentation in HTML explicitly names heteronyms as a core problem for TTS, noting that "in the English language heteronyms are words that are spelled identically but have different pronunciations and different meanings."

How bad is heteronym accuracy in current TTS systems?

Worse than most teams expect. Research published at EACL 2026 by Sharif University of Technology evaluated homograph disambiguation across multiple TTS architectures. Baseline systems using rule-based phonemizers (eSpeak) achieved only 43.87% accuracy on homograph disambiguation, meaning they chose the wrong pronunciation more often than the right one.

The same study found that existing G2P tools for Persian, a language with heavy homograph ambiguity, had phoneme error rates between 15% and 50%, with homograph disambiguation accuracy falling below random baseline. Context-aware methods using word co-occurrence statistics improved accuracy by up to 30 percentage points (Qharabagh et al., 2025), and the best system (Piper + LCA G2P) reached 77.67% accuracy, a significant improvement but still wrong on nearly one in four heteronyms.

NVIDIA's NeMo TTS framework maintains explicit heteronym lists for English, German, and Spanish in its text normalization config, treating heteronym handling as a dedicated preprocessing step rather than something the acoustic model resolves on its own.

These numbers matter at scale. If a voice agent handles 50,000 calls per day and 3% of utterances contain a heteronym, roughly 1,500 outputs per day include a word that might be mispronounced. At 77% accuracy, that is still roughly 345 wrong pronunciations shipping daily.

What are the most common English heteronyms that trip up TTS?

The heteronyms that cause the most TTS failures tend to be high-frequency words where both pronunciations appear regularly:

The stress-shift pattern (noun on first syllable, verb on second) covers roughly half of English heteronyms: object, subject, project, present, record, permit, contract, desert, import, conduct, conflict, insult, rebel, suspect, survey. This pattern is predictable enough for a part-of-speech tagger to resolve, but only when the POS tagger itself is accurate, which in informal or domain-specific text, it frequently is not.

How do production teams fix heteronym pronunciation?

Four approaches, from simplest to most robust:

1. SSML phoneme tags. The W3C SSML specification provides a <phoneme> element that forces a specific pronunciation. For "wind" the breeze: <phoneme alphabet="ipa" ph="wɪnd">wind</phoneme>. This works for static scripts where you know every heteronym in advance. It fails at scale because it requires manual annotation of every ambiguous word in every script.

2. Custom pronunciation dictionaries with POS rules. Map each heteronym to its pronunciations with part-of-speech conditions. "Lead" as verb → /liːd/, "lead" as noun → /lɛd/. The TTS preprocessing step runs POS tagging, looks up the heteronym, and selects the pronunciation matching the tagged part of speech. NVIDIA NeMo uses this approach, maintaining heteronym lists per language alongside a G2P converter for out-of-vocabulary words.

3. Context-aware G2P models. Transformer-based models (BERT, RoBERTa, or task-specific fine-tunes) process the full sentence to disambiguate heteronyms. The EACL 2026 study showed this improves homograph accuracy by up to 30 percentage points over rule-based baselines. The tradeoff: these models add latency. The service-oriented architecture proposed in that study decouples the context-aware phonemizer from the TTS engine, running it as an independent service to avoid blocking the synthesis path.

4. Per-output validation and retry. Even the best disambiguation model will get some heteronyms wrong. The production-grade fix is to validate every output against a reference and catch errors before they ship. Run the synthesized audio through STT, compare the transcript against the input, flag discrepancies on known heteronyms, and regenerate only the clips that failed.

Onepin is a voice workflow platform that orchestrates, validates, and ships production-ready audio across 100+ TTS models. For heteronyms, Onepin's orchestration layer applies pronunciation dictionaries and validation logic across providers, so a heteronym fix written once propagates to every model in the pipeline. When a clip fails validation, the system regenerates with corrected phoneme input, not a full batch re-run.

Why is the heteronym problem worse in multilingual TTS?

Heteronyms exist in every language, but the specific failure patterns vary. Mandarin Chinese uses tonal distinctions where the same syllable "ma" means mother, horse, scold, or question marker depending on tone. Arabic and Hebrew omit vowel markings in standard written text, making nearly every word a potential homograph. Russian uses stress position to change meaning: замок (castle) vs. замок (lock). Persian's Ezafe phoneme, a connecting /e/ sound between related words, must be inferred entirely from context, with the EACL 2026 study showing baseline F1 scores as low as 19.58% for Ezafe detection.

For multilingual TTS pipelines, every language is a separate failure surface. A disambiguation model trained on English handles "read" and "lead" but has no information about Mandarin tones or Persian Ezafe. Each locale needs its own heteronym list, its own disambiguation logic, and its own validation baselines.

This is where most production pipelines break. Teams validate English, ship the other languages on assumption, and discover the failures through user complaints.

What about end-to-end neural TTS models? Don't they solve heteronyms?

End-to-end models like VITS, which map raw text directly to waveform without an explicit G2P step, handle many heteronyms implicitly through their attention mechanisms. The model learns pronunciation patterns from training data, including contextual usage. For common heteronyms in well-represented contexts, this works.

But end-to-end models have their own failure modes. They tend to default to the most frequent pronunciation in their training data. If "bass" appears more often in music contexts than fishing contexts in the training set, the model will pronounce it /beɪs/ even when the text is about fishing. The error is invisible at the model level because the system never explicitly represents the phoneme choice. There is no intermediate step to inspect, override, or correct.

The EACL 2026 study compared end-to-end systems (MatchaTTS, GlowTTS) against pipeline systems with enhanced G2P. All end-to-end models scored 43.87% on homograph disambiguation, identical to the baseline rule-based phonemizer, suggesting that homograph handling in these models was not meaningfully learned beyond the default eSpeak output.

For production teams, end-to-end models do not eliminate the heteronym problem. They absorb it into the model weights where it becomes harder to diagnose and fix.

How should teams approach heteronyms in their voice AI pipeline?

Start with three steps:

Build a heteronym inventory for your domain. If your content involves medical terms, financial figures, or navigation instructions, identify which heteronyms appear in your scripts. "Wound" (injury vs. past tense of wind), "present" (gift vs. to show), "contract" (agreement vs. to shrink) all carry domain-specific default meanings that differ from general usage.

Add disambiguation to your preprocessing, not your model selection. Switching TTS providers does not fix heteronyms. The problem sits in the text normalization and G2P layer, upstream of the acoustic model. A pronunciation dictionary with POS-conditional rules, applied before the text reaches the TTS API, catches most cases.

Validate outputs on known heteronym sentences. Maintain a test set of sentences containing your domain's heteronyms. Run every new model version, voice change, or provider switch against this test set. If "I read the contract" renders with present-tense "read" when past tense was intended, catch it before it ships.

Heteronyms are one of those problems that feel minor until they show up at scale. One mispronounced "lead" in a product demo is an awkward moment. Five hundred mispronounced outputs per day across a voice agent fleet is a pattern your users will notice and your support team will hear about.