How to Fix TTS Pronunciation: Brand Names, Numbers, and Proper Nouns

TTS mispronunciation of brand names, numbers, and proper nouns is the most reported concrete failure across every major TTS platform — appearing in GitHub issues, G2 reviews, Reddit threads, and Trustpilot feedback alike. Custom pronunciation dictionaries and text normalization are the two systematic fixes. Without them, teams rely on regeneration roulette: re-run the synthesis request until a clean take appears. That works for ten clips. It fails at ten thousand.

Why does text to speech mispronounce names?

TTS models learn phoneme mappings from large general-language corpora, not your product vocabulary. When the model encounters "Onepin," "Cartesia," or "Synapse-9," it applies a statistical best-guess based on spelling patterns seen in training data. Domain-specific brand names, product identifiers, and proper nouns are rare in general-language training sets, so the model's pronunciation is a guess — and often wrong.

There are three categories of pronunciation failure that appear in production:

Brand and product names. Novel compound words, portmanteaus, and stylized spellings — "Lyft," "Figma," "NVIDIA" — do not map predictably to phoneme sequences. The model guesses from visual pattern.

Numbers, dates, and amounts. "$4.5M," "Q3 2026," and "10,000,000" each have a correct spoken form that depends on context. Without normalization, the model may read "$4.5M" as "dollar four point five M" — intelligible, but wrong for a client-facing audio asset.

Proper nouns and acronyms. "API" should read as letters ("A P I"), not as a word. "Dr." should become "Doctor." "St." could be "Street" or "Saint" depending on context. The model applies a single default that ignores context entirely.

How do custom pronunciation dictionaries fix this?

A custom pronunciation dictionary maps specific terms to their correct phoneme sequences, overriding the model's default behavior. Two formats are common in production: IPA notation and phoneme substitution strings.

With IPA notation, you write the exact phoneme sequence for the term. The brand name "Rime" maps to /raɪm/ to prevent the model from reading it as "rim-ay." Most enterprise TTS APIs accept IPA via SSML <phoneme> tags inline in your text, or via a lexicon XML file uploaded per voice profile.

With phoneme substitution, you tell the model to read the term as a different word that happens to produce the correct sound. "NVIDIA" might be substituted as "en-vidia" to get the right stress pattern. This approach is simpler but less precise than IPA.

The limitation of per-API lexicons is maintenance at scale. Every new product name, acquisition, or rebranding requires a manual update to the lexicon — and each TTS provider keeps its own format. A team using three TTS providers for different use cases now maintains three separate pronunciation dictionaries with no shared source of truth.

Onepin is a voice workflow platform that orchestrates, validates, and ships production-ready audio across 100+ TTS models. Onepin's pronunciation dictionary carries 4M+ entries per locale and applies the same normalized phoneme mapping regardless of which underlying TTS engine runs the synthesis. One dictionary update propagates across every provider in your stack.

What is text normalization in TTS?

Text normalization is a pre-processing step that converts non-standard written forms into their spoken equivalents before the synthesis request runs. The goal is to remove ambiguity before it reaches the model.

Common normalization rules:

• $4.5M → four point five million dollars
• Dr. → Doctor
• API → A P I
• Q3 2026 → third quarter twenty twenty-six
• 10,000 → ten thousand
• St. → Street (in an address context) or Saint (in a name context)

The last example illustrates why context matters. Pure rule-based normalization handles the easy cases. A normalization layer that understands surrounding context handles the rest. Both are better than sending raw text directly to the model.

Text normalization and custom pronunciation dictionaries work together. Normalization handles structural patterns — numbers, abbreviations, symbols. Pronunciation dictionaries handle vocabulary exceptions — brand names, proper nouns, domain-specific terms. Neither replaces the other; both run before synthesis to prevent errors rather than catch them after.

See the TTS quality validation checklist for a full breakdown of the five dimensions of production-grade TTS output quality, of which pronunciation accuracy is the first and most commonly cited.

Why regeneration roulette fails at scale

The most common current practice for pronunciation errors is regeneration roulette: send the synthesis request again and hope the model produces a clean take on the next run.

One verbatim buyer quote from G2 research captures the attitude accurately: "It still trips up on acronyms, brand names, and random proper nouns, so I'll do a couple of takes to get it clean. Not a dealbreaker, just part of the workflow."

That acceptance is reasonable at small scale. At production scale, the arithmetic changes completely.

A 2% mispronunciation rate sounds low. Across 10,000 clips, it produces 200 unshippable files. Each requires a human to identify the failure, route it for review, trigger a regeneration, validate the new output, and return it to the delivery pipeline. At a conservative 10 minutes per clip, that is 33 hours of unplanned remediation per batch — plus the pipeline latency of holding 200 clips out of delivery until each is resolved.

The failure compounds when the same brand name appears across a catalog. One mispronounced product name can propagate through hundreds of clips before anyone catches it. Without a pre-synthesis check that flags the term before synthesis runs, the error spreads through the entire batch.

For teams evaluating which TTS engine to use, the best TTS models benchmark guide covers model-level quality across providers. Model selection is the first step — but pronunciation accuracy on your specific vocabulary is a production layer question, not a benchmark question. The benchmark tests general naturalness. Your product names are not in the benchmark.

For a view of how specific providers handle pronunciation customization at the API level, see the ElevenLabs vs Cartesia comparison.

How do I fix TTS pronunciation errors at scale?

The production-grade fix has three components that work in sequence.

1. Shared pronunciation dictionary. Maintain one dictionary that covers your brand vocabulary, product names, and domain-specific terms. Apply it as a pre-synthesis step before any request reaches the TTS API. When a new product name launches, add one entry — not one entry per provider.

2. Text normalization pipeline. Run all text through a normalization layer before synthesis. Handle numbers, dates, units, abbreviations, and acronyms systematically. Do not leave expansion decisions to the TTS model.

3. Per-output quality scoring. After synthesis, score each output for pronunciation accuracy against a reference profile. Flag outputs that fall below threshold before they enter your delivery pipeline. This backstop catches edge cases that slip through the normalization and dictionary layers — novel spellings, context-dependent ambiguities, and terms added to copy after the dictionary was last updated.

Onepin runs all three steps automatically for any TTS provider in your stack. Teams do not build or maintain the pronunciation dictionary, the normalization rules, or the quality scoring logic — those run as part of the production layer above the model. See how the full pipeline works at onepin.ai/docs.

Regeneration roulette is not a production strategy. It is a manual patch that scales linearly with volume. At 10,000 clips per month, the patch cost exceeds the cost of building the right production layer above your TTS model.