> For clean Markdown of any page, append `.md` to the page URL.
> For a complete documentation index, see https://docs.sarvam.ai/llms.txt.
> For full documentation content in one file, see https://docs.sarvam.ai/llms-full.txt.
> For AI client integration (Claude Code, Cursor, etc.), connect to the MCP server at https://docs.sarvam.ai/_mcp/server.

# How to use quality control

> The built-in quality control (QC) pipeline of the Sarvam AI Voice Cloning API: ASR verification, character error rate scoring, and prompt-leak detection. What QC checks, when to disable it, and what you'll see.

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

QC is **off by default**. Set `enable_qc=true` to enable it; the generation is then 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. A high CER is flagged, but does not by itself cause the generation to be replaced.

#### 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.

Of these, only a detected prompt leak causes the audio to be regenerated, using a different reference, with bounded attempts. The other checks are advisory.

> **Note**
>
> QC applies to single-chunk generations. Text longer than a sentence or two is split into sentence chunks and synthesized in parallel; chunked generations run without the QC pipeline. If output verification matters for long text, verify the returned audio on your side.

## Default behavior

QC is off by default, so a plain request returns as soon as the audio is generated:

```bash
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 false
```

## Enabling QC

Set `enable_qc` to `true` to run the verification step:

```bash
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=true"
```

> **Warning**
>
> **QC adds latency, and how much depends on your text.** It adds roughly half a second for text in a single script. For code-mixed text - Hindi with English words, for example - it adds several seconds, because reconciling the transcript against mixed-script input needs an extra normalization step. Code-mixed input is fully supported either way; it is simply the case where QC costs the most.

Enabling it is appropriate when:

#### Output reliability matters more than latency

Customer-facing audio you will not listen to before it ships, where a rare malformed generation is worse than a slower response.

## When to leave QC off

The default is appropriate when:

#### You need the lowest possible latency

Skipping QC keeps the ASR and verification step out of the response path. This matters most for interactive and real-time use, and for code-mixed text.

#### 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 is enabled 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](/api/getting-started/errors-troubleshooting) guide for next steps - both are safe to retry.

## Best practices

#### Decide QC per use case, not globally

Enable it where a bad generation reaches an end user unreviewed. Leave it off for interactive paths, for code-mixed text, and anywhere you already verify output downstream.

#### 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

#### [Prepare Reference Audio](/api/api-guides-tutorials/voice-cloning/how-to/prepare-reference-audio)

Reference clip guidelines - the other half of output quality.

#### [FAQs](/api/api-guides-tutorials/voice-cloning/faq)

Quick answers on limits, voices, and errors.