16 kHz mono wav vs 128 kbps mp3: audio detach sizes for 15 minutes

The longest audio-detach output is 900 seconds. As a 16 kHz mono 16-bit wav that is 32,000 bytes per second x 900 = 28.8 MB; as the 128 kbps mp3, 16,000 bytes per second x 900 = 14.4 MB. The docs call sample_rate: 16000 plus channels: "mono" the speech-to-text shape.

Sizes

These are nominal sizes computed from the sample format and bitrate, 1 MB = 1,000,000 bytes. Real files add a small header, and mp3 adds priming padding.

Which one

Keep wav when the file will be joined again or drives lip-sync, because it is sample-exact and mp3 adds padding at every edge. Use mp3 for delivery to a podcast host or an email. For speech-to-text, 16 kHz mono wav is the format the docs name.

curl -X POST https://api.sume.com/v1/audio-detach \
  -H "Authorization: Bearer $SUME_API_KEY" \
  -H "Content-Type: application/json" \
  -H "Idempotency-Key: detach-stt-001" \
  -d '{"video_url":"https://media.sume.com/artifacts/artf_demo/talk.mp4","format":"wav","channels":"mono","sample_rate":16000,"range":{"start":0,"end":900}}'

Cost

Detach is $0.01 per job whatever the size. Transcribing 15 minutes afterwards at Sume's STT rate of $0.01 per audio minute is 15 x $0.01 = $0.15, so the pair is $0.16. A source of up to 1,800 s can be handled in two ranges: 2 x $0.01 = $0.02.

Refusals

• audio_detach_range_empty: end not after start, or range over 900 s.
• detach_source_has_no_audio: check probe.has_audio first.
• source_duration_exceeded: source over 1,800 s.

Reading the numbers

These are estimates, not promises: the docs state the formats, not file sizes. Use the table to decide storage and upload limits for the next tool. If you ship the audio to a service with a file-size cap, a 15 minute mono 16 kHz wav at about 28.8 MB can pass where a stereo 44.1 kHz wav at about 158.76 MB cannot. Always check the artifact's reported duration, since a range past the end of the source is clamped by the probe. Every media job follows the same lifecycle: submit with an Idempotency-Key, receive a job, poll GET /v1/jobs/:id/status until it is ready, then read GET /v1/jobs/:id/result. A retry with the same key does not queue a second job, so a network error during submit never doubles a charge.