There is no single number of audio hours that guarantees a useful ASR model. Start with the model you can already run, measure its errors on audio that represents your product, and use a staged training experiment to decide what to collect next. A total-hour estimate becomes useful when it is tied to languages, speakers, recording conditions and a measurable acceptance criterion.
This guide gives you a way to size that experiment and turn the result into a collection brief. The workflow is planning advice. The published examples below show what particular researchers did, rather than a minimum purchase or a promised result.
What published hour counts actually tell you
| Example | What the source reports | What it means for planning |
|---|---|---|
| Hugging Face's Whisper fine-tuning tutorial | Whisper small fine-tuned on about eight hours of Hindi Common Voice 11 training audio, with a separate test split | A specific adaptation experiment you can inspect and reproduce; it does not establish a requirement for your product |
| LibriSpeech's training splits | 100, 360 and 500 hours of read English speech, totaling 960 training hours | A named research corpus with a particular language and speaking style; its size is not a conversational-ASR requirement |
| The original Whisper paper | 680,000 hours of multilingual, multitask training data | A large pretraining setup; do not use that number to price a domain-adaptation project |
These examples answer different questions. Record the model, dataset, split and evaluation conditions whenever you use a published result in a budget discussion. A number without that context is a weak basis for a collection order.
Define the result before estimating the hours
Write down what the recognizer must do. “Better English transcription” leaves too much unresolved. “Transcribe customer-support calls in the accents and telephone conditions our product receives” gives you a starting scope.
Make the acceptance criteria equally specific. You might track overall word error rate alongside errors in product names, numbers or negations, and results for each important accent or recording channel. Choose thresholds with the people who will use the output. This article cannot set a safe production threshold for your application.
Our ASR test-set guide covers evaluation design. For sizing a collection, keep a final test set separate from training and model selection. Use a development set for repeated decisions, and decide in advance when the final test will be opened. Google's guidance on training, validation and test sets explains how repeated decisions against the same test data can undermine that check. For an unseen-speaker evaluation, keep a speaker's recordings in one split and check for duplicate recordings across splits.
Before any collection, confirm that you have permission to record, annotate and use the audio for the intended purpose. Include the required rights and handling rules in the brief, alongside the technical requirements.
Measure the starting model and classify the errors
Run a baseline on representative audio before choosing a training volume. Keep the checkpoint, decoding settings, text-normalization rules and scoring method in the experiment record. Save results for meaningful groups as well as the overall average.
Read a sample of the errors. Use the following table as a diagnostic checklist, not as a claim that any one remedy will work:
| Observed problem | Question to investigate before collecting more |
|---|---|
| Product names are repeatedly wrong | Can vocabulary handling or decoding address the issue, and which terms still need recorded examples? |
| One accent performs poorly | Is that accent represented in the training and evaluation audio, across different speakers? |
| Telephone calls fail while clean recordings work | Does the training audio match the actual channel and recording conditions? |
| Overlapping conversation is missing | Does the training task include the same speaking style and transcription convention? |
| Scores change after transcript formatting changes | Are reference and prediction normalization rules consistent? |
The output should be a short list of observed gaps. That list is more actionable for a collection provider than a request for an arbitrary number of hours. The ASR training-data checklist gives a broader specification for audio, transcripts, metadata and delivery checks.
Build a pilot that can answer a decision
Choose a pilot scope that lets your team test its main hypothesis within the available annotation, training and evaluation budget. Specify what counts as usable audio: recorded duration, speech-only duration or accepted, transcribed segments. Keep those quantities separate in the delivery manifest.
Agree the language and accent mix, speaker criteria, devices, environments and speaking style before recruitment begins. Also agree the transcript convention, metadata fields and checks for rejected recordings. Total hours alone do not tell you whether a delivery covers the conditions you identified.
For the training experiment, compare nested subsets where practical: each larger subset contains the smaller one. Keep the evaluation set and scoring rules fixed, and record other changes to the training setup. If compute permits repeated runs, record the variation rather than presenting a single run as a certain outcome.
Hypothetical example: sizing a support-call pilot
Suppose a team is adapting an existing model for two accents on one telephone channel. It chooses 10, 25 and 50 accepted training hours as experiment checkpoints. Those numbers are invented for this example, not recommended minimums or measured SpeechData.ai results.
| Checkpoint | What the team records | Decision it prepares |
|---|---|---|
| Baseline, before fine-tuning | Overall score, each accent's score and recurring error categories | Which gaps the pilot must address |
| 10 accepted training hours | The same scores, speaker coverage and transcript checks | Whether the collection and training process are working |
| 25 accepted training hours | Change from the earlier checkpoint, with other settings recorded | Whether additional coverage is helping the target errors |
| 50 accepted training hours | Remaining gaps and whether acceptance criteria are met | Whether to stop, change the mix or scope another experiment |
The team fills in actual results after running the experiments. It does not infer that 50 hours is sufficient because it appears in a table. If one accent has little evaluation coverage, it records that limitation before interpreting the average.
Decide whether to scale, change direction or stop
Plot your own measured results against accepted training hours. Review group-level results and error examples alongside the curve. Do not fit a purchasing forecast to a single before-and-after result.
If the target errors improve and important groups still have gaps, specify the next collection around those gaps. If results remain flat, inspect label consistency, data coverage and training settings before assuming the answer is more audio. If performance worsens on an existing use case, include that regression in the decision.
Stop when the agreed acceptance criteria are met and the remaining risks have been assessed for the application. If they are not met, explain what the next experiment will test. A clear stop or change criterion helps keep a staged project tied to evidence.
Turn the pilot into a collection brief
Use this outline when asking for a custom-project quote. Mark uncertain fields as questions rather than filling them with guesses.
- Application and baseline: what the product transcribes, the starting model and the errors observed.
- Language coverage: languages, regions or accents, plus any code-switching requirement.
- Recording conditions: channel, devices, environments and expected noise or overlap.
- Speech and speakers: conversation, read prompts or commands; recruitment criteria and coverage priorities.
- Accepted volume: the proposed pilot scope, how duration is counted and what gets rejected.
- Annotation: transcript conventions, timestamps, metadata and review criteria.
- Evaluation and rights: held-out evaluation plan, acceptance criteria and required permissions and documentation.
You can also use the speech-data RFP template when the procurement process needs a fuller specification. Check an existing corpus against the same brief before commissioning new recordings; a catalog may cover part of the requirement, while a custom collection addresses conditions it does not cover.
If you need recordings made to your specification, send your collection brief for a project quote. Include the target languages, recording conditions and the gap you are trying to close. If the hour requirement is still unknown, say so and describe the pilot decision you need to make.
