MP3 vs WAV on a TTS API: when to request each format — Audra

The format parameter on POST /v2/speech takes exactly two values — mp3 (default, 128 kbps) and wav (lossless) — and picking wrong either bloats storage or compounds artifacts. The right choice follows one rule: pick the container for what happens to the file after the API returns it.

This post is the format decision: what each format actually is on Audra, the byte math at real script sizes, and the pipeline patterns that demand each one.

What you get in each

MP3 output is 128 kbps CBR at −16 LUFS — broadcast-ready for podcasts, YouTube, course players, and anything humans stream. WAV output is lossless PCM, typically 44.1 kHz 16-bit stereo: the editing master. Same text, same voice, same $25/1M billing either way — format does not change cost.

The byte math

At real script sizes the difference is roughly 10x. A 7,500-character narration (about 10 minutes of audio) is ~9.6 MB as MP3 and ~100 MB as WAV. A 250k-character audiobook title is ~320 MB as MP3 versus 3+ GB as WAV — per title. The size you choose multiplies across storage, egress, and backup.

curl
curl https://audratalks.com/v2/speech \
  -H "Authorization: Bearer sk-audra-..." \
  -H "Content-Type: application/json" \
  -d '{"model":"audra-essential","voice":"june","text":"Chapter one...","format":"wav"}' \
  --output chapter-01.wav

Python
import requests

resp = requests.post(
    "https://audratalks.com/v2/speech",
    headers={"Authorization": "Bearer sk-audra-..."},
    json={"model": "audra-essential", "voice": "june", "text": text, "format": "wav"},
    timeout=3600,
)
resp.raise_for_status()
open("chapter-01.wav", "wb").write(resp.content)

JavaScript
const res = await fetch("https://audratalks.com/v2/speech", {
  method: "POST",
  headers: { Authorization: "Bearer sk-audra-...", "Content-Type": "application/json" },
  body: JSON.stringify({ model: "audra-essential", voice: "june", text, format: "wav" }),
});
if (!res.ok) throw new Error(await res.text());
await writeFile("chapter-01.wav", Buffer.from(await res.arrayBuffer()));

Choose MP3 when the file ships as-is

• Podcast feeds, YouTube voiceovers, course lessons — the loudness is already right; nothing downstream needs lossless.
• Web listen-mode players — 2–4 MB per article instead of 30 MB, and browsers stream MP3 natively.
• Mobile delivery and CDN storage where every byte bills.

Choose WAV when the file gets processed again

• Editorial pipelines that cut, crossfade, or EQ before export — every lossy re-encode compounds artifacts; start lossless, encode MP3 once at the end.
• Telephony platforms transcoding to 8 kHz codecs — MP3's lossy stage plus the platform's own codec compounds badly (see the IVR post).
• Archival masters you may re-master later at different targets.

Failure mode: the double-encode

The classic mistake is requesting MP3, importing into a DAW, editing, and exporting MP3 again — two lossy generations on one voice track. The fix is structural: your pipeline stores either the shipped artifact (MP3, never touched again) or the master (WAV, re-encoded once on each publish). Never both roles in one file. One legacy note: the v1 API used response_format for this field; v2 is format — the migration guide at /migrate covers the rename.

Format defaults and SSML interaction: /docs#formats-ssml. The loudness story for show pipelines: the podcast post.