Choose a repair that your tool supports
You can finish the basic repair in your speech editor without code: save the original sentence, change one name in a synthesis copy, generate both versions and listen against the intended pronunciation. If you do not read IPA, start with an alias. Move to a dictionary when you need to reuse the result, or to phonemes when spelling changes cannot express the required sounds.
Start with the smallest correction that addresses the audible error. A wrong vowel, missing syllable, misplaced stress and unwanted language switch need different checks. Changing the voice, spelling and speaking speed together makes it difficult to identify what helped.
| Your situation | First method to try | What to check |
|---|---|---|
| The editor accepts only ordinary text | A spoken-form alias in a separate synthesis copy | The name improves without adding pauses or changing the visible spelling. |
| The same name appears throughout a project | A pronunciation dictionary attached to that project | The correct entry and dictionary version apply to every intended occurrence. |
| You know the target sounds and the tool supports them | A phoneme rule or the model's documented IPA input | The alphabet, stress marks, locale and input route are supported. |
| The name works alone but fails in a sentence | The existing rule tested in several sentence positions | Neighboring words, punctuation and sentence delivery remain acceptable. |
| No available voice produces an acceptable result | An approved spoken recording or another voice with a new comparison | The final edit preserves timbre, timing and the rest of the sentence. |
Support belongs to a particular model and interface. In the documentation checked on October 1, 2026, ElevenLabs' Studio help page lists Flash v2 and Turbo v2 for phoneme rules, while its API dictionary guide lists v4, v3 and Flash v2 for dictionary phonemes. The general speech guide also describes native inline IPA for v4. These are different input routes; copying a tag into any text box is not a reliable compatibility check. Use an alias when your route does not support the required phoneme control, and verify the resulting audio.
Establish what the name should sound like
For a person's name, ask for a short recording of the name alone and in a sentence, including any acceptable variants. For a public figure, use a reliable recording of their own introduction when available. For a character, place or brand, use the project's agreed reference. A pronunciation generated by another AI system is a candidate to review, not independent confirmation.
Record the written name, target language or dialect, syllable count, stress and the part that your current output gets wrong. A useful note is specific enough to guide the next change: an extra syllable, an incorrect final consonant, or stress falling on the first syllable instead of the second. Preserve the reference source so a collaborator can make the same comparison.
Keep two copies of the script: the master with the correct written name, and the input sent to the speech engine. This prevents a successful sound substitution from creating a misspelled caption later.
Method 1: use a spoken-form alias
An alias tells the system to read an alternative string while you keep the proper spelling in your master script. This is the simplest route when your editor has no pronunciation controls. Duplicate the script into a synthesis copy and change only the problem name there.
Master script and captions:
Niamh Kelly will introduce the next speaker.
Synthesis candidate:
Neeve Kelly will introduce the next speaker.
Render both sentences with identical settings. Compare the changed word against the reference, then listen to the surname and the transition into the next word. If the output still misses the target, revise the candidate or move to a supported phoneme rule.
Work on one observed error at a time. If the syllable count is wrong, try a candidate that the selected voice reads with the intended number of syllables. If a hyphen creates an unwanted break, compare a version without it. Capital letters and punctuation are model-dependent experiments, so retain the exact input that produced the accepted result rather than assuming a universal spelling convention.
Do not replace every matching string across unrelated scripts. A word may also be an ordinary word, or the same spelling may belong to people with different pronunciations. Scope the replacement to the intended name and project. After synthesis, use the master script to check subtitles and titles so a temporary string such as Neeve does not appear in the finished video.
Method 2: save a project pronunciation dictionary
A dictionary is useful when a name appears repeatedly or several editors need the same rule. It maps the written form, called a grapheme, to an alias or phoneme sequence. In ElevenLabs Studio's Pronunciations editor, select the word, open the editor, enter a rule, preview its output, and save it to a dictionary connected to the project. If no word is selected, enter it in the input field.
The repair is not complete when the dictionary saves. Regenerate an affected sentence, listen to it and verify that the intended project uses the intended dictionary. Test a capitalized occurrence and any other written form you actually use.
If your tool imports PLS dictionaries, save this editable example as a UTF-8 .pls file. It maps the written name to the same alias:
<?xml version="1.0" encoding="UTF-8"?>
<lexicon version="1.0"
xmlns="http://www.w3.org/2005/01/pronunciation-lexicon"
alphabet="ipa" xml:lang="en-US">
<lexeme>
<grapheme>Niamh</grapheme>
<alias>Neeve</alias>
</lexeme>
</lexicon>
For API use, creating a dictionary and applying it are separate operations. The ElevenLabs API guide supplies the create-from-file call and a synthesis request containing pronunciation_dictionary_locators. Retain both the dictionary ID and version ID used by the request. A file uploaded to your account but absent from the synthesis request cannot establish that the rule was applied.
Keep the dictionary small enough to inspect. Add separate entries for written variants where necessary, remove conflicting rules, and retain the version alongside the accepted audio. If the desired pronunciation changes, update the rule and regenerate the relevant sentences before replacing the previous version.
Method 3: use phonemes or supported IPA input
Phonemes describe the sounds more explicitly than an ordinary spelling. Use this route when you have a reliable transcription and your synthesis system supports the required alphabet. Check the voice's language and the exact syntax first. A text editor that accepts an XML string may still treat it as literal text.
In Azure Speech's documented SSML format, a phoneme element contains the written word and specifies its sounds in ph. The following complete request illustrates a candidate corresponding to the fixture alias; replace it with your approved target.
<speak version="1.0"
xmlns="http://www.w3.org/2001/10/synthesis"
xml:lang="en-US">
<voice name="en-US-AvaNeural">
<s><phoneme alphabet="ipa" ph="niːv">Niamh</phoneme>
Kelly will introduce the next speaker.</s>
</voice>
</speak>
Submit this through an SSML input route. Azure's pronunciation documentation covers supported alphabets, locale-specific phones and stress notation. Unrecognized phones can produce an invalid-SSML error. Use the documented syllable and stress syntax for the chosen alphabet rather than copying marks from an unrelated service.
Eleven v4 has a different input route. Its speech guide documents IPA between forward slashes in the text, with model_id="eleven_v4". Using the same candidate sounds as the Azure example, the synthesis text is:
/niːv/ Kelly will introduce the next speaker.
Keep Niamh in the master script. The slashes belong to the synthesis input. Do not put this string into a different model and assume it has the same meaning. For the documented Flash v2 XML route, use a phoneme element instead. First and last names need separate elements in that route. An emotion or accent instruction does not specify the sounds of a name.
Other services also implement subsets of SSML. Check the provider's supported tags: the Google Cloud guide describes its supported elements, and Amazon Polly's phoneme guide defines its phonetic input. A valid SSML document is not a guarantee that every voice or engine supports every feature.
Build an A/B comparison that answers your question
Use the actual sentence containing the troublesome name. Keep a baseline with the original input and a candidate with one changed mechanism. Record the voice, model, language, speaking rate, delivery settings, dictionary version, text and export format. Leave music, compression and other finishing effects out of the first comparison.
- Save the unchanged sentence and generate version A.
- Change one alias or pronunciation rule and generate version B with the same settings.
- Compare the name with the reference. Write the error you hear instead of recording only a general preference.
- Listen to the complete sentence, including neighboring words and pauses.
- Retest the selected rule in other occurrences from the project.
Keep playback loudness reasonably comparable; a louder file can distract from a pronunciation error. If you audition anonymized files, use neutral names and keep the condition key away from the listener until their notes are saved. The labeled examples on this page are for learning the workflow, not a blinded listening study.
Some synthesis systems can vary delivery between renders. When differences extend beyond the name, retain another baseline and candidate render before attributing the change to the rule. Keep the extra renders so you can compare delivery as well as the name.
Use separate decisions for pronunciation and sentence quality. A candidate can match the target sounds but introduce an unnatural pause. It can also sound fluent while still getting the name wrong. If neither version meets both requirements, continue revising; an A/B test does not require declaring a winner.
Work through a name repair from input to decision
The downloadable audio contains one roll-call sentence before and after four alias substitutions. We generated it with the macOS Samantha voice at 155 words per minute and converted both files to mono, 24 kHz, 16-bit PCM WAV. The input, settings and files are available, so you can reproduce the comparison.
Focus on Niamh Kelly to see how a decision should be recorded. The baseline contains Niamh Kelly; the changed input contains Neeve Kelly. The table below separates what the files establish from what still needs a listener:
| Step | This example | Action in your project |
|---|---|---|
| Set the target | No recording from the named person is supplied. | Obtain the name alone and in a full introduction; record the accepted variant. |
| Identify the error | It would be misleading to label the baseline wrong without that target. | Write what differs: syllable count, vowel, final consonant or stress. A fluent sentence can still fail this check. |
| Change the input | Niamh becomes Neeve; the voice and rate stay fixed. | Generate the single-name A/B sentence shown in Method 1. Keep Kelly and the surrounding words unchanged. |
| Review the sentence | The two files below are available for listening; their different lengths are not a quality score. | Compare the name, the join into Kelly and the pause before the next phrase with the reference. |
| Make the decision | Hold for a target reference. The available evidence supports a reproducible comparison, not an accepted name pronunciation. | Accept B only if the name matches and the sentence remains natural. Otherwise record the remaining error and revise that part. |
If your single-name version passes, test We will hear from Niamh Kelly next. and Niamh Kelly, please begin. using the same alias. Save the accepted rule with its voice and settings only after these occurrences pass. If Neeve adds a break or gives the wrong vowel, keep the written script and try the supported /niːv/ candidate above, adjusting it to the actual reference. This is the point where the listener's notes determine the next input.
| Written form | Candidate in the synthesis copy | What you need before using it |
|---|---|---|
| Siobhan | Shuh-vawn | The project's reference and a check of stress and both syllables. |
| Saoirse | Seer-sha | A reference specifying the intended variant. |
| Niamh | Neeve | A check of the vowel and final consonant against the intended speaker. |
| Xochitl | So-cheel | A language-appropriate reference; the approximate English alias is not authoritative. |
The other substitutions in the same sentence are listed for inspection. They are approximate English inputs; a person's preferred variant takes precedence. Listen to the two conditions below:
Original spelling, sample 214:
Alias input, sample 907:
Optional: reproduce the audio files on a Mac
Start with the complete pronunciation repair kit; it includes both WAV files, settings, editable examples and a review sheet. You can listen and fill in the sheet on any computer. The commands below are only for rebuilding the demonstration. They require Python 3, the macOS say command, Samantha and FFmpeg in your terminal. Run:
python3 regenerate-pronunciation-pair.py --out rebuilt
python3 pronunciation-audio-integrity-check.py \
--key rebuilt/pronunciation-test-key.json \
--audio-dir rebuilt
The regeneration script reads the original key, writes both exact input texts, invokes say with the same voice and rate, and converts each result with FFmpeg. It writes a new key with the resulting hashes and durations. Voice assets and software versions can change, so use that new key for regenerated audio; use the original key only for the retained files. Recordings with different hashes are not automatically failed pronunciations.
For an ordinary voiceover, use your speech editor to generate the pair instead. Record its actual voice and model; the Mac recipe does not reproduce a commercial voice. The separate downloads at the end of the page are useful if you need only a WAV file, the settings or the optional checker.
Diagnose syllables, consonants and stress separately
When the name has too many or too few syllables, compare it slowly with the reference and mark where the extra or missing sound occurs. Test the name alone and in its original sentence. If it is wrong in both, revise the alias or phoneme sequence. If it fails only in context, keep the target sounds and investigate the sentence boundary.
For a wrong consonant or vowel, write down the position of the error. Changing the entire sentence's speed is a poor first experiment when one sound is wrong. Keep the rate fixed, change the candidate at that position and compare again. An alias that works in one voice is a result for that voice; it does not establish a reusable phonetic spelling for every engine.
For misplaced stress, identify the intended stressed syllable from the reference. A transcription needs both the sounds and their stress. ElevenLabs documents this Flash v2 CMU Arpabet example for Madison:
<phoneme alphabet="cmu-arpabet" ph="M AE1 D IH0 S AH0 N">Madison</phoneme>
The 1 marks primary stress on the first vowel; 0 marks the unstressed vowels. In IPA, ˈ precedes the syllable with primary stress and ˌ marks secondary stress. Use the alphabet your route supports. The provider example illustrates stress syntax; it does not define the pronunciation of everyone called Madison.
If you cannot transcribe the sounds, ask the reference speaker for a slow version as well as a normal introduction. Test an ordinary-text alias that preserves the syllables you hear. Capitals or hyphens can change emphasis and pauses unpredictably, so compare them in the full sentence before saving the rule.
If the target itself is uncertain, stop selecting candidates by fluency alone. Ask for clarification about the acceptable pronunciation or variant. Preserve a pending result until the reference is available; a technically valid pair can be prepared before there is enough information to approve it.
Handle multilingual names and mixed-language scripts
Decide whether the project needs the person's preferred pronunciation in their language or an explicitly accepted pronunciation within the narration language. Those targets can differ. Retain the intended version instead of inferring it from spelling, ethnicity or the audience's location.
Check whether the voice and model support the required language before revising individual letters. An English approximation can be a candidate for English narration, but it should not be presented as the native pronunciation of a Chinese, Irish or Nahuatl name. The Xochitl fixture alias above illustrates this limitation.
For a Chinese name, preserve the characters as well as any romanized form in your reference record. Ask for the full spoken name, including tones, surname and given-name boundaries. Feeding romanization to an English voice is a separate synthesis experiment, not confirmation that it will reproduce Mandarin sounds. Where supported, test the original characters in an appropriate voice or a language-controlled segment.
Chinese surnames can have readings that differ from the same character as an ordinary word. Azure documents 仇先生 with say-as interpret-as="name": the surname is read qiú rather than chóu. Here is a complete SSML example using a multilingual voice and an explicit Mandarin segment:
<speak version="1.0"
xmlns="http://www.w3.org/2001/10/synthesis" xml:lang="en-US">
<voice name="en-US-AvaMultilingualNeural">
<lang xml:lang="zh-CN">
<say-as interpret-as="name">仇先生</say-as>,请开始。
</lang>
</voice>
</speak>
For an English introduction containing that Chinese form, keep the English words outside the Mandarin segment:
<speak version="1.0"
xmlns="http://www.w3.org/2001/10/synthesis" xml:lang="en-US">
<voice name="en-US-AvaMultilingualNeural">
Our next speaker is
<lang xml:lang="zh-CN"><say-as interpret-as="name">仇先生</say-as></lang>.
Please welcome him.
</voice>
</speak>
Azure's language-control documentation lists this voice as supporting Mandarin and English. The lang element requires a supported multilingual voice; a non-multilingual voice does not support it. These examples combine documented features and still require an audio test. The surname example is a specific documented reading, so obtain a reference for another person's characters instead of extending the rule to every Chinese name.
For a mixed-language sentence, compare the name and the words immediately around it. If a language switch changes the rest of the sentence's accent or delivery, test a supported language boundary or a separately generated phrase with enough surrounding context for editing. Then review the joined audio. Changing the voice or replacing the segment creates a new candidate to assess, even if the isolated name sounds acceptable.
Keep full names, initials and brand names consistent
Test first and last names separately before combining them. If only the surname is wrong, leave the first name untouched. Then test the complete name, because an acceptable isolated word does not establish the rhythm of the full introduction.
Inspect the actual written variants in your script: a straight or curly apostrophe, a hyphenated surname, a possessive ending, all capitals or a shortened form. Add and test rules for the forms that occur instead of assuming one entry covers them. Search the final script after the repair to catch occurrences that still use the uncorrected synthesis input.
For initials and brand abbreviations, first decide whether the project wants individual letters, an ordinary word or an expanded phrase. In a supported Azure SSML route, <say-as interpret-as="characters">ABC</say-as> requests individual letters. To speak an expanded form while keeping its abbreviation in the source, Azure documents:
<sub alias="World Wide Web Consortium">W3C</sub>
Place that element inside the voice element of an SSML request. In a plain-text editor, put World Wide Web Consortium in the synthesis copy instead. Use the expanded form only when that is the project's intended reading; a caption containing W3C does not by itself establish whether the narration should expand it.
A project dictionary should not silently impose one person's pronunciation on everyone with the same spelling. Keep separate project rules where needed, and test aliases that also match ordinary words. Review every affected occurrence before applying the dictionary to a long narration.
When the rule saves but the voice still reads it wrong
| What you observe | Next check | Action |
|---|---|---|
| The output is unchanged | Rule attached to the actual project or request; supported model and input route | Confirm dictionary and version IDs, then generate a new affected sentence. |
| Only some occurrences change | Case, punctuation and written variants | Compare the exact grapheme with each occurrence and test separate entries where required. |
| The tool reads the markup aloud | Plain-text versus SSML or native IPA input | Use the documented input route, or return to an alias. |
| An old pronunciation returns | Old export, old dictionary version or provider caching | Regenerate with the intended version and inspect the new file, not a previous download. |
| The name is right but the sentence is awkward | Alias punctuation, pauses and the neighboring phrase | Test a less disruptive candidate or regenerate the complete sentence. |
| One render works and another fails | Delivery variation and whether settings changed | Retain additional comparable renders and test the rule in the project's other sentences. |
Check provider-specific caching instead of repeatedly editing the alias. Azure's custom lexicon documentation says a lexicon is cached by URI and changes at the same URI may take up to 15 minutes to refresh. That applies to its externally referenced custom lexicon, not every pronunciation editor. Keep a versioned record of the file and request so you can distinguish a stale rule from an ineffective one.
Use the checker for file problems, and listening for pronunciation
The kit includes the two original WAV files, their key and the audio-integrity checker. Run the checker on the retained files with:
python3 pronunciation-audio-integrity-check.py \
--key pronunciation-test-key.json \
--audio-dir .
A passing result means that hashes and durations match the key, the files have the declared PCM format, their signal exceeds the fixture's RMS threshold, no samples meet its clipping threshold, the PCM payloads differ, and reversing the declared alias map reconstructs the baseline text. It does not transcribe the audio or confirm that the speech engine followed the text. Sample-peak checks also do not detect every kind of audible distortion.
The supplied files and a locally regenerated pair passed the checker. Use the review sheet to record the target reference and listening decision separately.
Automatic transcription can help flag an omitted word elsewhere in the sentence, but correct spelling in a transcript does not establish the intended pronunciation. Compare the audio itself with the reference. If you also need to check the final dub's names and meaning, follow the separate video translation and dubbing workflow.
Apply the accepted pronunciation to the finished voiceover
Save the accepted audio with the target reference, exact synthesis text or dictionary rule, voice, model, locale, rate, dictionary version and reviewer notes. Have the named person or a qualified speaker resolve any uncertainty about the intended pronunciation.
Before rendering the long script, test actual occurrences with the name at the start of a sentence, in the middle, before punctuation and alongside the next speaker's name. Listen to each complete sentence. Keep the previous accepted audio until the new outputs have been reviewed.
If you replace only a phrase in an editor, include enough surrounding speech to judge the join. Check for a cut consonant, a doubled syllable, mismatched room sound and a noticeable change of tone. Review timing when the longer pronunciation shifts a subtitle or a video cue. Regenerating the complete sentence is another candidate to compare when a small splice is conspicuous.
Listen once more after speed changes, compression and background music. Then check the visible script and captions against the proper written name. If the voice, model, rule or delivery changes later, make a new comparison and record the new result before reusing it.
