What WavRead needs, what it runs well on, and where its ceiling actually is. Every number here was measured on a real machine rather than estimated — how, and on what, is at the bottom of the page.
| Mac | Apple Silicon — M1 or later. WavRead ships as an arm64 binary only, so Intel Macs cannot run it, with or without Rosetta. |
|---|---|
| macOS | macOS 14 Sonoma or later. That floor comes from the Python runtime and the audio libraries built into the app; on macOS 13 or earlier it will not launch. |
| Memory | 8 GB. Enough for songs of ordinary length — see the ceiling below, because memory is what actually limits WavRead, and it grows with the length of the track. |
| Disk | 2 GB free to install and work in. The app is 626 MB installed, from a 236 MB download. |
| Network | None. Analysis never needs it. The only requests WavRead ever makes are the once-a-day update check you can turn off, and a one-time 80 MB model download if you use built-in stem separation. |
| Memory | 16 GB or more. It buys you long tracks and lets separation run without the machine paging. |
|---|---|
| Disk | An SSD with room to spare. Separated stems are about 135 MB per song, and captures from a DAW run to roughly 1 GB per plugin instance per hour. WavRead lets you put the library on any drive, which is what external drives are for. |
| CPU | Any Apple Silicon chip is fast enough. Separation is the only heavy step and it uses the GPU (Metal) when one is available, falling back to the CPU when it is not. |
| For DAW capture | A host that loads AU or VST3 plugins. The plugin itself is close to free — measured here — but plan for the disk. |
One real 3-minute song, and the same song repeated to nearly 13 minutes, on the machine described at the bottom:
| What was run | Track length | Time | Peak memory | Written to disk |
|---|---|---|---|---|
| Analysis only | 3:12 | 12.7 s | 3.6 GB | 133 KB |
| Full run — separation, lyrics, melody | 3:12 | 70.8 s | 4.0 GB | 136 MB |
| Analysis only | 12:48 | 51.9 s | 6.8 GB | 133 KB |
Analysis is roughly four times faster than realtime; a full run with separation is about three times faster than realtime. Both are one-off costs — the documents are written once and read from disk after that.
WavRead holds the whole track in memory to measure it, so peak memory grows with length — measured at about 0.33 GB per additional minute of audio, on top of a 2.5 GB base.
| Track length | Expected peak memory | Comfortable on |
|---|---|---|
| 3 minutes | ~3.5 GB measured | 8 GB |
| 5 minutes | ~4.2 GB | 8 GB |
| 10 minutes | ~5.9 GB | 16 GB |
| 13 minutes | ~6.8 GB measured | 16 GB |
| 30 minutes | ~12 GB (extrapolated) | 16 GB or more |
The 3- and 13-minute rows were measured; the rest follow the straight line between them and are marked as such. macOS will page to disk rather than fail outright, so an 8 GB Mac given a 30-minute file gets slow, not broken — but a DJ set or a podcast episode is the case to watch.
| Sample rates | 44.1, 48, 96 and 192 kHz all tested and analysed correctly. True-peak oversampling adapts to the rate rather than assuming 48 kHz. |
|---|---|
| Bit depth | 16- and 24-bit PCM, and 32-bit float. |
| Channels | Mono, stereo, and more — a 6-channel file analyses fine. Peak and clipping are measured on the real channels, never on a mono fold-down. |
| File formats | WAV, MP3, AIFF, FLAC, M4A, OGG. |
| Track length | No hard limit. Memory is the practical ceiling — see the table above. |
| Short files | Down to half a second. Measurements needing a longer window are reported as unavailable rather than guessed. |
| Stems per song | No fixed cap. 32 simultaneous capture instances were measured without dropping audio, and wide tables scroll rather than overflow. |
Analysis runs entirely offline. Nothing is uploaded, ever.
There is no sign-in, no licence server, and no telemetry.
Separation uses Apple's Metal GPU when present and the CPU when not.
Drag it to Applications. The app is unsigned, so on first launch right-click it and choose Open.
How these were measured: on an Apple M4 with 24 GB of memory
running macOS 26.5, using WavRead 1.4.4. Time and peak memory come from
/usr/bin/time -l around a real analysis; disk figures are the bytes
actually written. The macOS floor was read from the load commands of all 380
binaries inside the app bundle, taking the highest. Your own times will differ
with your chip and what else is running — the shape of the numbers is what
matters, not the last digit.