# web audio decoding

## `decodeAudioData` costs memory by duration, not by file size

a compressed file is small; the PCM the browser produces from it is not.
stereo float32 at 44.1 kHz is about 21 MB per minute of audio, and the
decoder's working memory on top of that makes the transient several times
larger. measured in chromium, the browser process tree grows by roughly
**100 MB per minute of audio** for the duration of the decode, then frees
it: a 4-minute m4a (5.8 MB) cost about +550 MB, an hour-long one (85 MB)
about +6.9 GB. that transient, not the retained buffer, is what kills a
mobile tab.

so a waveform-from-file feature needs a cap on **duration**, read cheaply
from the container header first (an `<audio>` element's `loadedmetadata`
answered in under 80 ms for the 85 MB file), and a size cap only as a
backstop.

## decoding through a low-rate `OfflineAudioContext` shrinks what is kept, not what is spent

`new OfflineAudioContext(1, 1, 8000).decodeAudioData(buf)` returns a buffer
resampled to 8 kHz, so the retained PCM is a fraction of the full-rate
one (the same hour-long file: 220 MB kept instead of 1.2 GB). but the
browser still decodes at the file's own rate before resampling, so the
transient stays the same order (+5.5 GB vs +6.9 GB above) and the decode
takes longer (3.1 s vs 2.0 s). use it to keep long-lived buffers small;
do not use it as the reason to raise a duration cap.

the `numberOfChannels` argument to the constructor does not apply to
decoded buffers: a stereo file still decodes to two channels.

## test browsers do not share the platform's codecs

playwright's webkit build fails `decodeAudioData` on AAC with
`EncodingError: Decoding failed`, where Safari proper decodes it through
the OS. a headless measurement of AAC or ALAC handling in webkit says
nothing about Safari; only the `<audio>` metadata path behaved the same.

## sources

- plyr.fm — `frontend/src/lib/audio/probe.ts`, `peaks.ts`; measurement
  script and numbers in PR #1954 (2026-09-01)