The usual advice for repetitive sound effects is “add a little random pitch and volume.” That advice is not wrong, but it hides a failure mode that becomes obvious after a few hundred triggers: the sound stops being repetitive and starts being unstable. The event no longer reads as a consistent thing that happened; it reads as a series of slightly different things, and the player’s ear, which was supposed to be fooled into hearing variation, instead notices that the sound is never quite the same.
Controlled randomness is not a smaller amount of randomness. It is randomness applied to the parameters that can vary without changing identity, with a magnitude below the listener’s discrimination threshold for identity, and with a correlation structure that preserves the event’s internal relationships. The three constraints are independent, and failing any one of them produces a different audible problem.
Randomization Has a Ceiling, and It Is Lower Than Most Designers Assume
The perceptual thresholds for pitch, amplitude, and timing are the hard limit on how much variation can be applied before the sound reads as a different event. The numbers matter because they set the boundary between “variation” and “inconsistency.”
| Parameter | Approximate JND (barely detectable) | Practical randomization ceiling for short SFX |
|---|---|---|
| Pitch (complex tones) | ~9 cents for complex tones; 10–20 cents for pure tones; as low as 2–3 cents for expert listeners under ideal conditions | ±10–30 cents (±0.1–0.3 semitones) before the variation becomes audible as inconsistency |
| Amplitude | ~0.25 dB under optimal conditions; ~3 dB for speech-level perception | ±1–2 dB |
| Timing (onset) | A few milliseconds in controlled conditions; larger in gameplay | ±5–15 ms |
The pitch row is the one that causes the most trouble, because the threshold is not a single number. For complex tones — which is what most game sound effects are, since they contain multiple partials — the discrimination threshold is around 9 cents regardless of pitch . For pure tones it is wider, roughly 10–20 cents, and can be as low as 2–3 cents for trained listeners in ideal conditions . But in a dynamic game context, where the sound is competing with other audio and the player is not listening analytically, pitch variation smaller than roughly 2.5 semitones may go unnoticed , which is a much wider band than the laboratory JND. The practical ceiling is therefore not the JND itself but the point at which the variation becomes noticeable as variation rather than absorbed as natural difference. For a short impact, ±10–30 cents is usually enough to break exact repetition without making the sound feel detuned.
The 2.5-semitone figure is worth pausing on, because it points at the actual failure mode. A sound randomized by ±2 semitones will not be heard as a different pitch on each trigger — it will be heard as the same pitch with an occasional wrong one. That is worse than exact repetition. The randomization has crossed from “variation” into “error” without passing through “different but plausible.”
Uncorrelated Jitter Is Not the Same as Structured Variation
The second constraint is correlation. Applying independent random offsets to every parameter on every trigger produces a sound whose internal relationships change. A footstep that gets slightly louder, slightly higher, and slightly later on each step is not three variations of the same footstep; it is a footstep whose weight, pitch, and timing are no longer telling the same story.
A real footstep on a real surface has correlated variation. A heavier step is slightly lower in pitch and slightly longer in duration, because the same physical event causes all three. An uncorrelated randomizer that independently jitters pitch and duration can produce a step that is higher and longer, which no physical surface produces. The ear may not consciously identify the impossibility, but it registers the sound as less natural than exact repetition.
The practical fix is to randomize a small number of latent parameters and derive the audible parameters from them, rather than randomizing each audible parameter independently. A single “energy” or “weight” value can drive pitch, duration, and brightness together in the same direction, preserving the physical plausibility of the variation. The guide to creating a sound variation system to avoid repetition covers the architecture for this; the specific point here is that independence is not a virtue when the parameters are supposed to co-vary.
The same logic applies to layered sounds. If an impact has a low thump and a high crack, randomizing their relative timing by different amounts changes the perceived attack. A small shared offset applied to both layers is heard as a timing variation; independent offsets are heard as a smeared attack, which reads as a different — and usually worse — impact. The layering guide covers how layers should be separated in frequency; the correlation rule is the time-domain counterpart.
Why Playback-Rate Randomization Is the Wrong Tool for Most Short SFX
The most common implementation of pitch randomization in game engines is to vary playback rate. This is convenient because it requires no pitch-shifting algorithm, but it conflates pitch and duration in a way that is usually undesirable for a short sound effect.
In the Web Audio API, playbackRate changes the
rate at which samples are read, which affects both pitch and
speed . A
playbackRate of 1.06 raises the pitch by one
semitone and shortens the sound by about 6%. For a footstep,
that combination may be acceptable. For a weapon impact whose
perceived weight depends on the duration of the low-frequency
body, a 6% shortening is audible as a lighter hit, not just a
higher one.
The alternative is the detune parameter, which
specifies the pitch offset in cents and — in engines that
support it as a separate control — changes pitch without
changing duration . When
detune is available, it is the correct tool for
pitch variation because it preserves the temporal identity of
the sound. When it is not available, the practical workaround
is to keep the playbackRate variation small
enough that the duration change is below the JND for that
sound, or to accept that the variation is a combined
pitch-and-duration shift rather than a pure pitch shift.
There is a further problem with aggressive playback-rate randomization that shows up in generated or synthesized material. A study of real-time parameter randomization in a generative audio system found that increasing playrate randomization to its maximum introduced a spread of roughly 0.01x to 1.99x, and that this produced an “other-worldly” quality that detuned melodic patterns . That is fine for an intentionally alien sound and disastrous for a sound that is supposed to read as a physical event. The lesson is not that playrate randomization is always wrong; it is that the parameter’s range has to be chosen against the sound’s identity, not against a generic “more variation is better” intuition.
The Engine-Independent Rules for Controlled Randomness
The rules below hold whether the randomization is implemented in Wwise, FMOD, a Web Audio API game, or a custom synth. They are stated as constraints rather than recipes because the specific numbers depend on the sound.
Rule 1: Randomize one latent parameter, derive the rest. Choose a single value per trigger — call it “weight” or “energy” — and derive pitch, duration, and brightness from it with fixed ratios. This preserves correlation and prevents impossible combinations.
Rule 2: Set the range by the identity threshold, not by the JND. The JND tells you when a change is detectable in isolation. The identity threshold tells you when a change makes the sound read as a different event. The second threshold is what matters for a game sound that fires repeatedly. For a short impact, that is usually ±10–30 cents of pitch, ±1–2 dB of gain, and ±5–15 ms of onset.
Rule 3: Do not randomize the parameter that carries the event’s meaning. A coin sound’s identity may be in its two-note interval; randomizing that interval changes the event. A hit’s identity may be in its attack transient; smearing the transient with timing variation changes the hit. The randomization belongs on the parameters that are decorative relative to the event’s core. The randomized blip variation guide covers the same principle for UI sounds, where the tolerance is even tighter.
Rule 4: Avoid the “repeat the previous one” failure in selection, not just in synthesis. A random container that can pick the same variation twice in a row produces audible repetition even when every parameter is varied, because the two triggers are the same file. Wwise’s Random Container addresses this with a “previous” exclusion mode that removes the last played object from the selection pool . The equivalent in a custom system is a short history buffer that excludes the most recent N selections, where N is small enough to not exhaust the pool.
Rule 5: Test at the repetition rate the game will actually produce. A randomization scheme that sounds varied at one trigger per second may sound mechanical at ten per second, because the ear compares adjacent events more closely at higher rates. A footstep system should be tested at sprint speed, not walking speed. The footstep surface guide covers the surface-specific variation that interacts with this rate effect.
What “Controlled” Actually Means in Practice
Controlled randomness is not a smaller random number. It is a random number whose range is set by the sound’s identity threshold, whose distribution is shaped by the sound’s internal correlations, and whose selection logic avoids exact repeats. The three parts are separable, and each can be tested independently.
A sound with controlled randomness should pass three checks. First, a listener should not be able to predict the next trigger from the previous one. Second, a listener should not be able to identify which trigger is the “odd one out” when the full set is played back to back. Third, removing the randomization entirely should make the sound feel more mechanical, not less — if exact repetition sounds acceptable, the variation was never doing any work.
The guide to iterating sound effect prompts is relevant for the synthesis side of this: changing one parameter at a time is the only way to tell whether a perceived problem is caused by the base sound or by the randomization applied on top of it. If the base sound is unstable, no amount of randomization tuning will make it stable, and the fix belongs upstream.