What is 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.
Speech commands data is a set of short utterances, each an instance of a specific phrase, recorded by many different speakers. The unit of interest is the phrase rather than the session: what matters is how many different people said the same thing.
It is the category with the most rigid structure and the least tolerance for change. Once the phrase list is fixed and recording has started, adding a phrase means a new batch, because a phrase recorded by forty speakers is not comparable to one recorded by twelve.
The dominant uses are wake words, on-device command recognition, and the front end of any voice interface that has to run without a network round trip. All three share a constraint that shapes the data: the model has to run on a small device, so the training set must be small enough to be practical and diverse enough to work for anyone who picks up the product.
What buyers get wrong
What buyers consistently underestimate is the repetition count. A single command entry needs at least a few dozen distinct speakers, each reading it multiple times, to cover pronunciation variation.
The specification detail that decides everything
Once the word list is locked it cannot change; adding words midway means starting a new batch.
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 Speech Commands looks like
Command data is judged on per-phrase depth rather than total volume. Five properties decide whether it will generalize.
-
Distinct speaker count per phrase, stated as a minimum
A phrase with forty speakers and a phrase with eight are not the same asset, even inside one delivery. The minimum belongs in the contract rather than in the summary.
-
Pronunciation variation within each phrase
Deliberate coverage of the ways a phrase is actually said, including the fast and mumbled versions. A corpus of carefully enunciated commands trains a model that only works when people enunciate.
-
A frozen phrase list with a version identifier
If the list changes, the batch changes, and the dataset has to state which version it is so that two batches can be compared or combined.
-
Negative samples
Audio that is not the command but sounds adjacent to it. Wake word models fail on near misses, and near misses have to be recorded deliberately rather than collected incidentally.
-
Recording conditions that match deployment
The device the command will run on, in the environments it will run in, at the distances people actually hold it. Studio recordings of commands predict studio performance.
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.
-
Google Speech Commands
About 105,000 one-second recordings of 35 short words, released for keyword spotting. It is the standard starting point and it is far too small and too clean for a production wake-word system.
-
Fluent Speech Commands
Smart-home style commands recorded by 97 speakers, with intent and slot labels. Useful for command understanding, limited by the speaker count and the single recording condition.
-
Multilingual command sets
A few exist for major languages, and coverage thins quickly outside them. For most languages there is no public command corpus at all.
-
Why production always needs more
Command models are judged on false accepts in noisy rooms, not on clean accuracy. Public sets are recorded close to the microphone in quiet conditions, which is the opposite of the deployment environment.
Questions to ask a supplier
Questions that determine whether a command corpus will survive contact with a real device.
- What is the minimum distinct speaker count per phrase, and is it enforced in the contract?
- How are negative samples collected, and how close are the near misses?
- Is the recording device the deployment device, or a stated proxy for it?
- How is the phrase list versioned, and what happens if we need to add a phrase later?
- What is the pronunciation variation policy within a phrase?
In this category the vague answer is almost always about the negatives. A supplier who describes the command set in detail and says nothing about false triggers has described half a corpus. A command recogniser is judged on what it does when nobody is talking to it, and that material has to be collected deliberately.
A verifiable answer states the command count, the speaker count, the device and distance conditions, and the ratio of non-command audio to command audio. It also states how the non-command audio was elicited, because reading paragraphs aloud is not the same as a television playing in the next room. Those four numbers can be checked in the delivered files.
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.
| Phrase list | Fixed and versioned, delivered with the dataset |
|---|---|
| Speakers per phrase | Minimum and actual, reported per phrase rather than as a total |
| Repetitions per speaker | Stated, typically several per phrase |
| Negative samples | Included or not, with the near-miss policy described |
| Recording device | Named, matched to deployment or documented as a proxy |
| Delivery format | One file per utterance, with phrase and speaker identifiers |
The device and distance columns decide field performance, and they are the ones most often left at a single value. A command set recorded on one phone at thirty centimetres produces a model that works on that phone at that distance. The far-field and multi-device conditions are where deployment actually happens.
The values come from the product rather than from the category. A wearable, a phone and a smart speaker have different microphone arrays, different noise floors and different typical distances. Write the conditions down from the device you are shipping on, and treat any supplier-proposed default as a starting point to be argued with.
A mistake here is invisible until launch. The model reports high accuracy on the test set because the test set was recorded under the same single condition. The first month of field data then shows a false-accept rate far above the design target, and the fix is a collection that includes the conditions that were left out.
How Speech Commands is collected
Command collection is a scheduling problem as much as a recording one.
- Phrase list finalization. The list is frozen and versioned before recruitment begins, because the entire design depends on it not changing.
- Recruitment against the phrase count. The number of speakers needed is the phrase count multiplied by the per-phrase minimum, and that figure drives the recruitment effort.
- Controlled recording. Each speaker reads the full list several times, in a session that also captures the negative samples and the pronunciation variants.
- Condition variation. Where the specification requires it, sessions are repeated at different distances, in different noise conditions, or on different devices.
- Per-phrase verification. The delivery is checked phrase by phrase rather than in aggregate, because the failure mode is one thin phrase inside a healthy total.
After recording, the utterances are segmented, checked against the command list, and the non-command audio is reviewed to confirm it contains no commands. The packaging step separates the two and states the ratio, because that ratio is what determines the false-accept behaviour a buyer can expect.
The pilot for commands is small and fast: the command set spoken by a few speakers under the device conditions the specification names. Its purpose is to test the command set itself, because a list that looked distinct on paper usually has two entries speakers do not distinguish in practice. Finding that on the pilot costs a re-recording of a few hours; finding it after the full run costs the full run.
Acceptance is checked by confirming that every command in the set has usable coverage per speaker and per condition, and that no command is systematically confused with another. The specification should name the minimum utterance count per command before recording starts. Where the pilot shows a confusable pair, the set is revised rather than the data, since a model cannot learn a distinction the speakers do not make.
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.
-
Recorded close-talk only
A corpus recorded at a fixed short distance teaches a model that the speaker is always near the device. Far-field and off-axis recordings are the ones that decide whether the product works in a room.
-
Negative examples were not collected
Command sets usually contain only the commands. Without speech that resembles a command but is not one, the false-accept rate cannot be measured, and false accepts are the failure users notice.
-
One microphone, one room
Device and room acoustics dominate command recognition. A single-condition corpus produces a model that has learned that particular microphone, and the deficiency is invisible until deployment.
Why this matters to buyers
Wake words and on-device commands are the part of a voice product that runs constantly and locally. Their accuracy decides whether the product feels responsive, and their failure mode is the worst kind: a device that wakes when it should not, or does not wake when it should.
The second reason is that this category shows the cost of a thin dataset most plainly. A phrase recorded by a handful of speakers produces a model that works for those speakers and fails for everyone else, and the failure appears as a product that does not respond rather than as a metric that dips.
The visible failure of a command model is embarrassment. A device that wakes when it was not addressed is noticed by every person in the room, and the reports arrive faster than any metric. The underlying cause is almost always a corpus with too little non-command audio, which is cheap to collect at the time and expensive to add later.
The second cost is rework across the stack. False triggers force the wake-word threshold up, which causes missed commands, which then requires a second model to recover, and the engineering time spent on that chain usually exceeds the cost of the original collection. Teams that collect the negatives up front do not spend this.
A command corpus with verified coverage per command and per condition gives a recogniser whose error rate is known per command rather than in aggregate. The product team can decide which commands need a confirmation step, and that decision comes from the corpus rather than from field complaints.
The second gain is extensibility. Command sets grow, and a corpus that recorded its conditions and its per-command counts can take a second batch of new commands without re-recording the originals. The new commands are recorded on the same setup, and the coverage figures stay comparable.
Specification at a glance
| Category | Speech Commands |
|---|---|
| Group | Speech data |
| Critical spec | Once the word list is locked it cannot change; adding words midway means starting a new batch. |
| Included by default | Pilot batch, metadata schema, source and consent documentation |
| Pricing | Quoted from specification. No published rates |
Speech Commands 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.
-
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.
-
Multilingual Speech
Speech data covering multiple languages within one project, used for multilingual ASR, cross-lingual transfer, and language identification.
Questions about Speech Commands
Why does the speaker count per phrase matter more than total hours?
Because the model learns the phrase from the speakers it was given. Ten speakers saying a phrase forty times each is ten speakers of information repeated, not four hundred. The per-phrase minimum is the number that predicts whether the wake word works for a stranger.
Can we add phrases after the batch starts?
Not to the same batch. A phrase added midway will have fewer speakers than the rest, and mixing it in produces a dataset with an invisible weak spot. Adding phrases means a new batch against the extended list.
What are negative samples and do we need them?
Audio that is not the command but resembles it, such as a similar-sounding word or the command spoken inside a longer sentence. Without them the model learns to fire on anything close, which is the false-accept problem.
Should we record on the deployment device?
Ideally yes. Where that is not practical the proxy device has to be named and its differences documented, because a corpus recorded on a studio microphone and deployed on a smart speaker does not describe the deployment environment.
Do you have Speech Commands 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 Speech Commands
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.