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 privacy, biometric-data, permission, and security assessment required when data is used to identify a person.
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 requires a biometric-data assessment
Under the GDPR, personal data resulting from specific technical processing that permits or confirms unique identification is biometric data; Article 9 applies when it is processed to uniquely identify a person. Determine the controller and processor roles, Article 6 lawful basis, applicable Article 9 condition, notices, purpose, retention, security, transfers, and data-subject handling for the exact use. Explicit consent is one possible Article 9 condition, not a universal answer.
If consent is relied on, verify that it specifically covers the relevant recognition, authentication, and any synthetic or converted anti-spoofing processing, and document withdrawal handling. A source collected for transcription does not automatically support biometric identification; later paperwork does not by itself validate earlier processing. For every existing or repurposed source, also verify permissions, provenance, speaker distribution, and session design. Compare that evidence and fit with a purpose-recorded collection, which still requires its own project-specific legal and operational assessment. See the speech data licensing guide for contract and record questions.
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 existing corpora do not match the speaker, channel, or anti-spoofing brief, a commissioned collection can specify the speaker pool, session cadence, device mix, privacy basis, permissions, and records. Spirelight can assess repeated-session recruitment, device variation, QA, and project-specific provenance requirements; feasibility, participant criteria, security, deliverables, schedule, and price are confirmed in writing.
If you are scoping a speaker verification or identification system, use the collection configurations as planning references and provide the target speaker count, repeat sessions, channel variation, intended processing, rights, and privacy requirements. The pages do not establish inventory or feasibility.