How to use quality control

Voice cloning models can occasionally hallucinate - producing audio that doesn’t match the input text, drops words, or includes leaked content from the reference clip. The Voice Cloning API includes a built-in quality control (QC) pipeline that catches these issues before returning a response.

What QC checks

When enable_qc is true (the default), every generation is verified through three checks:

ASR transcription

The generated audio is transcribed back to text using Sarvam’s ASR model.

Character error rate (CER)

The transcript is compared against the input text to compute character error rate. Generations with high CER are rejected.

Prompt-leak detection

The output is checked to ensure it doesn’t contain leaked content from the reference clip’s transcript instead of the requested text.

If a generation fails any of these checks, the API retries it with bounded attempts before returning a response.

Default behavior

QC is enabled by default. You don’t need to do anything to benefit from it:

curl -s -X POST "https://api.sarvam.ai/voices/clone" \
  -H "api-subscription-key: $SARVAM_API_KEY" \
  -F "text=Hello world" \
  -F "language_code=en-IN" \
  -F "ref_audio=@reference.wav"
  # enable_qc defaults to true

For most use cases - production traffic, customer-facing audio, or anything where output reliability matters - leave QC enabled.

When to disable QC

You can set enable_qc to false to skip the verification step:

curl -s -X POST "https://api.sarvam.ai/voices/clone" \
  -H "api-subscription-key: $SARVAM_API_KEY" \
  -F "text=Hello world" \
  -F "language_code=en-IN" \
  -F "ref_audio=@reference.wav" \
  -F "enable_qc=false"

This is appropriate when:

You need the lowest possible latency

Disabling QC removes the ASR and verification step from the response path, reducing latency. Useful for real-time applications where you can tolerate occasional bad generations and handle them downstream.

You’re running internal experiments or batch tests

For benchmarking the raw model behavior, you may want to see ungated outputs - including any failures - rather than the post-QC results.

You’re applying your own quality checks downstream

If you have a custom verification pipeline (e.g. domain-specific phoneme matching, custom acceptance criteria), you may not need the built-in QC step.

VAD trimming

Alongside QC, the API trims leading and trailing silence from the generated audio using voice activity detection. This is controlled by enable_vad and also defaults to true. Disable it only when your downstream pipeline expects untrimmed output.

What you’ll see when QC runs

QC is internal - there’s no separate field in the response indicating which generation passed which check. From the caller’s perspective, a successful response simply means a QC-passing audio file was produced.

If QC fails repeatedly and the API can’t produce a passing generation, you’ll receive a 502 or 503 error (code: model_call_error) rather than a successful response. In that case, see the Errors & Troubleshooting guide for next steps - both are safe to retry.

Best practices

Keep QC enabled in production

The latency cost is small relative to the cost of shipping malformed audio to end users. Disable QC only for specific use cases where you know what you’re doing.

Log request_id values

Every response includes a request_id. Log it alongside your generations so you can reference it when reaching out to support - especially when investigating QC-related failures.

Watch for repeated QC failures on specific text

If certain inputs reliably fail QC (e.g. text with many proper nouns, unusual transliterations, or extreme code-mixing), reformat the input or break it into shorter segments. The model handles concise, well-formed sentences most reliably.

Next steps