Why uncompressed audio size is exactly predictable
Linear PCM stores every sample as a fixed-width number, whatever that sample contains. Silence costs the same as a full-scale drum hit, and a 24-bit sample takes three bytes whether it encodes a whisper or a snare. That makes the file size a pure product: samples per second, times bytes per sample, times channels, times seconds. Nothing about the material changes the answer.
That predictability is the whole point of the format. A recorder can guarantee it will not run out of card halfway through a take, and a session can be budgeted before it starts. It is also why lossless compression is a separate question: FLAC and ALAC store exactly the same samples in fewer bytes by modelling the waveform, but how many fewer depends on the music - dense loud material compresses to perhaps 70% of PCM, sparse quiet material to 40% - so their size cannot be calculated in advance.
Lossy formats are different again. MP3, AAC and Opus discard information and are usually specified by bitrate, which makes their size calculable but their quality material-dependent. At a constant bitrate the size is bitrate divided by eight, times the length, and the channel count and sample rate do not appear at all - a 320 kbps stereo file and a 320 kbps mono file are the same size, which is exactly why encoding mono material in stereo wastes half the bitrate.
Reading each factor in the product
Sample rate is samples per second per channel. It is set by the bandwidth you need: the Nyquist theorem puts the highest recordable frequency at half the sample rate, so 44.1 kHz reaches 22.05 kHz and 48 kHz reaches 24 kHz. Doubling the rate doubles the file. The 44.1 kHz figure is a legacy of early digital recorders that stored data on video tape; 48 kHz became standard for anything cut against picture, and its multiples follow the same family.
Bit depth is bits per sample, and it sets dynamic range rather than bandwidth - about 6.02 dB per bit, so 16-bit gives roughly 96 dB and 24-bit roughly 144 dB. Divide by eight for bytes: 16-bit is two bytes, 24-bit is three, 32-bit is four. Going from 16- to 24-bit costs exactly 50% more storage, and going to 32-bit costs 100% more than 16-bit.
Channels multiply directly. A stereo file is twice a mono file; a 5.1 file is six times. Note the distinction the calculator draws between channels inside one file and the number of files: a 24-track session of mono files and a session of twelve stereo files hold identical data and occupy identical space.
Length multiplies directly too, which makes the data rate the number worth memorising. At 48 kHz / 24-bit / mono it is 144 kB per second, which is 8.64 MB per minute and 518.4 MB per hour. Every other format scales from there by the ratios above. If you also need to move those files across a network, the data transfer time calculator converts the total into transfer time.
Worked example: a 24-track session at 48 kHz / 24-bit
You are tracking a band: 24 mono tracks at 48 kHz and 24-bit, recording for three hours of session time, onto a drive with 500 GB free.
- Bytes per sample. 24 bits / 8 = 3 bytes.
- Data rate per track. 48,000 samples/s x 3 bytes x 1 channel = 144,000 bytes per second, or 144 kB/s.
- One track for three hours. 3 hours = 10,800 s, so 144,000 x 10,800 = 1,555,200,000 bytes = 1,555.2 MB = 1.5552 GB.
- All 24 tracks. 1.5552 x 24 = 37.3248 GB.
- Against the drive. 500 GB free minus 37.32 GB leaves 462.7 GB, so it fits comfortably. Divide the other way for the ceiling: 500,000,000,000 / (144,000 x 24) = 144,676 s = 40.19 hours of 24-track recording.
- Check the WAV ceiling. A single mono track at 144 kB/s reaches 4 GiB (4,294,967,296 bytes) after 4,294,967,296 / 144,000 = 29,826 s = 8.3 hours. A three-hour take is safe; an all-day continuous recording is not, and would need RF64.
- Compare with a 320 kbps stereo bounce. 320,000 / 8 = 40,000 bytes/s, so three hours is 40,000 x 10,800 = 432 MB. The stereo PCM master of the same length would be 288,000 x 10,800 = 3,110.4 MB, so the encode is 3,110.4 / 432 = 7.2 times smaller.
Sanity-check step 4 the other way: 37.3248 GB over three hours is 12.4416 GB per hour, and 12.4416 GB / 24 tracks = 0.5184 GB per track per hour, which is the 518.4 MB figure quoted above. The two routes agree.
Choosing a format from the size figure
Storage is rarely the binding constraint any more, but throughput and workflow often are. A 96 kHz session at 24-bit across 32 tracks demands 32 x 288 kB/s = 9.2 MB/s of sustained write, which any modern SSD handles and a slow USB bus over a shared connection may not. Playback with plugin processing adds read demand on top. When a session drops out at high track counts, sustained disk throughput is usually the cause, and halving the sample rate halves the demand.
The recording-time figure is the one to check before a long-form job. A field recorder with a 128 GB card running eight channels at 48 kHz / 24-bit consumes 8 x 144 kB/s = 1.152 MB/s, so the card lasts 128,000,000,000 / 1,152,000 = 111,111 s = 30.9 hours. That is a reassuring number for a documentary shoot and a tight one for a multi-day conference.
On format choice, the honest summary is that bit depth buys headroom and sample rate buys bandwidth, and only one of those is usually in short supply. Recording at 24-bit rather than 16-bit costs 50% more storage and removes any need to ride the gain close to full scale, which is a clear win. Recording at 96 kHz rather than 48 kHz doubles the storage and the CPU load for an extra octave above 24 kHz; whether that is worth it is a longstanding argument, and the storage figure is the least of the considerations either way.
For delivery, remember that the compressed size depends only on bitrate and length. A three-minute track at 256 kbps is 256,000 / 8 x 180 = 5.76 MB whether it is mono, stereo, 44.1 kHz or 48 kHz. If you are trying to hit a size budget, the bitrate is the only lever.
Storage for one hour of audio
| Format | Data rate (kB/s) | One minute (MB) | One hour (GB) |
|---|---|---|---|
| 22.05 kHz / 16-bit / mono | 44.10 | 2.65 | 0.159 |
| 44.1 kHz / 16-bit / stereo (CD) | 176.40 | 10.58 | 0.635 |
| 48 kHz / 24-bit / mono | 144.00 | 8.64 | 0.518 |
| 48 kHz / 24-bit / stereo | 288.00 | 17.28 | 1.037 |
| 96 kHz / 24-bit / stereo | 576.00 | 34.56 | 2.074 |
| 96 kHz / 32-bit / stereo | 768.00 | 46.08 | 2.765 |
| 192 kHz / 24-bit / stereo | 1152.00 | 69.12 | 4.147 |
| 48 kHz / 24-bit / 5.1 | 864.00 | 51.84 | 3.110 |
| MP3 / AAC at 320 kbps | 40.00 | 2.40 | 0.144 |
| Opus at 96 kbps | 12.00 | 0.72 | 0.043 |
The two compressed rows depend only on the bitrate, not on the sample rate or channel count. Every uncompressed row is the product in the formula above, so any format not listed can be scaled from a neighbour: doubling the sample rate, the channel count or the bytes per sample doubles the figure.
What the calculation leaves out
- File headers and metadata. A WAV header is about 44 bytes, and broadcast metadata or embedded markers add a little more. Both are negligible against any recording longer than a second.
- Lossless codecs. FLAC, ALAC and WavPack store the same samples in fewer bytes, but by how many depends on the material, so their size cannot be predicted from the format alone.
- Variable bitrate encoding. A VBR MP3 or AAC file averages the target bitrate rather than holding it, so the calculated size is an estimate rather than an exact figure.
- Project overhead. A DAW session also holds undo history, fade files, peak files and clip copies, which can add a large fraction on top of the raw audio.
- Decimal against binary units. Drives are sold in decimal gigabytes and most operating systems report binary gibibytes, a 7.4% difference at the GB/GiB level that grows to 10% at TB/TiB.
- Filesystem limits. The 4 GiB ceiling applies to the WAV container and also to FAT32 volumes, independently. RF64, Wave64 and CAF all lift the container limit; the volume limit needs exFAT or better.
Containers, ceilings and what to record to
WAV is a RIFF container, and RIFF stores chunk sizes in 32-bit fields. That caps a compliant WAV file at 4 GiB - 4,294,967,296 bytes - which at 48 kHz / 24-bit stereo arrives after about 4 hours 8 minutes, and at 192 kHz / 24-bit stereo after about an hour. Recorders handle this in different ways: some split automatically into numbered files, some stop, and some write a non-compliant file that other software refuses to open. EBU Tech 3306 defines RF64, which stays byte-compatible with WAV up to the limit and then carries 64-bit sizes beyond it; Sony's Wave64 and Apple's CAF solve the same problem differently. If a job involves continuous recording of many hours, check what your recorder does before the day rather than after.
Broadcast Wave, defined in EBU Tech 3285, is WAV with a metadata chunk carrying originator, date and - critically - a timecode reference, which is what lets a separately recorded sound file line up against picture. It costs a few hundred bytes and is the format to use for anything that will meet video.
On the sample-rate side, the multiples exist because rate conversion between families is arithmetically awkward. Converting 44.1 kHz to 48 kHz is a ratio of 147:160 and requires a proper resampler; converting 96 kHz to 48 kHz is simply 2:1 and much cleaner. If a project's deliverable is 48 kHz, record at 48 or 96 rather than at 88.2, and if it is a CD master at 44.1, record at 44.1 or 88.2.
Finally, storage planning is only half of session planning. The runtime you are recording usually comes out of an arrangement measured in bars, and the song length and bar count calculator converts between the two. When the files have to move rather than merely sit, the data transfer time calculator turns gigabytes into minutes on a given link.