A Pronunciation Exception Registry Is More Useful Than Another TTS Retry
Summary: Thomas ZX discusses the limitations of text-to-speech (TTS) systems, emphasizing the need for a Pronunciation Exception Registry to ensure consistent pronunciation of terms like product names and acronyms across different instances. The proposed solution involves defining failure classes for pronunciation issues, creating a scope for corrections, and maintaining a versioned registry to track and review exceptions. A decision matrix helps evaluate audio output independently of the rendering system, aiming for consistency and traceability in TTS outputs. Regular reviews of the registry data are essential to manage changes and ensure reliability.
A Pronunciation Exception Registry Is More Useful Than Another TTS RetrySynthetic speech often passes a quick review because the sentences sound fluent. The failure appears later, when a product name, acronym, person, or place is pronounced inconsistently across a batch. One clip may stress the second syllable, another may spell the term letter by letter, and a third may sound acceptable only because the surrounding sentence hides the mistake. Repeating generation until one version sounds right does not create a dependable release process. It creates an unrecorded exception that the next script will rediscover.
The engineering problem is therefore not simply voice quality. It is traceability. A team needs to know which terms are risky, which transformation was applied, what evidence justified the change, and when a previously accepted correction must be reviewed again. That requirement is especially important when several people prepare scripts or when the same phrase appears across multiple languages and channels.
Define the failure before choosing a correction
A useful registry starts with observable failure classes. Avoid entries such as “sounds wrong,” because they cannot guide a later reviewer. Record whether the issue is stress placement, acronym expansion, language switching, vowel substitution, unwanted pauses, or ambiguity caused by punctuation. The classification should describe what a listener can verify without knowing which rendering system produced the clip.
The registry also needs a scope. A correction that works in one language, voice, or sentence may fail in another. Treat language, voice profile, and surrounding phrase as part of the test input rather than assuming a spelling hint is universal. This keeps a narrow workaround from becoming an undocumented global rule.
Store decisions as a small versioned contract
A plain YAML file is sufficient for a small team and can travel with the scripts in version control. The important part is the contract, not the storage product.
```yaml
schema_version: 1
terms:
- canonical: "Example Product"
language: "en-US"
failure_class: "stress-placement"
input_variant: "Ex-am-ple Product"
context_phrase: "Introducing Example Product for teams"
expected_observation: "stress remains on the first syllable"
status: "candidate"
reviewed_at: null
reviewer_role: "language-owner"
expires_when:
- "voice-profile changes"
- "renderer changes"
- "script language changes"
```
The `canonical` field preserves the text that should appear in the final script or transcript. `input_variant` records the controlled transformation sent to a renderer. Keeping both prevents a phonetic workaround from leaking into captions, subtitles, or customer-facing copy. `expected_observation` gives the reviewer a specific listening target. The `expires_when` list turns model or voice changes into explicit retest events instead of silent assumptions.
Do not mark a new entry as accepted immediately. A `candidate` state makes the uncertainty visible. Promotion to `approved` should require a listener who understands the target language and has heard the correction in the relevant context phrase. If that evidence is unavailable, the honest state is `needs-review`, not “probably fixed.”
Make the evaluation matrix independent of the renderer
The same decision matrix should apply whether audio is generated by a hosted service, a local model, or a studio tool. This makes the process portable and keeps vendor selection separate from release judgment.
| Check | Accept | Reject | Next action |
|---|---|---|---|
| Canonical term | recognisable without script | listener needs the script to infer it | revise transformation |
| Stress and rhythm | stable in two surrounding phrases | changes with nearby punctuation | add context-specific entry |
| Language boundary | target language remains consistent | term triggers unintended language switch | isolate or rewrite phrase |
| Batch consistency | all sampled clips use the same form | variants disagree | block batch and compare inputs |
| Transcript parity | display text remains canonical | phonetic spelling leaks into captions | separate render input from display text |
This matrix avoids a common false positive: accepting a clip because the reviewer knows what it was supposed to say. A pronunciation should be understandable to a listener who sees no internal prompt. The matrix also catches a different class of defect, where the audio is acceptable but the phonetic input accidentally appears in subtitles or metadata.
Put rollback gates around the batch, not just the sample
A successful sample is not proof that every generated asset is safe. The release gate should inspect a small but deliberate set: the first occurrence, the longest sentence containing the term, a sentence with punctuation near the term, and at least one clip from every target language or voice profile. The goal is not exhaustive listening. It is coverage of the conditions most likely to invalidate the exception.
A practical state machine can remain simple:
`candidate`: a correction exists but has not passed contextual review.
`approved`: the correction passed the defined matrix for a named scope.
`blocked`: at least one rejection condition remains.
`expired`: a renderer, voice, language, or script context changed.
Only `approved` entries may pass the release gate. `blocked` entries require rewriting, a different voice path, or a human recording. `expired` entries return to evaluation; they must not inherit approval from an older configuration. If a deadline arrives while an important term is still blocked, rollback means using the last accepted asset or removing the uncertain segment, not lowering the evidence threshold.
Keep the product as a replaceable rendering component
A registry and its release rules should outlive any one tool. The renderer receives a controlled input variant and returns an audio candidate; the team-owned contract decides whether that candidate can ship. According to its current product page, Qwen Audio 3.0 TTS provides a browser-based text-to-speech workflow and can be evaluated as one possible renderer in this stage. The registry should record the selected renderer and voice as scope metadata, but neither should define the acceptance rule.
That separation also makes comparison cleaner. Two renderers can receive the same context phrase and transformation, while reviewers apply the same matrix. A change is adopted because it satisfies the contract, not because a product name appears in the workflow.
Review the registry as operational data
Exception registries decay. Names change, campaigns add languages, and rendering behavior may shift after a configuration change. Schedule a lightweight review that looks for duplicate terms with conflicting corrections, entries without a reviewer, approvals missing a scope, and records whose expiration condition has already occurred. The review can be automated as a schema check, but listening evidence remains a human responsibility.
The useful outcome is not a larger list of phonetic spellings. It is a smaller, auditable set of decisions: what failed, what changed, what passed, and what must trigger another review. Once those decisions are explicit, pronunciation defects stop being surprising retries and become ordinary release conditions that a team can test, block, and roll back.
Qwen Audio 3.0 TTS official website homepage showing the product interface and primary workflow
.png?_a=BAVMn6DY0){kind=small}