A TTS dataset supplies speech recordings and the text and speaker information needed by a text-to-speech training recipe. Choose it for your model, language and intended speaking style. Training a model, adapting a voice and supplying reference audio are different data tasks.
Start with the checkpoint and the speech your product needs to generate. This guide compares those roles, shows what to inspect in a sample and provides a fictional acceptance brief. SpeechData.ai sells conversational datasets and custom recordings; a useful selection can also be a public corpus or a decision to postpone collection.
Separate training data from reference audio
A model's advertised reference duration does not tell you how much data was used to build it. Keep these roles separate when asking for a quote.
| Data role | Question to answer | Example and boundary |
|---|---|---|
| Training corpus | What recordings will the training recipe learn from? | LJ Speech contains about 24 hours of one speaker reading books. That describes a corpus, not a universal requirement. |
| Adaptation corpus | What data will change an existing checkpoint? | The StyleTTS 2 fine-tuning example uses one hour of LJ Speech with a LibriTTS checkpoint. It does not establish a minimum for another voice or language. |
| Inference reference | What recording conditions an already trained model? | The XTTS-v2 model card advertises a six-second reference clip. This is an inference capability claim, not a training-data budget or a guaranteed result on your clip. |
LJ Speech dates to 2017 and StyleTTS 2 to 2023. These are documented reference examples, not a ranking of current systems. We have not run these recipes for this guide. Record the revision, supported languages and preprocessing of the checkpoint you actually select before transferring an example into a purchase plan.
Match the corpus to the recording task
Read speech, conversation and a chosen product voice answer different needs. LibriTTS is a 2019 resource of approximately 585 hours of read English speech at 24 kHz, with original and normalized text. Its description does not establish that it supplies the conversational delivery or language your application needs.
Conversely, conversational recordings are not automatically a finished product voice. Ask whether you need one speaker reading controlled prompts, many speakers for broader coverage, or dialogue with turn context. Compare actual recordings with the intended delivery: short confirmations, questions, long explanations or another defined use. A corpus category is a starting description, not an acceptance result.
Avoid treating TTS and ASR data as complete opposites. The original VALL-E paper from 2023 describes training on noisier speech and imperfect automatic transcripts compared with LibriTTS. That is an architecture-specific research example, not a recommendation to ignore errors. Set audio and transcript requirements for your chosen recipe and application rather than assuming one threshold works for every model.
Inspect audio and transcripts together
Request a sample with its matching text, speaker identifiers and recording metadata. Include ordinary files as well as the conditions you expect to be difficult. A polished demonstration alone does not show the distribution of a proposed delivery.
Listen for clipping, changes in room sound, overlapping speakers and processing artifacts. Check whether those conditions are allowed by your spec. Keep the original recording available when judging a processed version, and document resampling or other transformations. LJ Speech's own documentation warns about artifacts from its original MP3 recordings, despite its use as a TTS reference.
Verify what the text represents. Spoken words, a normalized rendering and a script supplied before recording are different records. For names, dates, amounts and abbreviations, check the actual pronunciation against the transcript convention and preserve any required original text. Mark rejected or uncertain items rather than silently making their labels look complete.
Delivery formats also differ. StyleTTS 2 documents a filename, transcription and speaker list. The F5-TTS training instructions currently describe a custom CSV preparer with an audio_file|text header and absolute audio paths. These are examples checked in October 2026, not interchangeable manifests or a tested import recipe for your system. Confirm the loader, channel handling, text normalization and vocabulary for the exact revision you will use.
Test the speech you want to generate
Turn a broad request such as natural speech into concrete listening questions. Does a question sound like a question in the intended setting? Are product names intelligible? Do long sentences remain complete? Ask appropriate speakers of the target language to assess the examples rather than relying on one attractive English demonstration.
Include relevant names, numbers, sentence lengths and speaking situations in your evaluation plan. Record which cases are covered and which remain untested. A phoneme count or a list of sentence types can help describe coverage, but neither alone demonstrates pronunciation, speaker similarity or useful delivery.
Separate the checks: accurate wording, intended voice, speaking style and recording defects can produce different decisions. Write down the failure and the proposed next action. An output error may lead you to inspect text preparation, checkpoint behavior or the evaluation setup before collecting more recordings. More audio is not the only available response.
Use a pilot to make a collection decision
A pilot should answer a specified question, not merely produce an impressive sample. Define the baseline, the cases to inspect and the decision that would justify another recording round. Select both representative material and known difficult cases; choose sample coverage for the decision and explain its limits instead of assuming that thirty clips or thirty minutes is adequate.
Use development material for preprocessing and model choices, and reserve separate material for final evaluation. Google's dataset-splitting guidance explains why repeated decisions on a test set weaken its role and why duplicates matter. Keep a record of which recordings and texts informed each decision.
Make the evaluation question explicit. Testing new utterances from a chosen voice is different from testing voices absent from training. For a reference-conditioned system, specify what reference audio is permitted at evaluation and keep it distinct from the target output. Report the conditions actually tested; a successful demonstration does not establish performance across all speakers, languages or styles.
A fictional acceptance brief for one product voice
Consider an imagined English booking assistant. The following is our proposed planning aid, not a completed client project, tested protocol or recommendation for a fixed recording volume.
- Goal. Evaluate a chosen voice delivering short booking questions and confirmations. Language and desired delivery are explicit; support for other languages is outside this pilot.
- Recording material. Supply sentence lists containing the product's relevant dates, names and confirmation phrases. Agree which speakers and voice samples need approval before recording.
- Delivery. Specify audio format and channels from the selected loader, speaker and session IDs, matching spoken-text conventions and any normalization fields. Count accepted audio separately from rejected files and silence.
- Checks. Review a sample spanning the planned recording conditions. Log transcript mismatches, pronunciation concerns and audible defects against agreed acceptance criteria, with a route to correction or rejection.
- Decision. Use development examples to resolve preparation issues, then assess reserved examples. Continue, revise the script or recording spec, or stop if the chosen setup does not meet the defined goal. Record the result without inventing a general quality guarantee.
This brief deliberately leaves volume and numerical acceptance thresholds to the project. Those choices need the model team's requirements and evidence from its evaluation, not a number copied from an unrelated corpus.
Review permissions for the intended use
Record the dataset release, model weights, code and intended deployment in your review. For example, the F5-TTS repository distinguishes MIT-licensed code from pretrained models licensed CC BY-NC. Check the specific release and its terms instead of treating a code license as permission for every artifact.
For custom voices, make the proposed synthesis use and handling of generated audio explicit in the recording brief and agreements. Have the appropriate legal reviewer assess the applicable rights, data handling and unresolved questions before use. This checklist does not determine a legal basis or establish that consent paperwork clears every intended deployment.
Turn the brief into a recording request
For a chosen voice or a controlled script, describe your TTS recording project. SpeechData.ai recruits native speakers, provides samples for voice approval and records sentence or prompt lists and monologues to an agreed spec. Speakers receive a briefing on the use and a project-specific contract; feasibility and pricing are assessed for the project.
If spontaneous two-person conversation is relevant to your model, inspect the catalog and request matching audio, transcripts and metadata with a company email. The catalog is conversational, rather than one chosen voice reading your script. Compare samples and permitted use against your requirements before deciding; this guide does not establish compatibility or a synthesis-quality outcome for a particular dataset.
