Audio noise suppression: where recording and call break down
Audio noise suppression almost never starts with the task of “making it sound good.” The trigger is incident analysis: a call recording is sent for quality review, and instead of half the operator’s answers, ventilation is audible.
Hum in a call recording doesn’t interfere with the conversation in the moment—it surfaces later, when a decision has to be made based on that recording.
The second bottleneck of audio processing is the meeting room. Echo from speakers, reverberation from glass and furniture, a microphone that picks up the wrong speaker.
Even a careful filter errs here: it suppresses the echo tail together with quiet word endings, and the meaning of a phrase flips.
Remote employees add their own failure class. Unstable channel, cheap headset, hiss and clicks at the input. Speech dropouts fall exactly on function words and numbers—IDs, figures, deadlines—that is, on what the recording is kept for.
Separately, there is speech loss during cleanup. Aggressive filters cut consonants, breathiness, and short pauses, and along with the noise they carry away intelligibility.
Automatic transcription starts missing keywords, ticket review turns into listening to the recording for the third time, and the share of recordings unusable for QA grows.
We explain how this is addressed: where to place noise suppression in the pipeline, why neural models such as RNNoise and DeepFilterNet behave differently on hum and on clicks, and how to clean audio without losing speech.
Measurable effect: speech intelligibility and measurement sweep
“Improved by ear” is not an acceptance criterion: ears adapt to processing, the argument about the result becomes a matter of taste, and nobody remembers the source recordings after a month.
So we fix the list of metrics and the measurement method before the start: the same tracks are run through the pipeline without cleanup and with it, and for part of the recordings we prepare a reference transcript manually in advance.
The protocol turns “did it get better” into a comparison of numbers—and the work is accepted based on it.
- Recognized word share: how many words from the reference transcript matched the machine one, before and after. The main metric—directly reflects how many fragments will have to be re-listened to or corrected manually.
- Eliminated failure class: counted by noise sources in the customer’s recordings—server room hum, keyboard clicks, meeting room echo, street outside the window. Before work—how many tracks are affected by each class, after—how many remain.
- Speech intelligibility: operator rating on a scale from “can’t make out a word” to “understand without repeats,” on the same fragments and under the same listening conditions.
- Time to listen to a recording: how many minutes it takes to review a one-hour fragment together with the transcript. Usually the effect is visible on the first pass.
- Speech loss: share of speech fragments suppressed together with noise—clipped word beginnings, “swallowed” endings. An increase in cleanliness at the cost of cut speech counts as a defect.
- Robustness across sources: headsets, recorders, meeting recordings. Processing like DeepFilterNet behaves differently on them, and one device cannot represent the fleet.
We summarize the result in a “before/after” table for each metric, indicating the test set. If at least one hasn’t moved—we change suppression parameters and re-measure, rather than reporting implementation.
Audio noise suppression: stream, file, and batch modes
The processing mode is chosen not by model quality, but by where the audio lives: in a live channel, in an individual recording, or in an archive of thousands of hours.
In a stream, the algorithm works on a short window and cannot accumulate context; in a file, it sees the whole track and builds a noise estimate from pauses—hence different requirements for buffering and latency.
| Option | When suitable | Limitations |
|---|---|---|
| Streaming audio processing | Calls, live streams, operator lines, real-time speech recognition | Hard latency budget: short window, aggressive settings produce artifacts on consonants, no second pass |
| Single file processing | Interviews, podcasts, voice-over, dubbing | Processing takes longer than the recording itself, control needed at phrase boundaries |
| Offline archive cleanup | Recording repositories, support calls, training materials | Requires a task queue and reproducible result: quality is assessed on a batch, not one file |
The core—RNNoise and DeepFilterNet: the first maintains real-time mode, the second gives noticeably cleaner sound when processing a recording in full.
Profiles don’t mix silently: the stream goes fast, the archive goes high quality, and both write a report on the share of suppressed noise and sections marked as risky.
Implementation stages: from recording audit to handover
The route starts not with model tuning, but with a recording audit: the character of the noise determines both the algorithm choice and the processing order. Below—stages with checkpoints; after each, the result is visible.
- Recording audit — listen to the material and inspect the spectrum: ventilation hum, street background, room reverberation, mains interference. Stationary and impulse noise require different settings; we don’t combine them into one profile.
- Noise level measurement — record the signal-to-noise ratio on quiet speech, loud speech, and pauses. These values become the acceptance baseline: comparison is by numbers, not by ear.
- Pipeline design — define the processing order: noise suppression, timbre alignment, loudness normalization, limiter. Reordering steps is audible as artifacts, so we agree on the design in advance.
- Reference fragments — cut 10–15 short segments with difficult cases: whispering, shouting over each other, speech over music. We tune profiles on them and make sure consonants don’t disappear.
- Profile tuning — select the model and suppression strength for each recording type: RNNoise for streaming processing, DeepFilterNet for complex background. The goal—remove noise while preserving the naturalness of the voice.
- Processing verification and acceptance — run the entire array, compare against references, check pauses and boundaries. We document the result in a report on noise level and intelligibility for each fragment type.
- Handover — deliver profile configurations, batch processing scripts, the pipeline design, and instructions for the team.
The solution remains workable without us: processing can be repeated on new material with the same settings.
What the customer keeps: schematics, profiles, regulations
Documentation is handed over not as a “folder in the cloud,” but as a working kit by which the operations team can connect a new room and roll back an unsuccessful change. Below is the composition we fix at handover: each item is checked on real recordings, not on a demo stand.
- Pipeline design — order of blocks from source to output, break and bypass points: you can see where audio noise suppression is embedded into recording, call, or stream.
- Processing profiles for rooms — parameter sets for the meeting room, open space, noisy workshop, and street: suppression depth, trigger threshold, headroom so music and announcements aren’t harmed.
- Model configurations in readable form with comments: what a parameter does, what it affects, what range is safe for manual editing.
- Audio cleanup documentation — signal descriptions, quality metrics, and an acceptance checklist: how to confirm noise is gone and speech isn’t “chewed up.”
- Operations regulations — who changes profiles and how, how to revert to the previous one, what to do when microphones are replaced or moving to another room.
- Reference recordings and comparison runs — before and after configuration edits, so changes aren’t accepted by ear.
- Load map — how many channels one node supports and what headroom remains, so expansion doesn’t hit the ceiling.
The kit is updated with every change in the pipeline; otherwise it turns into an archive. We hand it over together with a short analysis for engineers and support the first independent profile edit.
Case: remote call center, metrics before and after
Remote call center operators spoke from apartments—recordings picked up renovation behind the wall, air conditioner, keyboard, and other people’s speech. Speech recognition confused words, and QA re-listened to conversations manually: automatic labeling wasn’t trusted.
They decided not to replace microphones—that’s the longest part of the project. Instead, they put a cascade at workstations: the first pass suppresses stationary background, the second—DeepFilterNet—non-stationary: footsteps, door slams, neighbors’ voices.
Processing happens before recording, so the cleaned signal goes into both the archive and recognition immediately.
Settings were separated by equipment groups: on headsets with a boom mic, hard suppression ate consonants; on cheap ones, conversely, headroom was insufficient. Each group got a fixed profile and was run on reference recordings with known text, to see where the model cuts speech.
Metrics before and after
The share of requests handled without manual listening grew from 62% to 89%. Time for re-listening to a fragment dropped from 40 to 12 seconds, clarification requests halved, and the average conversation became 20 seconds shorter.
QA now looks only at disputed conversations—the rest is closed by automatic labels. During implementation, no operator rejected the new profile: the settings don’t interfere with speaking.
How do neural methods differ from spectral ones?
Spectral subtraction first estimates the noise spectrum from pauses between words and subtracts this estimate from the input signal. The method is deterministic, requires no training, and behaves predictably on stationary noise: ventilation hum, interference, microphone hiss.
Neural cleanup methods solve the inverse problem—the model is trained to map a noisy spectrum to a clean one, so it handles non-stationary interference too: keyboard, rustling, other speech in the background.
Spectral subtraction breaks predictably: when the noise estimate is wrong, musical noise remains in the signal—narrow whistling peaks where the subtracted harmonics were.
It is powerless against room reverberation: it is not additive interference but convolution with the room response; spectrum subtraction cannot remove it.
The neural network pays for this with computation and latency: the model processes a fixed-length frame, and CPU requirements are higher. On an unfamiliar recording type it either under-suppresses or over-dries speech—consonants disappear, a metallic timbre appears.
Lightweight models like RNNoise fit the frame and run in a single stream; heavier ones, like DeepFilterNet, also remove moderate reverberation.
| Approach | What it removes | Where it breaks | When to choose |
|---|---|---|---|
| Spectral subtraction | Stationary noise: hum, hiss, interference | Musical noise, reverberation, non-stationary interference | Recording in controlled conditions, limited computation |
| Neural cleanup | Non-stationary noise, background speech, part of reverberation | Unfamiliar material, latency, over-drying artifacts | Real-time communication, field recording |
| Cascade of two approaches | All of the above with careful tuning | More complex debugging and parameter selection | Need quality headroom and control over artifacts |
In practice, the choice of processing method is dictated by the noise source, not fashion. Stationary background and strict latency requirements—spectral subtraction; heterogeneous noise in the field—neural network.
Reverberation is removed by a separate model: the cascade gives quality headroom, but requires tuning parameters for the specific recording pipeline.
Common technical concerns about audio processing
Engineers who have already listened to noise suppressor output ask the same questions: doesn’t the filter “eat” consonants, what to do with an archive of existing recordings, does processing fit real time, and can a model be trained on own data.
Below—answers without marketing; all four scenarios are resolved at the tuning stage, not after handover.
Will there be metallic timbre and “eaten” consonants?
Artifacts are a consequence of excessive suppression strength. We keep it below the threshold at which sibilants and plosives suffer; we process disputed sections in two passes with different aggressiveness and compare by ear against a reference. The dry signal and a map of applied edits are saved—any fragment can be reverted.
What to do with recordings that are already made?
Batch pass through the directory: recursive processing, originals not overwritten, output—a log per file with parameters. An archive of tens of hours passes without manual control; we selectively re-clean only problematic tracks.
Does processing keep up in real time?
Yes: a frame is processed faster than it sounds, so latency remains comfortable for calls and dictation. If the model is heavy, we split the contours—the stream runs in lightweight mode, and final cleanup is done offline.
Can a model be trained on own data?
Yes, and on your own material the result is higher than a universal one. We collect a set from your recordings: speaker voices, typical room noises, microphones.
Fine-tuning goes by this profile; quality is measured by the share of correctly recognized words and intelligibility by ear.
Let's discuss the task: where we start the review
To come back with an assessment and implementation plan, not general words, we need an analysis of your audio specifically. Usually a short conversation and a few sample files are enough—then the picture becomes concrete.
- Noise character: constant hum of equipment or ventilation, office and keyboard noise, street outside the window, mains interference, echo in the meeting room.
- Material type: calls and conferences, interviews and podcasts, dictation, recorder or headset recording, mixed tracks.
- Source parameters: container format, number of channels, bit depth, where the speaker’s voice is separated from noise and where everything is in one channel.
- Archive volume: how many hours of recordings are in storage, what share requires processing, whether ready transcripts exist.
- Operating mode: real-time stream processing or batch over the archive, allowable latency, where noise suppression is embedded into your process.
- Acceptance criterion: what we consider a good result—speech intelligibility, absence of “watery” artifacts and metallic timbre, preservation of pauses and intonation.
- Constraints: requirements for storage and processing of voice data, access rules for recordings, whether local processing without external upload is needed.
With this set we assemble an implementation plan: select a model for your noise profile, determine the mode and integration points, fix how we will verify the result on your own markup.
The first step—a pilot on a fragment: run processing on 20-30 minutes of real recordings, deliver a “before and after” result, and show which sections remain problematic.
Describe the task and attach a couple of files—we’ll come back with an estimate of recording volume and a work plan.