Audio noise gate — silence anything below the threshold, kill background hum between words

The recordings that need noise gating have real-world contexts attached

Noise gating happens on specific kinds of audio: podcast episodes recorded in a room with an HVAC system, gaming streams where keyboard clatter bleeds into the mic, meeting recordings full of typing noise, vocal tracks where breath sounds need smoothing, interview audio with ambient background hum. In each case, the speech content — the actual words spoken — is the recording’s entire value.

A noise gate removes quiet sounds but does nothing to suppress the speech. The file going into the process contains everything. Uploading it to a cloud service for gating delivers the conversation along with the noise. The goal was to remove the hum; the outcome includes transferring the speech to a third-party server.

Cloud processing of voice recordings — what the transfer implies

Free audio processing services often sustain themselves by deriving value from uploaded content. Terms of service in this space routinely permit broad usage rights. Each parameter adjustment that triggers a re-render sends the file again. The interactive feel of tweaking a noise gate — rapid iterations, immediate playback — makes repeated uploads feel like a UI operation rather than multiple data transfers.

Voice is biometric-adjacent data. Regardless of what’s being said, the fact that a voice recording exists on a server means the speaker’s voice is there too. As voice fingerprinting and voice synthesis technology has improved, unnecessary external transfers of voice recordings carry more downstream risk than they did a few years ago.

Sample-level gate logic runs inside the Web Audio API

The tool decodes audio via decodeAudioData, then applies a per-sample gate: compute windowed RMS, compare against threshold, transition the gate state (open/closed) with attack and release ramps, apply gain reduction of reduction dB when closed. The result is written as 16-bit PCM WAV. A reduction value of -20 dB produces a soft gate that leaves residual room tone; -100 dB silences fully.

No sample data leaves the browser. Open DevTools Network and run a re-render by changing a parameter: no audio requests appear. The gate state-machine logic is in the GitHub source.

Setting the threshold and combining with other tools

The most useful measurement to take before setting a threshold is the noise floor level. audio-loudness-lufs can show you the integrated LUFS of a quiet section; set the gate threshold 3–6 dB above that number. Too low and you’ll clip the speech; too high and background noise leaks through in the pauses. If silence sits only at the head and tail of the recording, audio-trim-silence handles that case more cleanly than gating.

The classic broadcast chain is gate → compressor. Run the noise gate first in this tool (removes the floor), then run the WAV through audio-compressor (evens out volume variation). Check the result with audio-loudness-lufs and audio-true-peak before final export — all of this runs in the browser without any uploads.

Envelope tracking and the role of threshold, attack, hold, release

Inside the gate is an envelope follower tracking the input level, plus a state machine that compares the envelope to the threshold and switches gain between 1.0 (open) and the configured reduction (closed). This tool estimates level per sample using |sample| or a short RMS window (~5 ms), and smooths gain changes with exponential coefficients exp(-1 / (sampleRate · attackTime)). attack (0–100 ms) sets how quickly the gate opens to reach the target gain, release (10–500 ms) sets how quickly it closes. hold (0–500 ms) is a dwell time before the gate is allowed to close after the signal drops below threshold — without it, brief silences inside speech (between consonants, mid-breath) cause the gate to chatter open-and-closed, producing audible artefacts.

A reduction of -100 dB is full silence; -20 dB is a “soft gate” that leaves residual ambience so the cuts don’t feel abrupt. Cinematic dialogue mixing often prefers -15 to -20 dB to preserve a thin layer of room tone — total silence between lines feels artificial. Envelope detection is usually either RMS (closer to perceived loudness for sustained sounds) or Peak (faster response to transients); this tool’s absolute-value detection behaves like a peak-style follower, which handles sharp transients (keyboard clicks of 1–2 ms) appropriately.

Use-case patterns and where sidechain falls outside scope

For podcast and narration, a sensible starting point is threshold = -45 to -35 dB / attack = 5–10 ms / hold = 100–200 ms / release = 150–300 ms / reduction = -20 dB — preserves natural speech dynamics while cutting HVAC, fan, and keyboard noise by about 20 dB. Game-streaming mic chains lean faster: threshold = -50 dB / attack = 2 ms / release = 80 ms cuts mechanical keyboard clatter almost the moment it appears. Vocal recording wants very short attacks (1–3 ms) so the consonants s, t, k aren’t dulled.

Order in the chain matters. Gate → compressor is right because compressing first lifts the noise floor before the gate ever sees it, hurting SNR. Sidechain (ducking) — using one signal to gate another — is theoretically possible with this kind of architecture, but this tool runs the gate self-keyed (no external key input), so true sidechain compression / ducking is out of scope. Pitfalls: (a) a threshold set below the noise floor doesn’t gate anything, (b) a threshold set too aggressively cuts soft consonants and the trailing decay of words, (c) too-short release time makes gate transitions audible, (d) gating L and R independently on stereo material can desync the channels and hurt mono compatibility — this tool processes L and R in lockstep. A typical pre-export pass is audio-loudness-lufs for loudness and audio-true-peak for peaks.