Advertisement
UI & Interface Sounds

How to Regenerate Voice Blips Without Breaking Character Consistency

Regenerating a voice blip is not the same operation as rendering it the first time. This guide classifies which parameter changes stay inside the perceptual threshold and which cross it, gives the cent, decibel, and millisecond ranges that matter, and shows how to verify a batch re-render against golden samples before it reaches the build.

Regenerating a voice blip is not the same operation as rendering it the first time. The first render has no reference: whatever comes out is the character, and the designer adjusts until it sounds right. A regeneration has a reference. The existing renders are the character, and the job is to change some inputs without crossing the line where the output stops reading as the same person.

That distinction changes the failure mode. A first render that sounds wrong is a design problem — the parameters need to be adjusted. A regeneration that sounds wrong is a change-management problem: something moved that was not supposed to move, and the fix is not to re-tune the character but to identify which input crossed a threshold and pull it back. The rest of this article is about classifying those inputs and verifying the batch before it reaches the build.

Start by Classifying the Change, Not the Sound

Before regenerating anything, write down what is actually changing. The categories below behave very differently, and conflating them is the most common reason a re-render breaks consistency.

  • Output format change. Sample rate, bit depth, or container. The parameters are identical; only the encoding moves.
  • Renderer change. A different build of the same synthesizer, or a different synthesizer reading the same parameters.
  • Template change. A parameter inside the template has been edited — pitch center, formant pair, envelope, contour slope.
  • Seed or line-identity change. The character-level seed has moved, or line IDs have been reassigned.

The first category is usually safe, the second is conditionally safe, the third is where most consistency failures live, and the fourth is almost always a rebuild of the character rather than a regeneration of it. If you cannot place a planned change into exactly one of these four boxes, the change is not ready to run.

The Perceptual Thresholds That Decide Whether a Change Is Invisible

A change is safe when it stays below the listener's ability to detect it, or when it is large enough that it reads as a deliberate state change rather than a drift. The dangerous zone is the space between those two — changes large enough to be noticed but not large enough to be interpreted as intentional.

The approximate thresholds, stated as ranges rather than single numbers because they depend on context, duration, and listener training:

  • Fundamental frequency (F0): the just-noticeable difference for sustained vowels is typically reported in the range of roughly 10–20 cents, depending on reference pitch and the comparison task. A change of 1–2 cents is below that floor and reads as the same voice; a change of 100 cents (one semitone) reads as a different but related voice; a change beyond about 1.5–2 semitones reads as a different character.
  • Formant frequencies (F1/F2): the JND is larger than for F0 and harder to state as a single number, because it depends on which formant and which vowel. A working rule is that a formant shift of a few percent is detectable in careful comparison and a shift of roughly 10% or more changes the vowel color enough to read as a different speaker.
  • Per-syllable duration: speech-rate changes below roughly 5–10% are usually not noticed in a short blip; larger changes shift the character's perceived energy or calm.
  • Amplitude: a level change under roughly 1 dB is generally inaudible in a blind comparison; 3 dB is noticed as "louder" or "quieter" but does not change identity.
  • Onset jitter: changes of a few milliseconds to the per-syllable onset timing are usually unnoticeable in isolation but become audible as a rhythm change when a line is compared side by side with its previous render.

These ranges are not a specification. They are a starting point for deciding which changes need a verification step and which can be trusted. A format change at the same sample rate is below every one of these thresholds by definition; a template edit that moves the pitch center by two semitones crosses all of them at once.

Golden Samples: The Only Reliable Check

The problem with "listen and see if it still sounds right" is that memory for short sounds decays within seconds, and the designer who made the change knows what changed, which makes the comparison biased. The fix is a small set of golden samples and a blind A/B test.

A golden sample set is three to five rendered lines per character, chosen to cover the range of the character's speech: a short line, a long line, a line with wide pitch contour, a line with narrow contour, and at least one line in a non-idle state. These renders are stored alongside the manifest and are never overwritten; they are the reference against which every future regeneration is judged.

The test is simple. Render the new version of each golden sample. Put the old and new versions in a random order behind labels A and B. Ask someone who was not involved in the change to answer one question per pair: same character, or different character? Not "better or worse" — that question invites aesthetic judgement. Same or different is the only question that matters for consistency.

If the listener says "same character" on every pair, the change is within the threshold and the full batch can run. If the listener says "different character" on any pair, the change has crossed the line and the batch should not run until the cause is identified. If the listener hesitates — "it's the same person but something is off" — the change is in the dangerous zone, and the batch should be narrowed to the smallest change that produces the intended effect. The guide to randomized blip variations covers why the dangerous zone is often caused by the seed rather than the template, and how to check for that first.

Three Operations That Break Consistency More Often Than Anything Else

Re-seeding the character. If the renderer generates its per-syllable jitter from a global random state rather than the character-level seed stored in the template, every regeneration produces a new jitter pattern. The character's pitch center and formant pair can be identical and the result will still read as a different person, because the micro-rhythm that gave the character their particular "speech" has changed. The fix is structural: the seed must be read from the template, not generated at render time. The template system guide explains why the seed belongs at the character level rather than the line level, and the same reasoning applies here.

Upgrading the renderer without diffing the output. A renderer upgrade that fixes a bug will change the output for every template that triggered the bug. Sometimes the change is a tiny DC offset that nobody hears; sometimes it is a change to the attack envelope that shifts the character's perceived hardness. The upgrade itself is not the problem — the problem is running it across the whole cast without checking which lines moved and by how much. The asset version control guide covers the manifest hash comparison that makes this check possible, and the renderer version field that makes it traceable after the fact.

"Small" template edits made while other work is in progress. A designer opens a template to fix one line, notices the formant Q value looks slightly off, adjusts it, and re-renders. On a single line the change is inaudible. Across ten lines of dialogue it reads as the character becoming thinner or more nasal — not a different person, but not the same person either. The dangerous zone is precisely where small edits accumulate into a perceptual shift that nobody can point to a single cause for. The formant modulation guide is relevant here for the specific parameter relationships that are easy to disturb without noticing.

A Regeneration Workflow That Holds Up

The workflow below assumes the template and manifest already exist in the form described in the template system and asset version control guides. If they do not, this workflow cannot run — there is nothing to compare against.

  1. Write down the change. One sentence: "Moving sample rate from 44.1 kHz to 48 kHz" or "Bumping renderer from 1.4.2 to 1.4.3" or "Adjusting F2 from 1400 to 1500 Hz on template tpl_authority_soft/v3". If the change cannot be stated in one sentence, it is more than one change and should be split.
  2. Classify it against the four categories and the thresholds above. A format change at the same sample rate can run without a golden-sample test. A renderer upgrade needs one. A template edit needs one, and the magnitude of the edit determines whether a passing result is even plausible.
  3. Render only the golden samples first. Not the whole batch. Three to five lines per character is enough to catch the failure before it costs hours of render time and a build rollback.
  4. Run the blind A/B test. Same character or different character, per pair. Record the answers before looking at the manifest diff — otherwise the diff biases the listening.
  5. If the test passes, render the batch and update the manifest. If it fails, do not adjust the template to compensate. Identify which input crossed the threshold and revert that input. Compensating changes stack on top of each other and produce a character that drifts across several regenerations in a way that nobody can reconstruct.
  6. Commit the template version, the renderer version, and the new hashes together. A regeneration that is not recorded in version control is a regeneration that will be repeated by someone else in six months, with a different renderer, and a different result.

When the Right Answer Is to Treat It as a Recast

Sometimes a regeneration cannot preserve consistency because the intended change is a change of character. A villain who is revealed to be a different person, a protagonist who is transformed, a side character whose voice is deliberately replaced as a story beat — these are not consistency failures, they are deliberate breaks, and the workflow above does not apply to them.

The signal that a regeneration belongs in this category is that the writer or designer wants the player to notice the change. If they do, the regeneration should be marked in the manifest as a deliberate recast, with a note of what changed and why, so that a later consistency audit does not flag it as a bug. The pitch envelope guide is useful here for designing the specific audible change that marks the recast, and the sample rate and format guide is worth checking before the recast is rendered, because a format change and a recast happening in the same pass makes the two effects impossible to separate if the result needs to be adjusted later.

Regeneration is safe when three conditions hold: the change is smaller than the perceptual threshold or large enough to read as deliberate, the result has been verified against a golden sample by someone who did not make the change, and the change is recorded in version control alongside the renderer and template versions. If any of the three is missing, the batch is a guess — and a batch of voice blips rendered as a guess is exactly the failure this workflow exists to prevent.

Advertisement