A one-shot and a loop are not the same sound played under different engine settings. They are different objects, and the difference is structural: a one-shot has a beginning and an end that the player is supposed to hear, while a loop has a beginning and an end that the player is never supposed to notice. A sound that is excellent as a one-shot can be a bad loop for reasons that have nothing to do with its timbre, and a sound built as a loop can be a weak one-shot because its attack was shaped for a seam it will never cross.
The practical consequence is that the playback mode needs to be decided before synthesis, not after. If you make the sound first and then decide how it will play, you will usually end up with a one-shot that clicks when looped or a loop that feels unfinished when triggered once. The sections below work through the differences in the order they affect the sound: how it starts, how it ends, what has to be true of the file, and what the engine will do with it once the file is in the project.
The Attack Question: Does the Sound Need to Announce Itself?
A one-shot is an event. It happens at a moment, and the player needs to register that moment. That is why one-shots tend to have a pronounced attack: a sharp transient, a clear onset, a level that rises quickly enough to be heard as “now.” A UI click, a weapon hit, and a footstep are all judged first on whether their attack reads as the moment of input.
A loop is a state. It starts when a condition becomes true — the player enters a cave, a machine turns on, the wind picks up — and it continues until the condition changes. The onset matters less than the fact that the sound is present. A looping wind bed with a hard transient at the start will announce itself every time the player enters the area, which may be correct for a sudden gust and wrong for a continuous breeze. The attack-time guide for ambient sounds covers the ranges that separate “presence” from “event” in more detail; the point here is that the loop’s attack is a design choice about whether the state should be announced at all.
The exception is the loop that is triggered on a state change the player should notice — a machine sputtering to life, a portal opening. Those loops often have a short one-shot introduction followed by a seamless loop body. The introduction carries the announcement; the loop carries the state. That structure is different from a plain loop and needs to be built as two segments, not one.
The Release Question: Is the Tail Allowed to End, or Does It Have to Be Interrupted?
This is the difference that most often gets discovered late. A one-shot’s release is part of the sound: the tail decays, and the player hears it finish. An explosion that ends cleanly at 2.5 seconds is finished; the player does not expect it to continue. A loop’s release cannot be allowed to finish, because the loop is supposed to continue until the engine stops it.
That changes what a good release is. A one-shot benefits from a release that resolves — a natural decay, a fade to silence, an ending that feels like an ending. A loop needs a release that can be interrupted without a click. If the loop is stopped mid-cycle, the engine has to apply a short fade to avoid a discontinuity, and the longer the sound’s natural release, the more of that fade becomes audible as an artificial cut. The SFX duration guide covers the tail lengths that are expected per category; the loop-specific point is that a loop’s tail has to be designed for interruption, not for resolution.
A workable pattern for a loop’s body is a short release — a few tens of milliseconds — followed by the loop point. When the engine stops the loop, it can fade over that short release without cutting into the sustain. A one-shot with the same short release would feel abrupt, because the player hears the cut. The same envelope shape is correct in one mode and wrong in the other.
The Seam: What Has to Be True of the File Itself
A one-shot does not have a seam. It has a start and an end, and the space between them is the whole sound. A loop has a seam by definition: the point where the end connects back to the beginning. Everything about how a loop is authored is downstream of that seam.
The two standard techniques for making the seam inaudible are zero-crossing cuts and loop-point crossfades. A zero-crossing cut places the loop start and loop end at points where the waveform crosses the zero line, so the amplitude at the seam is zero on both sides and the transition produces no discontinuity. A loop-point crossfade overlaps the end of the loop with the beginning, fading one out while the other fades in, so the seam is masked by the overlap rather than eliminated at the sample level. Both are standard practice, and both are documented in engine tooling — Audiokinetic’s documentation recommends positioning loop points at zero crossings to avoid clicks and pops and defines a separate crossfade duration for cases where the zero-crossing approach is not sufficient.
The choice between them is not arbitrary. A zero-crossing cut works when the material is quasi-periodic or when the seam can be placed in a low-energy region; it preserves the exact waveform and produces no change in timbre. A crossfade works when the material is dense or noisy and a clean zero crossing cannot be found; it introduces a short overlap, which changes the sound slightly at the seam but hides the transition. A loop built with a crossfade will sound different in its first and last few hundred milliseconds than in the middle, and that difference is the cost of the seam being hidden. The ambient background sound effects guide covers the loop-length and layer-density considerations that interact with this choice.
The one-shot equivalent of this decision does not exist. A one-shot can be trimmed anywhere; its start and end are chosen for the event, not for a seam. That freedom is why a one-shot can be edited after the fact without breaking it, while a loop edited after the fact may develop a click that was not there before.
The Metadata Problem: Loop Points Are Not Always in the File
A one-shot is self-describing: it plays, it ends. A loop carries information that is not always audible from the audio data alone — the loop start point, the loop end point, whether the loop is infinite or counted, and whether the file is meant to be looped at all. That information lives in metadata, and where it lives changes how the file behaves when it moves between tools.
In FMOD, if a file contains a loop region, FMOD 4 and FMOD 5
will detect it and automatically enable
FMOD_LOOP_NORMAL unless the code explicitly passes
FMOD_LOOP_OFF when creating the sound
. That means a loop can become a loop without the
designer choosing it, simply because the file carried the
metadata. In Wwise, looping is set at the object level — the
Loop option on a Sound or Container, with the choice of
infinite repetition or a specific number of loops
— which means the same WAV can be a one-shot in one event and
a loop in another, depending on how the object is configured.
The practical consequence is that loop metadata is not portable in the way audio data is. A file exported with loop points from a DAW may be interpreted as a loop by one engine and as a one-shot by another, or by the same engine after an import setting is changed. The safe practice is to treat the loop points as part of the asset specification and to verify them in the engine that will actually play the sound, not only in the editor that created them. The export decision framework covers the channel-count and format side of the same portability problem; loop metadata is a separate field that travels with the file and needs the same verification.
The Engine’s Behaviour Is Different, and That Changes the Design
The two modes are not just different ways of reading the same file. They occupy different slots in the engine, and those slots have different rules.
A one-shot typically spawns a new voice each time it is triggered, which means the same sound can overlap with itself . That overlap is often desirable — footsteps and gunshots should overlap — but it also means a fast-firing one-shot can consume many voices at once. A loop, by contrast, is usually a single persistent voice that continues until stopped . Looping a sound that is currently implemented as a retriggered one-shot can significantly reduce voice count, which matters most on mobile or on scenes with many simultaneous emitters.
The table below summarizes the design differences that follow from the engine behaviour. It is not a rule set; it is the set of decisions that change when the playback mode changes.
| Design dimension | One-shot | Loop |
|---|---|---|
| Attack | Sharp, announces the event | May be soft; the state, not the moment, matters |
| Release | Resolves; the end is heard | Interruptible; the end is hidden |
| Seam | None | Must be inaudible, via zero crossing or crossfade |
| Voice behaviour | New voice per trigger; can overlap with itself | Usually one persistent voice until stopped |
| State following | Hard to change once started | Can follow a parameter continuously; one-shots are not suitable for parameter changes |
| Editing after the fact | Trim anywhere; the start and end are not constrained | Edits near the seam can reintroduce a click |
The row on state following is the one that is easiest to overlook. A loop can respond to a parameter continuously — the pitch of an engine loop can rise with speed, the density of a wind loop can follow a weather value — because the sound is already playing and its parameters can be modulated. A one-shot is a fixed event: once it has been triggered, it is difficult to change its parameters without retriggering it, and retriggering consumes another voice. If the design calls for a sound that follows a changing state, the loop is the mode that supports it, and the one-shot is the mode that does not.
When the Answer Is Not the Obvious One
The default assumption is that environmental sounds loop and event sounds one-shot. That assumption is usually right, and it is still worth knowing the cases where it is wrong.
Looping a one-shot is sometimes correct for held actions. A door creak that should continue while the player holds the interaction button is not a one-shot with a long tail; it is a loop that starts on hold and stops on release. The creak’s seam has to be hidden, which means the sound has to be authored as a loop even though it reads as a one-shot event. The alternative — retriggering the one-shot while the button is held — may produce a stutter and consume voices.
One-shotting a loop is sometimes correct for count-limited states. A machine that runs for exactly three seconds and then stops is not a loop in the design sense; it is a one-shot with a longer duration. If the sound is authored as a loop and the engine is configured to play a fixed number of loops, the result is the same audio, but the authoring constraints are different: the seam still has to be hidden, because the sound may loop before it stops. The decision is not “loop or one-shot” but “how many repetitions, and does the seam need to hold.”
The playback mode can change during the sound’s life. A sound can start as a one-shot introduction and transition into a loop body, and the engine configuration has to support that transition without a gap. This is the introduction-plus-loop structure mentioned earlier, and it is the case where the file is neither purely one-shot nor purely loop; it is two segments with a defined boundary. The sound variation system guide covers how to keep the loop body from becoming recognisable across repetitions, which matters more for a long-lived state than for a short event.
A Decision Order That Settles the Mode Before the Sound Exists
The order below is arranged so that the decision is made before the file is authored, which is the only point where it can be made cheaply.
- Ask whether the sound represents a moment or a state. If the player needs to know that something happened at a specific time, it is a one-shot. If the player needs to know that a condition is currently true, it is a loop. If both are true, it is an introduction plus a loop body.
- Ask whether the sound can be interrupted. A sound that can be stopped by the game at any moment needs an interruptible release and an engine configuration that fades rather than cuts. A sound that always finishes is a one-shot, even if it is long.
- Ask whether the sound needs to follow a changing parameter. If it does, it is a loop, because a one-shot cannot be modulated without retriggering. If it does not, either mode can work and the decision falls to the previous questions.
- Author for the seam before authoring for the character. For a loop, find the loop points and verify them in the target engine before spending time on timbre. A loop whose seam clicks is not a finished sound, regardless of how good the body sounds.
- Verify the metadata in the engine, not only in the editor. Export the file with the loop points and confirm that the engine reads them as intended. If the engine auto-detects loops, confirm that the intended one-shots are not being silently looped.
The 80/20 guide applies to this decision as much as to any other: a sound that is authored in the wrong mode will consume more time than a sound that is authored in the right mode, because the correction is not a tweak but a rebuild. Settling the mode first is the cheap version of the decision.