Speech data is recorded human voice. Some training tasks pair it with transcripts or speaker labels; self-supervised pretraining can use untranscribed audio. The required labels and recording metadata should follow the task. If you are training an ASR system, a text-to-speech voice, or a voice assistant, the recordings and required labels should represent the task and conditions you intend to evaluate.
This guide covers what speech data actually is, the main types you will meet, what arrives in the box alongside the audio, where it comes from, and how to evaluate source, permissions, annotations, metadata, and QA for audio obtained through any route. It is written for the engineer or data lead doing the homework before the budget gets spent.
What speech data is, precisely
Speech data is audio of people talking. Which labels it needs depends on the task: supervised speech recognition uses audio and transcripts, supervised speaker-recognition training uses speaker labels, and self-supervised pretraining can learn from untranscribed recordings. The wav2vec 2.0 paper demonstrates that last route. Do not reject useful unlabeled audio or pay for every annotation layer until the training recipe is clear.
Confirm the accepted encoding, sample rate, channel layout and segmentation for the actual model or service version. Preserve an authorized source copy where appropriate, record transformations and check derived files before training; resampling or normalization is not automatically a defect. The official LJ Speech documentation, for example, describes single-channel 22,050 Hz WAV recordings. Microsoft Custom Speech documentation sets its own input requirements for particular training and testing routes. These are specific recipes, not a sample-rate rule for every ASR or TTS model.
The main types of speech data
Describe both how speech is elicited and how it is captured. Read, prompted and spontaneous speech describe the speaking task; microphone distance, device, channel and noise describe the recording conditions. These dimensions can overlap. For example, the historical CHiME-4 dataset combines read speech with distant microphones and real noisy environments.
Read or scripted speech
The speaker reads prepared text aloud: sentences, paragraphs or phonetically balanced prompts. The script helps define content coverage, but it is not automatically a verbatim transcript of what was spoken. CHiME-4 documents corrections for reading errors and distinguishes the prompt from the transcription. Read speech can be useful for a defined synthesis or recognition task; test whether its speaking style and capture conditions represent the intended use.
Prompted speech
The speaker responds to a task or cue, such as answering a question, naming an object or giving a command. Define whether exact wording is required or a free response is allowed: a fixed command and an open answer need different checks. Prompted collection can target wake words or command coverage, subject to the actual speaker, language and recording requirements.
Spontaneous and conversational speech
Here people talk freely, alone or with each other. Recordings may include disfluencies, false starts, overlapping turns, filler words and varied prosody. Specify which of those phenomena need representation and labels for the task. A meeting-transcription brief, for example, may require overlapping turns and speaker annotations; those requirements do not follow merely from calling a corpus conversational.
Capture conditions: far-field and in the wild
Far-field describes microphone distance; in-the-wild describes capture outside a tightly controlled setup. Neither term alone tells you the other conditions. A smart speaker across a room, a car cabin or a phone on a table can involve different microphones, channels, noise and reverberation. Record those conditions explicitly, including whether noise was captured live or added later.
Consider an illustrative brief for voice commands in a car: specify the spoken commands separately from microphone placement, road noise and speaker coverage. A quiet close-microphone recording of the right words does not establish coverage of the requested cabin conditions. A read command captured in that cabin can satisfy both descriptors. This is a planning example, not a completed collection or model result. Our speech-data sizing guide discusses choosing coverage before an hour target.
What ships alongside the audio
Agree the delivery package for the training stage. Audio-only pretraining need not include a transcript; supervised recognition and reference-based recognition evaluation need the applicable audio-text pairs. When transcripts are required, document segmentation, alignment and conventions for numbers, punctuation, casing and non-speech events. A script, verbatim transcript and normalized transcript serve different jobs. The ASR training-data and TTS training-data guides cover their respective task requirements.
Request identifiers and recording metadata that the project needs, such as language, locale, device, environment, sample rate and channel layout. Speaker attributes should be justified and permitted, rather than an assumed package of age, gender or accent fields. If assessing group coverage or performance, first establish appropriate attributes, records and evaluation data. Optional annotation layers include speaker turns, emotion or intent tags, sound-event labels and phonetic alignment. Our audio annotation guide explains how to specify and check the layers that matter.
One field is easy to overlook: provenance and permitted use. Each file should link to the applicable source, permission and license records, privacy notice and lawful basis where relevant, and consent record when consent is relied on. Without those records, suitability remains unverified no matter how clean the audio sounds.
Where speech data comes from
Compare the actual source and release. Open speech datasets, including academic and community releases, may provide a starting point when their contents, documentation and permissions fit. Inspect the exact release, coverage, labels, restrictions and preparation work; an open listing alone does not establish low cost, suitability or training rights.
Commissioned collection starts from a proposed specification, with recruitment, recording, annotations and delivery subject to feasibility and agreed acceptance. Possible requirements might include Norwegian speakers across justified age bands in car-cabin noise, or 200 distinct voices reading domain-specific prompts. These are illustrative briefs, not claims of available stock or completed Spirelight projects. Compare the quoted scope, schedule and total implementation work with existing assets. Spirelight assesses project-specific language, locale, speaker profile and recording conditions before launch; the speech data collection service explains that process.
A third route obtains audio from existing web, media, or call sources. Acquisition method alone does not establish permission or risk. For each source, review copyright and license terms, speaker and platform permissions, applicable lawful basis and notices, transcripts, metadata, recording conditions, and QA.
What makes speech data fit for training
Training suitability is specific to the task and source. Request the applicable permission and license records, privacy information and lawful basis, consent records when consent is relied on, documented recording conditions and relevant QA evidence. Add transcripts, alignments, speaker attributes and other labels only where the intended training or evaluation stage needs them.
An unresolved rights or source-record gap needs the applicable review; a missing transcript or label may instead be a technical gap for a particular task. Keep those decisions separate. Untranscribed audio can be suitable for an audio-only training stage, while a supervised recognition task may require verified transcripts before proceeding. Compare verification and annotation work on the existing source with a purpose-recorded scope. The buying AI training data guide covers procurement decisions.
Define the model job, training stage, language and locale coverage, speaker distribution, recording conditions, required labels and intended uses before comparing options. Record acceptance evidence and unresolved gaps in the speech dataset specification worksheet. A sample that opens correctly is a starting point; it does not establish full distribution coverage, training suitability or rights.
Spirelight publishes 60 conversational speech dataset listings, with recording details and sample-request options on the individual pages. Confirm current availability, sample coverage, permitted uses and written commercial terms for the specific asset. If a material gap needs new recordings, a proposed custom collection requires its own feasibility assessment and agreed scope.