STT with noise suppression: WER < 10% even at SNR 5 dB

Why noise robust STT breaks on real noise

On studio recordings, the model rarely makes mistakes, but on a shop floor, in a warehouse, outdoors, and in a car cabin, the word error rate increases several times over.

It is not just hum: reverberation from concrete walls blurs word endings, echo between racks overlays an utterance on itself, and a voice far from the microphone drowns in the noise of a forklift or engine. This is exactly where noise robust STT loses the very thing it was deployed for.

The second layer is the microphone and communication channel. A phone headset produces a narrowband signal with cut upper frequencies, and that is exactly where hissing and whistling consonants are distinguished.

As soon as they disappear, speech recognition in noise stops distinguishing numbers and codes, substituting similar-sounding variants instead of an SKU or order number.

Next, the language model makes mistakes: instead of a rare word — an item name, surname, or waybill number — it confidently inserts a frequent one. The error looks plausible and is not caught by spot checks.

The speech detector adds its own issues: it cuts phrases at noise bursts, merges utterances from two speakers, and loses short answers.

Together, this produces recognition failures on recordings, because of which audio transcription quality falls short of documentation: the text is proofread manually, and analysis of shifts, receiving, and requests proceeds on incomplete data.

Below we break down how noise-robust speech recognition is built — from audio preparation and microphone selection to tuning the dictionary for a specific site.

What robust recognition delivers: measurable effect

The first measurable result is the recognition error rate on complex recordings.

We calculate it separately for clean audio and for an archive with negotiations, street, and shop floor: if on a studio recording the metric stays at the lower bound, but on a noisy one it doubles, the system is not ready for real data. The benchmark is a narrow gap between the two sets, not a nice average in a report.

We test robustness to background noise on files with a low signal-to-noise ratio, where speech overlaps music, equipment hum, or nearby conversation.

Such recordings used to go entirely to manual transcription; now the model extracts speech and returns text with predictable quality, marking disputed fragments for proofreading.

Transcription speed stops depending on interview length: an hour of dialogue is processed in batches in minutes, an accumulated archive is processed overnight instead of weeks, and segments retain timecode alignment for comparison with the source.

The volume of manual editing is the most honest indicator. The editor does not retype, but proofreads: corrects names, terms, and numbers, spending time on meaning rather than deciphering the unintelligible.

When the share of words requiring intervention drops to single-digit percentages, one specialist handles a volume that previously kept an entire group busy.

Separately, we record the eliminated class of failures: missed utterances, merging of different speakers, loss of short answers against noisy background. They do not show up in average accuracy, but they were exactly what forced recordings to be replayed again.

STT operating modes: streaming, batch, hybrid

The processing mode is chosen not by "model quality," but by where the result is needed — during speech or after recording. Streaming speech recognition returns intermediate hypotheses as audio arrives, batch processing of recordings works with a complete file.

A hybrid recognition scheme combines both pipelines: draft transcription runs in real time, while a refinement pass forms the final text.

The key trade-off is context. In real-time audio processing, the model does not see the end of a phrase and confuses names, terms, and homonyms; the batch pass reads the recording in full and is therefore more accurate, but the result appears only after the file is complete.

All three modes rely on a shared acoustic and language pipeline, so switching does not break dictionaries, post-processing rules, or labeling. Streaming and batch pipelines coexist on the same infrastructure: during the day, load goes to real time; at night, to batch.

Implementation stages of noise-robust recognition

The workflow is structured so that every change is based on measurements, not on hearing.

First we record the recording conditions and noise profile, then assemble the processing pipeline, and only after that tune suppression — a targeted adjustment for one channel almost always worsens another.

Below are the stages that speech recognition implementation goes through, from recording audit to handover of regulations.

1. Audit of audio recordings. We label real channels: telephone line, operator headset, microphone in the room. We record noise level, echo, voice overlap, and speech share in the recording — these are the boundaries within which the model must work.
2. Target metrics. We agree on what counts as an error: a missed word, wrong name, lost digit. For the task, we build a held-out sample against which we will check model quality.
3. Pipeline design. We split the stream into links: speech segmentation, speaker separation, noise suppression, recognition, text post-processing. Each link has its own input, output, and verification method.
4. Noise suppression tuning. We select filtering modes for the recording profile — separately for narrowband and separately for wideband. We fix parameters in configuration so the result is reproducible on new recordings.
5. Model quality check. We run the held-out sample and analyze the worst recordings: where exactly words are lost. We break causes down by noise, echo, and speech rate — and fix the link responsible for them.
6. Handover of regulations. We provide configurations, pipeline design, instructions for connecting new channels, and a set of reference recordings. Plus a retraining rule: when and on what data to update the model.

What we hand over to the customer: configurations and regulations

We hand over not a file archive, but a working kit that your team can use to operate the system and develop it without us. Each artifact has a version and owner, so updating one part does not break the others.

• Audio processing scheme — the path of a recording from stream intake to text: where noise level is estimated, when the recognition model connects, and what happens if connection drops.
• Noise-suppression profiles for recording types: meeting room, street, call center, voice recorder. The profile is selected automatically by signal features, but can be switched manually for a specific source.
• Recognition settings for the domain — dictionaries of terms and abbreviations, rules for normalizing numbers and dates, and a list of words that must not be corrected automatically.
• Access policies for recordings: separation of rights to audio and to text, retention periods, masking of personal data at input, and a log of archive accesses.
• Quality control policy — on which labeled set the error rate is measured, how often, who analyzes discrepancies, and at what deviation retraining is launched.
• Recognition documentation: description of the model, its limitations and weaknesses, instructions for updating dictionaries and rolling back to the previous version.
• Monitoring instructions — signals that show accuracy drop or response time increase, and the on-call procedure.

We review the kit at handover together with your engineers and record who is responsible for what going forward.

Case: warehouse contact center — errors before and after

Before: transcription was manually double-checked

A warehouse contact center took calls directly from loading equipment: headsets, ventilation hum, radio conversations in the background. Automatic transcription broke down on the most important things — waybill numbers, unloading addresses, vehicle arrival times.

The operator replayed the recording and corrected the text by hand, and the share of incorrectly recognized words in noisy segments stayed around 22%.

What was changed in the pipeline

The input path was rebuilt: stationary noise suppression, separate handling of operator and customer channels, and a separate model for short confirmation phrases.

Retraining used real shift recordings, not studio samples — the same headsets, the same interference; reference labeling was checked against the open corpus Common Voice.

Quality control of transcriptions became measurable: disputed low-confidence fragments went to manual labeling, and these same examples returned to the training set — the error rate fell iteration by iteration.

After: what measurements showed

On noisy channels, the speech recognition error rate dropped from 22% to 8-9%; on waybill numbers — to 3%, where manual clarification requests previously began. Finished text now flows in parallel with the conversation, not several minutes after the call.

The volume of manual editing fell by about five times: the operator reviews only flagged fragments, not every dialogue in full — and this freed the shift to handle requests, not proofreading.

What to do if another recognition engine is already deployed

Replacing a recognition engine almost never means rewriting the system: recognition is a separate layer. Telephony provides audio, the service returns text and timestamps, and business logic lives above.

So migration comes down to switching the stream and bringing the engine response to the format your system already consumes.

Before replacement, we fix three points: where audio is captured — a stream from the switch or a recording file; how channels arrive — mixed to mono or separated; and which domain term dictionary is used now.

Separated channels give near-error-free speaker separation; mixed mono requires additional processing — the difference is visible on the first test calls.

To avoid downtime, we enable the new engine as a parallel pipeline: it receives a copy of the audio stream, while the old one continues serving subscribers.

On the same recordings, we compare results — you can see where the new model is stronger on noise, not "on average." We switch via routing, and roll back by returning the stream to the previous address.

We check compatibility with current telephony separately. If you have Asterisk or an equivalent, integration goes through streaming audio and notifications about call start and end — no changes to the PBX itself are needed.

We look at resampling between narrowband and wideband audio, packet loss, and the latency that real-time recognition adds.

We transfer recording history by batch reprocessing the archive: old calls get text, labels, and search instead of remaining "mute." One limitation — in a compressed lossy format, accuracy is lower than on a live stream, and we determine this on a sample in advance, not after switching.

Technical doubts: latency, load, quality

Before discussing timelines and scope, customers check not quality on a clean demo recording, but service behavior under load: will transcription keep up with the speaker, what happens at peak, how fragments with overlapping voices are processed, and how well the model adapts to industry vocabulary.

Below are four engineering objections that we address on every project, with honest limits of applicability.

What happens under peak load on the service?

Task queue, auto-scaling of recognition nodes, and a limit of simultaneous streams per client. When capacity is exhausted, the service does not fall: short phrases get priority, and batch transcription of archives is shifted. We separately test degradation on a load profile taken from your traffic.

How are recordings with overlapping speech processed?

We separate voices into tracks and label utterances by speaker, so overlapping phrases are not "glued" into meaningless text. Areas where sources are inseparable are marked as uncertain — they are visible in the output and can be sent for listening.

On noise where speech is comparable to background, we maintain quality through noise suppression before recognition.

Is retraining on our terminology realistic?

Yes, and most often without full model retraining: a hint dictionary for names, SKUs, and abbreviations plus adaptation on the customer's labeled recordings.

Before implementation, we build a regression set, record speech recognition error rate before and after, and monitor that the general dictionary does not degrade. Retraining affects only your pipeline — others' data does not get into it.

Let's discuss the task: what to clarify before project start

To ensure the recognition project estimate is based on your pipeline rather than market averages, we need source data for calculation.

Below is what to lay out point by point before discussing the technical specification: this set is enough to come back with an implementation plan, not general wording.

• Recording channels and nature of audio: telephone line, microphone in the room, operator headset — the choice of noise suppression and the achievable error threshold depend on this.
• Stream parameters: daily volume, session duration, number of channels, storage format — the basis for load and storage calculation.
• Target accuracy level by scenarios (dictation, dialogue with a client, speech in noise) plus a dictionary of terms and names — the language model is tuned for it.
• Samples from the noisiest conditions: one or two hours with reference transcripts — we use them to measure baseline accuracy before work starts.
• Pipeline constraints: own server, closed network or cloud, requirements for personal data storage and access level.
• Integration points: telephony, customer accounting system, protocol database; whether a real-time stream is needed or batch processing is sufficient.

Describe the task and attach what you already have — even a partial set gives a much more accurate estimate than written correspondence. We will look at your recordings, name a realistic accuracy threshold, and come back with a work plan for your pipeline.