A speaker recognition dataset is graded on a different scale than the audio you would buy to train a transcriber. For speech to text you want coverage of what people say. For speaker verification and identification you want coverage of who is saying it, captured often enough, on enough devices, to teach a model what stays constant about a voice and what drifts. The two goals pull against each other, and a corpus built for one rarely does the other job.
This guide is for teams building speaker verification or identification who are deciding what voice biometrics data to collect or license. It covers speaker count and session structure, the channel and device variation that decides whether your model generalises, anti-spoofing, and the heightened consent that voiceprint data carries because it identifies a person, not a sentence.
What a speaker recognition dataset has to contain
The first number that matters is the count of distinct speakers, and it is almost always higher than buyers expect. A model that tells one voice from another is learning the shape of the whole space of human voices, not a handful of points in it. A few hundred speakers is a floor, and serious systems train on thousands. A clip from a well known open corpus can look like a lot of audio, but if it comes from a small cast of speakers the model overfits to those individuals and falls apart the moment it meets someone new.
The second requirement is multiple sessions per speaker, recorded on different days. A single sitting captures one mood, one mic position, one state of health, one background. Verification has to survive a person who is tired today and energetic next week, who enrolled on a laptop and now signs in from a phone in a car. If every utterance from a speaker comes from one continuous session, the model can cheat by latching onto session level cues, the room, the channel, the noise floor, instead of the voice. Good speaker identification data spreads each person across time so that the voiceprint is what is left when everything else has moved.
You also want both enrolment style and test style material. Speaker verification data usually pairs longer, cleaner enrolment audio against shorter, messier verification attempts, because that is what production looks like: a careful sign up followed by a hurried login. If your dataset holds only pristine read speech, your equal error rate on a clean held out set will flatter you and your real world rate will not.
Channel and device variation decide whether it generalises
The most common reason a speaker recognition dataset disappoints in production is that it was recorded under conditions the deployment never sees. A model trained only on close mic studio audio learns to recognise voices and the studio. Move it to a phone speaker across a noisy kitchen and the channel shift swamps the voice signal it was leaning on.
Plan that variation in rather than hoping it turns up. Across the speaker pool you want a spread of capture devices, phones of different makes, laptops, headsets, far field smart speaker mics, a spread of acoustic environments, quiet rooms, street noise, cars, reverberant spaces, and, the part people skip, the same speaker recorded across more than one of those conditions. That overlap is what teaches the model to factor the channel out. A dataset where device lines up perfectly with speaker is worse than no data: the model will quietly learn the device and report it as accuracy.
If your product is multilingual or serves accented populations, the pool has to reflect that too. A verification model tuned on one accent group can show measurably different error rates on others, which is an accuracy problem and a fairness one at the same time. Our note on multilingual speech data covers how to recruit across languages and dialects without letting one group dominate, and the same discipline applies when your axis of interest is the speaker rather than the language. For in car use the acoustics are specific enough that our automotive voice data guide is worth reading next to this one.
Anti-spoofing and presentation attacks
A speaker recognition system that only ever sees genuine speakers is naive by construction. The moment voice authentication is worth attacking, attackers show up with replayed recordings, text to speech, and voice conversion of the target. A model trained purely to tell speakers apart has no notion that a voice can be fake, so it will happily wave through a good clone.
That is why anti-spoofing data belongs next to the recognition data, not in a separate project. In practice you collect or license spoofed examples alongside the genuine ones: replay attacks captured through real playback chains, synthetic speech from current TTS systems, and converted voices. The genuine and spoofed material should share speakers and channels, so the countermeasure learns to separate live from fake rather than separating two unrelated recording setups. Synthesis keeps improving, so a one time spoof set ages fast and you should budget to refresh it.
Voiceprint data is biometric, and consent is not optional
A voiceprint identifies a specific person, which puts this data in a different legal class from a transcript of an anonymous sentence. Under GDPR and comparable regimes, audio processed to identify or authenticate someone is biometric data in a special category, and it generally needs explicit, purpose specific consent. The wording carries weight: consent to record someone for transcription does not cover building a model that recognises them, and you cannot bolt the right purpose onto recordings gathered for a different one.
Treat that as a procurement gate, not a footnote. For a speaker recognition dataset it means consent that names speaker recognition and biometric processing as the use, a record mapping each consent to the individual contributor and their files, and clear terms on retention, withdrawal, and onward transfer. Anti-spoofing adds a twist: if you synthesise or convert a contributor's voice to make attack examples, the consent has to cover producing a synthetic version of them as well. Our guide on speech data licensing and consent walks through the grant terms, provenance trail, and ownership language to insist on before you sign, and it bites harder for voiceprint data because the cost of a weak provenance trail is higher here.
This is also why you should be wary of voice scraped from the open web or repurposed from another project. It rarely carries speaker level consent for biometric use, the speaker count and session structure are whatever the source happened to have, and you inherit a provenance problem you cannot fix after the fact. A custom collection with consent attached from the start is slower to stand up and far easier to defend.
How much, and how to scope a collection
There is no single right size, because it turns on how many speakers you have to tell apart and how hard your channel conditions are. The cleanest way to scope is to fix the speaker count first, then sessions per speaker, then per session duration, instead of starting from a total hours figure that buries all three. A model that has to verify across many devices needs more sessions per person than one living on a single hardware platform. Our guidance on how much speech data you need sets out how to reason from the use case back to a quantity rather than guess at one.
When the off the shelf corpora do not match your speakers, channels, or anti-spoofing needs, a commissioned collection lets you specify the speaker pool, the session cadence over time, the device mix, and the consent terms up front. That is the kind of build we run: recruiting a large, diverse contributor pool, recording the same speakers across sessions and devices, quality checking, and delivering structured data with consent attached to every file.
If you are scoping a speaker verification or identification system and want data with the speaker count, repeat sessions, channel variation, and biometric consent these models actually need, start from the ready made and custom options on the datasets page and tell us what your model has to recognise.