Audio File Size Calculator

Background.

Audio file size is one of the few things in media production you can predict exactly, provided you know which of two questions you are actually asking. Uncompressed audio and compressed audio are sized by completely different arithmetic, and mixing the two up is why estimates go wrong.

Uncompressed PCM — the WAV, AIFF and BWF files that come off a recorder or out of a DAW — stores a raw number for every sample of every channel. Its size therefore depends on three settings and nothing else: how many samples per second you capture, how many bits each sample uses, and how many channels you are recording. Microsoft's WAVEFORMATEX documentation, which defines the format chunk at the head of every WAV file, states the frame size directly: nBlockAlign is (nChannels x wBitsPerSample) / 8, the size in bytes of a single sample frame. One frame is written per sample period, so multiplying by the sample rate gives nAvgBytesPerSec, the average data transfer rate. Multiply that by the running time and you have the file, to the byte. Red Book CD parameters — 44,100 Hz, 16-bit, stereo — work out at 176,400 bytes per second, or the familiar 1,411.2 kbps.

Compressed audio works the other way round. An MP3, AAC or Opus encoder throws away information it judges inaudible and then writes out a stream at a bitrate you choose. The sample rate and bit depth of the original no longer determine the size; the bitrate does. At a constant bitrate the arithmetic collapses to one line: bitrate in kilobits per second, times 1,000, times the running time in seconds, divided by 8. This is the mode to use for a podcast episode, an audiobook chapter or any web delivery file. Apple Podcasts publishes explicit guidance here — 96 to 128 kbps for mono MP3 and 128 to 256 kbps for stereo MP3, at 44.1 or 48 kHz — and those numbers are the ones most episode-size questions actually turn on.

Both modes report the answer three ways, because storage is labelled inconsistently. NIST documents two competing definitions of the prefixes: the SI decimal convention where a megabyte is 1,000,000 bytes, used by podcast hosts, card manufacturers and most upload limits, and the IEC binary convention where a mebibyte is 2^20 = 1,048,576 bytes, which is what Windows File Explorer shows while still printing the label 'MB'. The gap is about 4.9 percent at megabyte scale — small, but enough to matter when a host imposes a hard cap. The calculator also reports minutes per gigabyte, which is usually the more useful number when you are sizing a card, a field recorder or an archive drive rather than a single file.

One caveat on precision. The byte counts here are the audio payload. A real file adds a small, format-dependent amount on top: the RIFF and fmt chunks of a WAV header, ID3 tags and album art on an MP3, or a chapter and transcript track on a podcast episode. On a 40 MB episode a few hundred kilobytes of artwork is negligible; on a ten-second sound effect an embedded 2 MB cover image is most of the file. Treat the result as the audio content, and add tags and artwork separately if they are large.

What is audio file size calculator?

An audio file's size is its data rate multiplied by its duration. What differs between formats is how that data rate is arrived at.

For linear PCM — the representation used by WAV, AIFF and BWF — the data rate is fully determined by the capture settings. Sample rate is how many amplitude measurements are taken per second per channel; bit depth is how many bits each measurement uses; channel count is how many independent signals are stored. The product of the three, divided by eight, is the byte rate. Nothing is inferred and nothing is thrown away, which is why PCM sizes are exactly predictable and why a stereo 24-bit 96 kHz session consumes 1,036.8 MB per hour.

For perceptually coded formats — MP3, AAC, Opus and their relatives — the encoder discards information it models as inaudible and emits a stream at a target bitrate. At constant bitrate the file size is that bitrate times the duration, independent of the source sample rate. Variable-bitrate encodes let the rate float around the target, so the same calculation gives an estimate rather than an exact figure, typically within a few percent for speech and music of ordinary complexity.

How to use this calculator.

1. 01Choose whether the file is uncompressed PCM (WAV, AIFF, BWF) or compressed at a fixed bitrate (MP3, AAC, Opus).
2. 02Enter the running time in minutes — 45 for a 45-minute podcast episode, 3.5 for a 3 minute 30 second song.
3. 03For PCM, pick the sample rate, bit depth and channel count you are recording at. These three settings alone determine the size.
4. 04For compressed audio, enter the encoder's bitrate in kbps. Apple Podcasts recommends 96-128 kbps mono and 128-256 kbps stereo for MP3.
5. 05Read the size in decimal MB, compare it against the binary MiB figure your operating system will show, and use minutes per gigabyte when you are sizing a card or an archive rather than a single file.

The formula.

In PCM mode the calculator first builds a sample frame. A frame holds one sample for every channel, so its size in bytes is (channels x bitDepth) / 8 — precisely the nBlockAlign field Microsoft's WAVEFORMATEX documentation says a PCM writer must set. At 16-bit stereo that is (2 x 16) / 8 = 4 bytes.

One frame is written per sample period, so multiplying the frame size by the sample rate gives the average byte rate, the nAvgBytesPerSec field: 44,100 x 4 = 176,400 bytes per second. Multiplying by eight and dividing by a thousand expresses the same thing as a data rate in kilobits per second: 44,100 x 16 x 2 / 1,000 = 1,411.2 kbps, the standard figure for CD-quality stereo.

In compressed mode there is no frame arithmetic to do because the encoder has already fixed the output rate. The byte rate is simply bitrateKbps x 1,000 / 8 — a 128 kbps stream is 16,000 bytes per second regardless of what sample rate or bit depth went in.

From there both modes converge. The byte rate multiplied by the running time in seconds gives the total byte count. That count divided by 1,000,000 gives decimal megabytes and divided by 1,048,576 gives binary mebibytes; the two differ by about 4.9 percent. Dividing 1,000,000,000 by the byte rate and then by 60 gives minutes of audio per decimal gigabyte, which is the number to use when planning storage rather than checking one file.

A worked example.

Frequently asked questions.

References& sources.

1. [1]Microsoft, WAVEFORMATEX structure (mmreg.h) — for PCM, "set nBlockAlign to (nChannels*wBitsPerSample)/8, which is the size of a single audio frame"; nAvgBytesPerSec "specifies the required average data transfer rate in bytes per second".
2. [2]Apple Podcasts, "Audio requirements" — MP3 mono at 44.1/48 kHz, 96-128 kbps; MP3 stereo at 44.1/48 kHz, 128-256 kbps; WAV and FLAC accepted at 44.1, 48, 88.2, 96, 176.4 or 192 kHz.
3. [3]National Institute of Standards and Technology, "Prefixes for binary multiples" — defines 1 MiB = 2^20 bytes against the SI 1 MB = 10^6 bytes, the source of the roughly 4.9 percent discrepancy at megabyte scale.
4. [4]YouTube Help, "Recommended upload encoding settings" — recommended audio bitrates of 128 kbps for mono, 384 kbps for stereo and 512 kbps for 5.1.