Complete newbie here - where do I start with voice selection?

You've nailed a key issue with using tone as a blunt instrument. That "authoritative but not angry" baseline is really hard to find.

One trap I've seen, especially in compliance modules, is that slowing down to 0.9x for gravity can sometimes introduce a hesitant or uncertain quality, which is the opposite of what you want. It's not just about avoiding monotone, it's about retaining confidence at a lower speed.

Testing the same critical line in two different contexts, like user1286 suggested, is a great next step from your point. Can the voice deliver the warning with appropriate weight, then smoothly return to a neutral explanatory tone without sounding like two different narrators stitched together? If it can't, that dissonance will break listener trust.

That confidence-at-lower-speed trap is real, but I think the "two different narrators" problem you both mentioned is often baked into the voice model itself. The real test isn't just if it can pivot, but if it *remembers* its tone after the pivot. A lot of voices will nail the serious warning, then bounce back to a cheerful default that completely undercuts the gravity of what was just said. It's like a psychological whiplash for the listener.

The hesitation at 0.9x? Sometimes that's actually the better tell. If slowing it down makes it sound unsure, you've found a voice that's all performance, no substance. It was never authoritative, it was just talking fast.

You've hit on a subtle but critical detail: tonal memory. A voice that doesn't carry the emotional context forward for a sentence or two breaks immersion completely. It's like the model has amnesia.

That "performance vs. substance" distinction is so apt. I'd add that you can sometimes spot this early by testing with a three-sentence structure: a neutral setup, a serious core statement, then a neutral consequence. If the consequence sounds like it's delivered with a smile, you know the voice lacks that underlying depth.

The whiplash effect is real, and it erodes credibility faster than almost anything else in a training module.

That three-sentence test is a great practical filter. It catches the 'amnesia' issue immediately.

I'd just add that sometimes the *script* is the problem, not the voice. If you're writing the consequence clause with overly casual language right after a serious warning, you're asking the voice model to do an unnatural emotional jump. The whiplash might be in the text itself.

So if a voice flunks that test, try rewriting the follow-up sentence to be more tonally neutral before you scrap the voice entirely. Sometimes it's a dialogue between the script and the voice, not a one-way test.

Yes! Script and voice have to be in sync for that test to work. Good call.

I've been burned by this exact thing. Picked a great serious voice, but my script went from "Failure to comply will result in suspension" to "So let's head to the next module!" The cheerful transition was in the text, and the voice just read it faithfully.

Now I always write the whole test paragraph in the target tone first. If the voice still can't hold it, then I know it's the model, not my writing.

You're right to isolate the variable like that. I've seen projects waste days testing voices with inconsistent scripts.

One nuance: even a tonally consistent test script can't always predict how a voice will handle *user-generated* content down the line. If your workflow involves taking script drafts from multiple authors, you might get that cheerful transition sentence inserted later regardless. A truly robust voice should moderate those shifts somewhat.

I now run two tests: one with my perfectly tuned script, and another where I deliberately introduce a jarringly casual sentence at the end. The difference in how the voice handles the second test tells me more about its real-world buffer against imperfect scripts.

Start with the most neutral sentence you can write. Avoid anything with emotional words.

Then do the jargon test. Something like, "The quarterly results showed a significant year-over-year increase in EBITDA." Listen for stumbles on the acronym.

Forget about trying them all. Pick five that sound vaguely professional from their preview. Test those two sentences. Eliminate anyone who sounds even slightly hesitant or unnatural on the technical term. You'll cut 80% of the options in ten minutes.

The one left is your baseline. Compare others to it, not to perfection.

Trying them all will burn you out. The "same sentence" approach is actually a solid starting point for a controlled test. Use a script line that's exactly the kind of thing you'll narrate, ideally with a piece of technical language in it.

Where I'd deviate is just listening for clarity. For training videos, you need to evaluate consistency. Generate a short paragraph, not just a sentence. Listen to see if the voice maintains the same professional, instructional tone throughout, or if it starts to waver or sound bored halfway through. A voice that can't hold a steady, clear tone for 30 seconds will be grating in a ten-minute module.

The "not too robotic" feel often comes from subtle pitch variation. Listen for a slight, natural rise and fall in longer sentences. A completely flat line, even if the pronunciation is perfect, will sound synthetic.

Agreed on the paragraph being the minimum viable test unit. A single sentence often fails to reveal prosody issues, especially on longer, clause-heavy technical statements.

Your point about pitch variation is correct, but it's quantifiable. I've logged spectrograms for several voices, and the "flat line" you mention often correlates with a standard deviation in fundamental frequency (F0) of less than 15 Hz across a declarative sentence. That's a good, objective filter to add after the subjective listen.

One caveat: some voices achieve consistency by adopting a slight "rhythmic" pattern, repeating the same pitch contour on every sentence. It sounds less robotic at first, but becomes monotonous over a full module. So the test paragraph must include at least three different sentence structures to catch this.

Forget the advanced tonal memory tests for now. They're putting the cart before the horse.

Your script is more important than the voice. Write 30 seconds of your actual training material first. Something dry with an acronym or two. Then try maybe three voices on it. You'll hear which one stumbles.

Everyone's overcomplicating this. A voice that can't read a basic technical sentence clearly isn't worth your time, no matter how well it 'pivots'. Clarity first, personality second. Most of them are just reading the words you give them anyway.

Listen for two things: clarity on technical jargon and consistency over 30 seconds. Generate a short paragraph from your actual training material that includes an acronym and a complex sentence. Run that through maybe four voices.

You'll hear which ones stumble on the acronym. The ones that don't are your candidates. Then listen for tone drift in the paragraph. The voice should sound the same at the end as at the start. If it gets bored or starts a sing-song pattern, drop it. That's your baseline filter before you worry about tonal memory or emotional range.

You've set up a good filter, but you're assuming the voices render the test script identically each time. I've found that's rarely the case, especially with cloud-based services under load.

Run your 30-second paragraph test at least three times per voice and listen to the variation. Sometimes a voice nails the acronym on generation one, then completely mangles it on generation two. That inconsistency is a deal-breaker for production, and you won't catch it with a single pass.

Consistency between renders is as important as consistency within a single paragraph.

Right on about the in-browser players, that's a huge hidden variable. I've even had the same voice sound thinner on my laptop speakers versus my desktop setup because one browser applied a "loudness normalization" flag by default.

Your WAV download advice is key, but some platforms don't even offer that until you're on a paid tier. They *want* you judging through their processed web player. It's a feature wall disguised as a convenience.

You're both talking about the wrong metric. That "two narrators" effect and the speed drop-off aren't just performance issues, they're symptoms of poor prosody modeling in the underlying architecture.

When a voice can't remember its tone after a pivot, it means the model isn't maintaining a coherent latent state across the sequence. It's reverting to a mean embedding. The 0.9x speed test just exposes the lack of a proper duration model - it's stretching phonemes without adjusting pitch contours, which sounds unnatural.

You're diagnosing the problem correctly, but you're calling it a voice issue. It's a model training issue.