# Audio Formats

All speech-to-text endpoints accept audio in two ways: a container format that the server detects automatically, or raw audio described explicitly with the `encoding`, `sample_rate`, and `channels` query parameters.

## Automatic Detection

With the default `encoding=auto`, the server detects the audio format by reading the container headers at the start of the data. Most common formats (WAV, M4A, MP3, OGG, FLAC, WebM, etc.) are supported.

On the [Prerecorded](/speech-to-text/prerecorded/) endpoint, you can also set a seekable media container explicitly: `m4a`, `m4v`, `mp4`, `mov`, `3gp`, or `3g2`.

## Raw Audio

If you are sending raw audio without container headers, set the `encoding` parameter explicitly along with `sample_rate` and `channels`:

| Encoding    | Description                    |
|-------------|--------------------------------|
| `pcm_s16le` | Raw PCM, 16-bit little-endian  |
| `mulaw`     | G.711 mu-law telephony audio   |
| `alaw`      | G.711 A-law telephony audio    |

## Streaming Containers

When streaming to the [Realtime](/speech-to-text/realtime/) or [Turns](/speech-to-text/turns/) endpoint, you can use a container with an indefinite length (e.g. a WAV header with the data size set to the maximum value) and continuously append audio frames.

:::tip[Recommended streaming setup]
If you control the capture pipeline, send raw PCM at 16 kHz mono: `encoding=pcm_s16le&sample_rate=16000&channels=1`. There are no container headers to lose, so the reconnecting caveat below does not apply.
:::

:::caution[Reconnecting mid-stream]
If you reconnect to the WebSocket and resume sending audio, the server will not be able to detect the format because the container headers are missing. Each new connection must start with a fresh audio stream that includes the headers. Alternatively, set the `encoding` parameter explicitly to bypass format detection entirely.
:::