Make a Pronunciation-Checked Scratch Voiceover From Text

The line is twenty seconds long, and one word in it comes out wrong. A synthetic voice is reading approved copy into your animatic, and it says the product name like it has never met you. The reflex is to retype the script until the voice complies — spelling the name phonetically right there in the sentence. Now the audio sounds right and the approved copy is wrong, and nobody notices until the approved copy is somewhere that matters.

There is a less fragile route. Keep the approved wording exactly as approved. Put the speaking instructions somewhere else, next to it rather than inside it. Use a voice and a route your team is allowed to use for this material. Then listen to the result against the words you meant before you drop it into the animatic, because a request that looks correct is not a pronunciation check.

That is the whole method. The rest of this piece is about the parts that go wrong: which instruction fixes which problem, what to do when the route ignores you, and how to keep the audio tied to the inputs that produced it.

Two documents, not one

A scratch voiceover for an animatic is usually doing two jobs at once. It lets people hear whether the copy is understandable at speed, and it lets them hear how long the copy actually takes. Both jobs need the words to be the approved words. Neither job needs performance quality, and neither job survives a silent edit to the script.

So keep two things side by side:

The written master. The approved copy, frozen. This is the source of truth. If it changes, it changes through approval, not through a synthesis tool.

The synthesis source. A derived, disposable, heavily annotated version that exists only to make a temporary reading. It can be messy. It can contain markup, respellings, settings notes — anything needed to get the intended reading out of a stock voice.

Between them, keep a reading brief: a short list of the written values whose spoken form is genuinely ambiguous, with the intended reading written down before you touch a synthesizer. Names, abbreviations, numbers, anything borrowed from another language. This list is what you will check the audio against, and it is the thing you cannot reconstruct afterward from memory.

The distinction that keeps this honest: an expansion a person would make out loud is a reading; an expansion a person would have to approve is a copy change. Reading "RC" as the letters R and C is a reading. Reading "12 weeks" as "three months" is a rewrite wearing a pronunciation costume. The first belongs in the synthesis source. The second belongs in a review.

Two shortcuts are worth naming because they are so convenient. The first is sending copy you are not cleared to send to whichever service is fastest. Whether a service is authorized depends on the material and on whatever agreements cover it — that is a decision for whoever owns the copy, and no amount of careful markup repairs it. The second is imitating a performer's voice to get a nicer scratch. That is not a faster version of this workflow; it is a different, riskier one, and it is out of scope here for good reason.

Pick the control that answers the problem

A voice reading your copy can go wrong in three different ways, and they need three different kinds of instruction. Microsoft's documentation on speech synthesis markup separates them, and the distinction is worth carrying over even if you end up on another provider.

Interpreting a written value. The text stays exactly as written; you tell the engine what kind of thing it is, so it knows how to say it. This is the right tool for an abbreviation you want read as letters and for a number you want read as a quantity. The Microsoft Learn pronunciation page, which was checked on September 18, 2026, describes this as content-type interpretation; it also notes that which interpretations are available depends on the chosen language and route.

Supplying a spoken alias. The written form stays on the page; the listener hears an alternative wording instead. This is useful for a name the voice keeps mangling and for which no pronunciation instruction is available.

Annotating a pronunciation directly. The written word stays, and you specify the sounds. This is the most precise of the three, and the most fragile: supported phonetic alphabets vary by language and by voice family, and a phonetic string you half-remember from another project is worse than no instruction at all. Don't paste one. Source it or leave it out.

A pause is a fourth thing. The structure page's break element controls a pause, by strength or by a duration — a separate task from specifying pronunciation, and one you should treat as its own identified problem rather than as punctuation cleanup. The documentation is clear that these are different jobs.

The rule that ties all four together: use the narrowest control that answers a problem you have actually identified. A control that changes nothing for your voice is not neutral — it is one more thing that can silently disagree with the audio, and one more thing a reviewer has to read past.

Support is the trap. The documentation notes that supported elements depend on the voice, and that phonemes and interpretations depend on language and route, so a source that is perfectly valid against one voice may produce nothing at all against another. That is why the next step is not "write the markup." The next step is a short passage, generated and listened to.

Work through one line

Suppose the approved copy for a twenty-second animatic is this, frozen and not to be touched:

Navilo RC arrives in 12 weeks. Existing accounts keep their terms.

And suppose the reading brief has been agreed like this. Navilo is said "nah-VEE-loh" — three syllables, stress on the middle one, and not "NYE-lo." RC is the letters R and C, not "release candidate." 12 is the word twelve, a quantity of weeks, not a product number. And the animatic needs a beat after the first sentence, longer than the period will give, because the logo reveal lands there.

Nothing so far requires a synthesizer. This is the fictional exercise, laid out as fixed facts so the rest of the steps have something to be right or wrong about.

Now make two sources.

The plain source is just the approved copy pasted into the text field, with nothing added but the voice and locale. Generate it first. Some of your four rows may already be correct — whether a given voice reads two capitals as letters or as a word, and whether a number comes out as a word by default, is not something you can assume in either direction. The plain source is how you find out, and it costs you one short generation to learn which instructions are actually load-bearing.

The revised source adds only what the plain source showed you it needed. Its shape follows the element names above, with the specific attribute values taken from your selected voice's own documentation rather than from memory or from another provider's examples:

<speak version="1.0" xml:lang="[your locale]">
  <voice name="[your selected stock voice]">
    <sub alias="[agreed spoken form]">Navilo</sub>
    [interpretation markup for RC] arrives in
    [interpretation markup for 12] weeks.
    [pause element, per your route's supported syntax]
    Existing accounts keep their terms.
  </voice>
</speak>

Two cautions about that sketch. It is a shape, not a runnable file: the bracketed parts are exactly where your route's supported syntax goes, and whether your route supports the elements at all is a question you answer by generating and listening. And if you reach for a spoken alias for the name, remember that an alias is a spelling, and spellings are unreliable pronunciation instructions. A respelling like "nah-VEE-loh" may land exactly right or produce something new to fix. A direct pronunciation annotation avoids that guesswork, when your language and voice support one.

Then fill in what you heard, per row:

• What the plain source actually said.
• What the revised source actually said.
• Whether that matches the agreed reading.
• Whether to keep the instruction or cut it.

The last column matters more than it looks. The revision that survives this comparison is the shortest one that produces the right reading. Cutting a control that turned out to change nothing is progress, not thrift.

One thing this exercise cannot do for you: generate the audio. No speech was synthesized for this piece and none was heard, so the comparison columns above are yours to fill. The example is a procedure, not a report.

Listen before you trust the file

Valid markup is not proof that the generated speech says the intended words. Neither is a successful export, a green checkmark, or a route that accepted every element you sent. A control your route does not support may be rejected loudly or dropped quietly, and the only instrument that tells you which is your ears.

So listen in this order. First, the smallest passage that exposes the uncertain reading — the name in its actual sentence, not the name alone, because surrounding words change how a voice handles it. Only when that passage sounds right do you generate the full reading.

Then listen against the brief, not against your hope. Did the name land on the syllable you agreed? Did the abbreviation come out as letters? Did the number come out as a word? Did the pause land where the animatic needs it, or somewhere a period would have put it anyway? Note where the voice stumbled, where two words ran together, where a beat you did not ask for appeared.

Then write down what produced that audio, while you still remember: the voice, the locale, the revision of the approved copy it was built from, the controls you used, the controls the route rejected or ignored, the date, and who listened. That record is what makes the audio reviewable rather than merely present. It is also what makes the next revision possible, because "the one that sounded right" is not a reproducible setting.

Keep the reviewed audio tied to its inputs

Store the master, the reading brief, the synthesis source, the voice and locale settings, and the checked audio together, as one revision. When either the wording or the intended pronunciation changes, make a new identified revision rather than overwriting the old one — an audio file whose inputs have changed is no longer the file anyone checked.

When the new revision is approved, replace the asset in the animatic's slot. Do not leave an unlabeled near-duplicate sitting beside it; that is how a cut ends up carrying the reading everyone agreed to abandon.

Label the file and its metadata plainly: temporary synthetic narration, the voice and locale, the revision, the date it was checked, and the person who checked it. The label does real work. It stops the track from being mistaken for a licensed performance, and it stops the file from being handed to a performer as a target.

On that last point, be deliberate. The timing of a synthetic scratch is evidence about this sketch and this copy. It is not a standard a future performer has to match, and it is not a direction. When the job moves to an audition, the brief carries the intent; the scratch track carries only a sketch of the length.

What the good revision looks like

The end state is small and unglamorous: a temporary reading whose words match the approved copy, whose ambiguous names and numbers sound the way the brief says they should, and whose file can be traced back to a specific source revision, voice and locale. Change one input and the whole chain gets a new number.

Getting there is usually not a matter of writing more markup. It is a matter of generating something short, listening to it honestly, and removing the instructions that turned out not to do anything — or admitting that the route cannot do what you need and choosing a different authorized voice before the animatic review, not during it.

The correction that matters is rarely the elegant one. It is the one where you hear the wrong word, go back to the source, and find that the instruction you trusted had been sitting there doing nothing at all. That discovery is the point of the exercise. It is much cheaper to make it in a scratch file than in a room full of people watching the cut for the first time.

Frequently asked questions

What is the core method for a pronunciation-checked scratch voiceover?

Keep the approved wording exactly as approved and put speaking instructions beside it rather than inside it. Use a voice and route your team is allowed to use for the material, then listen to the result against the intended words before dropping it into the animatic. Valid markup or a successful export is not a pronunciation check.

What are the written master, synthesis source, and reading brief for?

The written master is the approved copy, frozen and used as the source of truth. The synthesis source is a derived, disposable, annotated version that exists only to get a temporary reading. The reading brief records written values whose spoken form is ambiguous and the intended reading. Reading RC as the letters R and C is a reading; expanding 12 weeks into three months is a rewrite needing approval.

Which controls fix which pronunciation problems?

Interpreting a written value tells the engine what kind of thing the text is. A spoken alias supplies an alternative wording while the written form stays. A pronunciation annotation specifies the sounds directly. A pause control handles a beat. Use the narrowest control that answers a problem you have actually identified. Support varies by language, voice and route, and a control may be rejected or ignored, so generate a short passage and listen.

How should an ambiguous line be worked through?

Generate a plain source first with only the voice and locale to learn the defaults. Then make a revised source that adds only what the plain source showed it needed, using the selected voice's own documentation. Fill in what the plain source actually said, what the revised source actually said, whether it matches the agreed reading, and whether to keep or cut the instruction. A respelled alias is still a spelling and may be unreliable; a direct pronunciation annotation is better when supported.

How should reviewed scratch audio be kept tied to its inputs?

Store the master, reading brief, synthesis source, voice and locale settings, and checked audio together as one revision. When wording or intended pronunciation changes, make a new identified revision rather than overwriting the old one. Replace the asset in the animatic slot and avoid unlabeled near-duplicates. Label the file as temporary synthetic narration with voice, locale, revision, date and checker; scratch timing is not a performance target.

Further reading

• Record the Commercial’s Voice First—or Build It Around the Picture? — Read this before letting a temporary read govern picture timing; it separates a scratch placeholder's timing from a specific approved delivery's authority over the cut.
• Write Commercial Voiceover for the Way It Will Be Spoken — Read this if the copy itself is hard to say at speed, so you can fix the writing's thought units before checking pronunciation in a read.