Custom speech data collection means commissioning recordings to a written specification when available data cannot be shown to meet the intended task, conditions, coverage, or rights. First compare licensed sources against the same requirements and a representative test set. If a gap remains, scope the missing recordings, acceptance checks, deliverables, and licence before requesting a quote.
This guide explains scripted, prompted, and spontaneous recording, gives a reusable buyer brief, and shows how to plan recruitment and quality checks. The right sequence and timeline depend on the task and the evidence from a pilot; a catalogue purchase, adaptation, or a smaller targeted collection may meet the need.
When off-the-shelf data is not enough
Start with the intended task, not the supplier category. Record the language and dialect, speaker groups, acoustic conditions, labels, delivery format, permitted uses, and the metric the model or evaluation team will use. Then compare licensed datasets, adaptation of existing material, and new collection against that same brief. A catalogue match can save a new recording project; a published language label alone does not prove that the audio, rights, or conditions fit.
For ASR, test with held-out audio that resembles the target traffic before assuming more training recordings are needed. Microsoft’s custom speech guidance calls for training and test samples from the speakers and scenarios the model should recognize; its evaluation guidance describes how to assess recognition accuracy with test audio. These are examples of a test method, not requirements for every speech model.
Suppose a dispatch assistant must recognize warehouse-headset commands. An existing corpus might cover the words but miss the headset channel or the deployment noise; targeted evaluation can show which gap matters. If a licence, dialect, acoustic condition, or usage right cannot be met, write that gap into the custom brief. If the existing material passes the buyer’s acceptance test, a new collection may add cost without solving a measured problem.
Scripted, prompted, and spontaneous collection
Choose how speakers produce the target speech separately from where and how the audio is recorded. The elicitation method changes coverage and naturalness, but its suitability depends on the model task and the held-out test.
Scripted speech asks speakers to read fixed text. A script makes target words, phrases, and phonetic units easier to plan and check. It can suit wake words, commands, or pronunciation coverage. It does not by itself reproduce how a user speaks in an unscripted interaction.
Prompted speech gives a scenario or goal rather than exact words. It can elicit varied responses while retaining some control over the topic. Check pilot recordings for the vocabulary, turn structure, and recording behavior the task needs; a prompt does not guarantee natural speech.
Spontaneous speech captures unscripted interaction, such as a conversation or a suitably permitted real-world recording. It may better expose interruptions, overlap, and topic shifts when those matter to a dialogue or voice-agent task. Prompted dialogues can also produce overlap, so choose the method by testing actual samples rather than treating one style as the only valid source.
A brief may combine styles, for example fixed command coverage and prompted exception handling. Decide the mix after defining the target behavior and checking whether existing recordings already cover it.
How a collection project is scoped
A collection brief is a starting set of decisions written down clearly enough that a provider can plan recruitment, recording, and QA. Fill in known fields before the first scoping call, mark unknowns, and use the call to resolve feasibility and acceptance.
| Spec field | What a good answer looks like | Why it matters |
|---|---|---|
| Languages and dialects | The named language plus the specific dialect or regional variant, not just "Spanish" but "Mexican Spanish, Mexico City register" | A named variant lets a provider propose screening and annotation rules for the target market |
| Speaker demographics and count | Age bands, gender split, and accent mix, each with its own target number, not just a total headcount | Per-cell counts make the desired coverage explicit and give recruitment and evaluation a common target |
| Hours | Total hours of usable, QA-passed audio, stated separately from raw recording hours | Define whether the quote and acceptance apply to raw, accepted, or annotated hours |
| Pilot and acceptance | A representative sample, recording-level pass/fail checks, a separate task evaluation method, review ownership, and agreed rework rules | Separates delivery QA from model evaluation and makes a failed pilot actionable |
| Recording conditions and devices | The environment (quiet room, car, call center, outdoor) and the device or microphone class the deployment will actually use | A channel or environment mismatch may affect performance; compare with representative held-out audio |
| Scenario or script design | The elicitation style (scripted, prompted, spontaneous) and, if scripted, the actual script or prompt bank | The method shapes the coverage that can be planned and checked in a pilot |
| Annotation depth | Transcription only, or transcription plus speaker labels, timestamps, non-speech events, or emotion tags | Deeper annotation adds review time and cost; naming it upfront avoids a scope change mid-project |
| Delivery format | File type, sample rate, channel layout, and metadata schema, matched to the training pipeline that will consume the data | A dataset that does not match the expected format adds an integration delay after delivery |
| Licence and exclusivity | Whether the data can be resold or reused by the provider, and for how long any exclusivity period holds | Define permitted use, reuse, resale, retention, and any exclusivity period in writing |
A first enquiry can mark unknowns explicitly. The provider can then respond with feasibility assumptions, questions, pilot scope, and a comparable written quote rather than silently filling gaps.
Illustrative buyer brief and acceptance check
Example only, not a Spirelight delivery claim: A team evaluating a warehouse dispatch assistant could send the following brief to every candidate:
- Task: Recognize English dispatch commands and spoken exception reports through the headset class used in deployment; name the target markets and vocabulary in the attached task sheet.
- Coverage: State the required speaker and condition cells after checking existing licensed audio. Include scripted command coverage and prompted exception reports only where a pilot shows they are useful.
- Pilot and acceptance: Agree on recording-level checks for clipping, channel, metadata, and permissions; keep a separate, representative held-out test set for the buyer’s task metric. Set the numeric threshold and review method in the contract, not on a generic web page.
- Deliverables and rights: Specify accepted audio hours, transcript and metadata schema, permitted model-training and evaluation uses, retention, reuse or exclusivity, and what happens to failed files.
Ask each provider to mark what it can verify now, what needs a pilot, and what is outside scope. Google Cloud’s speech accuracy guidance likewise recommends evaluating representative audio recorded on the same equipment as production traffic; that principle helps make a speech-data purchase testable.
Recruiting the right speakers
Recruitment can be a major schedule constraint when a brief crosses a narrow dialect, speaker cell, location, device, or recording condition. Annotation, permissions, setup, and buyer review can also determine the critical path. Ask the provider to show the screening method, likely bottlenecks, replacement plan, and dependencies for the actual brief. Our participant recruitment guide covers the questions to put to a sourcing plan.
Keep speaker cells tied to the intended population and the model’s evaluation plan. A hypothetical brief with a narrowly defined regional dialect and several demographic cells requires different sourcing from a broad language brief, but the final quotas and feasibility need evidence from screening. Before recording, agree on the applicable lawful basis, notices, permissions, and records. Where consent is the chosen basis, obtain and document valid consent for the intended processing.
Use a pilot to confirm that recruitment, audio quality, and metadata can meet the acceptance rules before scaling. If a cell proves difficult, document the trade-off and ask the buyer to approve any changed scope.
Quality control during collection and after delivery
Define checks before recording. During a session, level and clipping checks, script or prompt review, channel checks, and a sample of takes can identify problems while a retake is still possible. The required live-review coverage depends on the project; do not assume that every take needs a human reviewer or that automated checks prove a recording usable.
Post-session QA still matters. Reviewers can correct transcripts or metadata, reject files, and sometimes request a speaker recall. Processing may help some noise problems, but it cannot reliably reconstruct speech missing from a clipped or absent signal. Agree in advance which defects permit repair, retake, replacement, or rejection, and who bears the cost.
Write a rejection loop into the acceptance plan: record the failed check, disposition, reviewer, and replacement status; count accepted hours using the contract’s definition. Keep a separate buyer acceptance sample, rather than treating the provider’s in-session pass as the final model-quality test. The speech data quality guide explains the wider checks.
Timelines, delivery, and what you own
Ask for a stage plan covering feasibility, pilot, recruitment, recording, annotation, QA, buyer review, and any rework. The longest stage varies by language and speaker availability, recording setup, label complexity, and approval cycle. A proposal should name the assumptions behind its schedule and the point at which a failed pilot changes it.
Delivery should match the written specification: accepted audio in the agreed codec and channel layout, transcripts and labels in the agreed schema, and metadata that links files to permitted speaker and recording-condition fields. Define the sample review, defect categories, acceptance period, and rework process before production starts.
Ownership and usage rights need a written licence. Specify whether the provider can retain, reuse, or resell recordings; the buyer’s permitted training and evaluation uses; any time-limited or use-limited exclusivity; and the privacy and retention obligations that apply. A custom recording is not automatically exclusive, and removing obvious identifiers does not settle all rights questions. See speech data licensing for the contract questions.
For a project-specific assessment, review Spirelight’s speech data collection service and send the brief through its quote route. A proposed scope may include recruitment, recording, transcription, and QA; feasibility, components, acceptance rules, capacity, schedule, rights, and price are confirmed in writing. Compare that proposal with existing sources against the same acceptance test.