What is Noisy Speech?
Speech collected under background noise (street, in-car, restaurant, office and other real environments), used for noise-robust models and speech enhancement.
Noisy speech is audio recorded in the presence of background sound that is part of the recording rather than removed from it. The noise is not a defect; it is the variable being modelled. What separates a useful noisy corpus from a pile of bad recordings is that the noise is characterized.
The category exists because clean corpora produce models that fail outside the studio. A recogniser trained on quiet audio meets street noise, restaurant chatter or engine sound as a distribution it has never seen, and its accuracy drops in exactly the conditions where a voice product is most likely to be used.
Uses divide into robustness training, where the model learns to work despite the noise, and enhancement, where the model learns to remove it. The two need different corpora: robustness training needs noise that matches deployment, while enhancement needs paired clean and noisy recordings of the same speech.
What buyers get wrong
Noise type has to be reproducible. Buyers do not want vaguely noisy; they want a specified condition like restaurant chatter at 5 dB SNR.
The specification detail that decides everything
Signal-to-noise ratio (SNR) level and noise type must be annotated per file, or the data cannot be reproduced.
This is the line item that most often separates a dataset that works from one that gets re-ordered. It belongs in the specification before production starts, not in the delivery review.
How we source it
We do not hold inventory in this category. A requirement comes in, we match it to a producer who can meet the specification, and we agree the quality bar with both sides before recording begins. A pilot batch goes first so misalignments surface early.
Scenarios this covers
Buyers rarely ask for a category by name. They describe a situation, and the situation is what tells us whether this category is the right one. If yours is in the list, name it in the brief and it goes straight into the specification. If it is not, describe it anyway, because it usually means the requirement sits in a neighbouring category.
What good Noisy Speech looks like
What separates a usable noisy corpus from a pile of bad recordings is characterization. Every file has to say what the noise is.
-
Noise type labelled per file
Restaurant, street traffic, in-car, office, wind. Vague noise is not a specification and cannot be reproduced in a second batch.
-
Signal-to-noise ratio measured rather than estimated
The SNR is what makes the corpus usable for training a model that has to work at a particular level, and an unmeasured SNR is a guess recorded as a fact.
-
Stationary and non-stationary noise both present
Steady hum and intermittent clatter are different problems, and a corpus containing only one produces a model that handles only one.
-
Competing speech as its own label
Background conversation is the hardest noise case and behaves differently from mechanical sound, so it has to be distinguishable in the metadata rather than folded into a general noise category.
-
Clean reference where enhancement is the target
Paired recordings of the same speech with and without noise. An enhancement model has to learn the mapping, which requires both sides of it.
Public datasets in this category
These are openly documented resources, not products we sell. Each one covers part of the category, and knowing where each stops is usually what decides whether a project needs a collection of its own.
-
CHiME challenges
A series of far-field and noisy speech datasets built around dinner-party and home scenarios. They are the standard benchmark for noise robustness and they are evaluation-scale rather than training-scale.
-
VoiceBank-DEMAND
A paired corpus of clean and noisy speech, widely used for speech enhancement. The pairing is what makes it useful for measuring enhancement, and it covers one noise set recorded in one set of conditions.
-
DEMAND
A noise database of environmental recordings across many categories, used to add noise to clean speech artificially. Useful for augmentation, and artificial mixing does not reproduce the way noise and speech interact in a real room.
-
Why simulation is not enough
Mixing clean speech with a noise recording produces a signal that is statistically convenient and acoustically simplified. Real noisy speech includes reverberation, competing talkers, and device distortion that the mixing model leaves out.
Questions to ask a supplier
Questions that reveal whether the noise in a corpus was designed or simply happened.
- How is SNR measured, and with what method?
- What noise types are covered, and how many files per type?
- Is competing speech included as its own category?
- For enhancement work, are clean references available for the same recordings?
- Was any noise reduction applied before delivery?
The vague answer in this category concerns the noise itself. A supplier who says the audio is recorded in noisy conditions without naming the noise types and their levels has described an atmosphere. Robustness comes from noise that is measured, labelled and reproducible, not from recording in a cafe and hoping.
A verifiable answer names the noise categories, the signal-to-noise ratios and how each was produced. Ask whether the noise was mixed in post-production or captured live, because the two behave differently at the boundary and the difference matters for anything deployed in the field. Ask also for the clean reference, since without it the noise cannot be re-mixed at a different level.
Technical attributes
The items below are the ones a specification can hold a producer to, and the ones that decide whether a delivery is usable for training rather than only present.
| Noise type | Labelled per file from a defined set |
|---|---|
| Signal-to-noise ratio | Measured per file, with the measurement method stated |
| Noise character | Stationary, non-stationary, or competing speech |
| Recording environment | Documented per file |
| Clean reference | Available or not, required for enhancement use |
| Delivery format | Audio with a per-file noise and SNR annotation table |
The signal-to-noise ratio column decides how far the corpus can be pushed, and it is the one most often given as a range without a distribution. A corpus described as between zero and twenty decibels may be almost entirely at the top of that range. Ask for the histogram rather than the range.
The values come from the environment the model will run in. A vehicle cabin, a factory floor and a street have different noise spectra, and the level that matters is the one at the microphone rather than at the source. Measure the target environment first, then specify conditions to match it.
A mistake here is invisible in the corpus metrics and visible in the field. A model trained on noise that was mixed in post-production learns the mixing artefacts as much as the noise, and it performs well on the test set and worse on live audio. Recovering means collecting in the real environment, which is slower and more expensive than the studio session it replaces.
How Noisy Speech is collected
Noisy collection is controlled recording in uncontrolled conditions, which means the control moves into the metadata.
- Environment selection against the deployment profile. The noise conditions are chosen to match where the model will run rather than to be dramatic.
- Level calibration before recording. The speech-to-noise ratio is set and measured at capture rather than estimated afterward, because a level that was not measured cannot honestly be reported.
- Simultaneous capture of the noise floor. Where the specification allows it, a short noise-only sample is recorded at each session so the SNR can be verified rather than assumed.
- Annotation of noise type and level. Every file carries its noise category and its measured SNR, with competing speech marked separately.
- Paired clean capture where enhancement is the target. The same speaker reads the same material in a quiet condition, giving the enhancement model a reference to learn toward.
After recording, the audio is checked for clipping, the noise conditions are verified against the specification, and the files are packaged with per-utterance metadata covering the noise type and the measured ratio. The verification step is what turns a claim about conditions into a number a buyer can filter on.
The pilot for noisy speech is recorded in the target environments rather than in a studio, because the property being tested is whether the noise can be characterised and reproduced, and a studio run cannot show that. A short session in each named environment establishes the noise floor, the distance and the spectrum, and those measurements are what the full run is then specified against.
Acceptance is checked on the measured signal-to-noise distribution against the specification, not on the average. The specification should state the histogram rather than a range before recording starts, because a batch can sit entirely at the top of a wide range and still look compliant. Where the pilot shows an environment does not produce the required conditions, the environment is changed rather than the measurement.
How a delivery goes wrong
The defects below are the ones that recur across this category. Each is decided at collection or annotation time, which is why none of them can be repaired in delivery review.
-
Noise condition is described but not measured
A corpus labelled "noisy" without a signal-to-noise figure cannot be matched to a deployment environment. The label is a word, and the number is what makes it a specification.
-
One noise type throughout
Café noise and road noise affect speech differently. A corpus containing one type trains a model that handles that type, and the manifest usually does not say which one it is.
-
Clean reference was not captured
Where the use involves enhancement or denoising, the clean signal has to be recorded alongside the noisy one. Reconstructing a reference afterwards is not the same thing and does not support the same measurements.
Why this matters to buyers
The gap between laboratory accuracy and field accuracy is almost entirely a noise problem. A recogniser that scores well on a clean benchmark and poorly on a phone in a car has not been trained on the distribution it meets, and the remedy is data rather than architecture.
The second driver is enhancement, now a standard component of consumer audio products. Removing noise requires knowing what the clean signal was, which means paired data, and paired data has to be designed into the collection rather than extracted from it afterward.
A model that fails in noise fails in the situations where it is most needed. Recognition in a car, in a contact centre and on a factory floor all happen in conditions that a clean-corpus model treats as an edge case. The visible symptom is a product that works in the office and not where it is deployed.
The second cost is debugging time. Noise-related failures do not present as recognition errors, they present as intermittent and unexplained ones, and teams spend weeks examining model architecture before suspecting the training conditions. That investigation costs more than the collection would have.
A noisy corpus with a measured distribution lets a model be evaluated at the operating point the product will meet. The team can report an error rate per noise level rather than a single figure, and that breakdown is what makes the deployment decision rather than the average.
The second gain is reusability. Where the clean reference and the mixing method are documented, the same recordings can be re-mixed at a different level for a second product without a new collection. Noise conditions differ between products, and a corpus built for re-mixing serves several of them.
Specification at a glance
| Category | Noisy Speech |
|---|---|
| Group | Speech data |
| Critical spec | Signal-to-noise ratio (SNR) level and noise type must be annotated per file, or the data cannot be reproduced. |
| Included by default | Pilot batch, metadata schema, source and consent documentation |
| Pricing | Quoted from specification. No published rates |
Noisy Speech across languages
This category is available in every language we cover. The difficulty changes with the language, which is why each language page documents its own constraints.
Related categories
-
Call Center Speech
Customer-service calls, simulated rather than intercepted, capturing both the agent and the caller side, used for call center QC, intent recognition, and dialogue systems.
-
Conversational Speech
Speech from natural conversation between two or more people, on open or semi-structured topics, used for conversational AI, voice assistants, and small talk models.
-
Singing Voice
Vocal recordings with melody, in both a cappella and accompanied form, used for singing voice synthesis, music information retrieval, and lyric alignment.
-
Speech Commands
Targeted recordings of short command words or phrases, usually with many speakers reading each entry several times over, used for wake words and on-device command recognition.
-
Read Speech
Recordings of speakers reading specified text, with clear pronunciation and known text, the base material for TTS and ASR.
-
Podcast Speech
Long-form podcast and interview audio, either solo monologue or two-person conversation, used for long-form speech recognition and speaker modeling.
Questions about Noisy Speech
Should the noise be removed before delivery?
No, and this is the most common way a noisy corpus is ruined. Removing the noise removes the thing the buyer is paying for. If the specification needs both, deliver both as separate sets rather than one processed set.
How is SNR measured in practice?
By measuring the speech level and the noise level separately within the same recording, usually from segments where only one is present. The method has to be stated, because different methods give different numbers for the same file.
Can you match a specific deployment environment?
Yes, and that is the right way to specify it. Describe where the product will be used, and the noise conditions are chosen to match rather than picked from a generic list.
Do we need competing speech?
If the deployment involves other people talking, yes. Competing speech is the hardest noise case for recognition and behaves differently from mechanical sound, so a corpus without it will overstate performance in crowded places.
Do you have Noisy Speech available now?
No. We do not hold inventory. Everything is produced against a specification. That means the timeline starts when the spec is agreed rather than immediately, and it also means the data matches your requirement instead of approximately matching something already built.
Can this be combined with other categories in one delivery?
Yes, and it is common. A single specification can cover several categories across several languages, with one pilot batch and one quality bar. It usually reduces total cost because contributor recruitment and project setup are shared.
What does the consent documentation cover?
Signed contributor consent stating the intended use, the collection methodology, and the annotation guideline the data was produced under. For projects involving EU data subjects the chain is built to satisfy GDPR, including the transfer mechanism. The terms for moving the data across a border.
Request Noisy Speech
Tell us the language, the hours, and what the data needs to look like. You will get a real number and a real timeline, not a range. If we cannot source it well, we will tell you that instead.
- Pilot batch before the full run, so problems surface early.
- Consent documentation delivered with the data.
- No medical or clinical data. No recorded telephone calls.
- You send the spec Language, hours, recording conditions, and the deadline.
- We reply within two business days A real number and a real timeline, not a range.
- You approve a pilot batch A small run first, so problems surface before the full order.
- Full run, then delivery with documents Audio, transcripts, and the consent record for every speaker.