Skip to content
OneKitly

How Big Is That Audio File?

Published 8/22/2025 · 15 min read · Developer tools

Daniel Okonkwo

Daniel OkonkwoFront-end developer and tech writer at OneKitly

Web performance · File formats

Checked against 6 sources

View profile
In short

For uncompressed PCM the size is exact and there is nothing to estimate: bytes = sample rate × bit depth × channels × seconds ÷ 8. CD audio is 44,100 × 16 × 2 ÷ 8 = 176,400 bytes per second, so a minute is 10,584,000 bytes — 10.58 MB, or 10.09 MiB if your file manager counts in binary units. A 48 kHz, 24-bit stereo master is 288,000 bytes per second; a 96 kHz, 24-bit eight-track session is 2,304,000 bytes per second, which is 138.24 MB a minute and 8.29 GB an hour. Lossy formats work completely differently. A 320 kbps MP3 is defined by its bitrate, so its size is bitrate × duration: 40,000 bytes per second, 2.4 MB a minute, regardless of whether the source was 44.1 or 48 kHz. The sample rate simply does not enter the calculation. Variable bitrate makes even that approximate, because the encoder spends bits where the music needs them and the quoted figure is only an average. The two models cross at the source bitrate: CD audio is 1411.2 kbps, so any lossy file encoded above that is larger than the lossless original it came from.

Uncompressed audio size is exact arithmetic: sample rate × bit depth × channels × seconds ÷ 8. CD audio is 176,400 bytes per second. A 320 kbps MP3, by contrast, is bitrate × duration and does not depend on the sample rate at all — 2,400,000 bytes a minute whether it came from 44.1 or 48 kHz.

The formula, and why it is exact

Uncompressed audio is a list of numbers, and the size of a list of numbers is not something you estimate. The recorder takes a sample of the waveform at fixed intervals; each sample is stored in a fixed number of bits; each channel gets its own stream. Multiply and divide by eight to reach bytes: size = sample rate × bit depth × channels × seconds ÷ 8. There is no compression, no header worth counting and no dependence on the content. Silence and a full orchestra occupy exactly the same space.

Work the canonical case. CD audio is 44,100 samples per second, 16 bits per sample, two channels. That is 44,100 × 16 × 2 = 1,411,200 bits per second, which divided by 8 is 176,400 bytes per second. A minute is 176,400 × 60 = 10,584,000 bytes. An hour is 635 million bytes. A full 74-minute disc, the original Red Book capacity, holds 783,216,000 bytes of audio; an 80-minute disc holds 846,720,000.

One thing routinely trips people up here, and it is not audio at all: the difference between MB and MiB. A minute of CD audio is 10,584,000 bytes, which is 10.58 megabytes if a megabyte means a million bytes, and 10.09 mebibytes if it means 1,048,576. Storage vendors and most calculators use the decimal sense; several file managers report the binary one under the label MB. When a calculator and a file listing disagree by about five percent, that is almost always what has happened, and neither of them is wrong.

Why 44.1 kHz exists

The rate looks arbitrary and is not. Two separate constraints produced it. The first is sampling theory: to reconstruct a signal you must sample above twice its highest frequency, so capturing hearing up to 20 kHz needs more than 40,000 samples per second. Anything above 40 kHz satisfies the theorem, and the margin matters because a real anti-aliasing filter cannot cut off instantly. At 44,100 the filter has 44,100 ÷ 2 − 20,000 = 2,050 Hz of transition band to roll off in, which was demanding but buildable with the analogue filters of the late 1970s.

The second constraint decided the exact figure, and it came from video. Before dedicated digital audio recorders existed, the cheapest way to store and ship a digital master was to encode the samples as a pseudo-video signal and record them on a video tape recorder, using a device called a PCM adaptor. The adaptor packed three samples per channel into each horizontal line of the picture. From there the arithmetic is forced: on 525-line, 60-field geometry with 245 usable lines per field, 3 × 245 × 60 = 44,100 exactly. On 625-line, 50-field geometry with 294 usable lines, 3 × 294 × 50 = 44,100 exactly as well.

That coincidence is the whole answer. 44,100 is the one value above the Nyquist floor that falls out cleanly on both television systems, so a master cut on either kind of machine carried the same rate. The colour version of the 525-line system complicates it in a way worth knowing: its field rate is not 60 but 60,000 ÷ 1,001, and 3 × 245 × that comes to 44,055.944 Hz. Early Sony PCM adaptors really did run at that rate, usually quoted as 44,056 Hz, and tapes exist at both. When the Compact Disc specification was written the round number won, and 44,100 has outlived the video machines that produced it by decades.

48 kHz exists for a different reason: it is a professional rate chosen to divide neatly against film and video frame rates, which is why every camera, every editing timeline and every broadcast chain runs at 48 kHz while music distribution still runs at 44.1. Neither is better; they are answers to different scheduling problems.

What bit depth buys, derived

Bit depth does not affect frequency response at all; it sets the noise floor. Every sample is rounded to the nearest representable level, and the rounding error behaves like added noise. If the step between levels is D, that error is spread roughly uniformly over the interval from −D/2 to +D/2, and the mean square of a uniform distribution over that interval is D² ÷ 12. That is the noise power, and it depends only on the step size.

Now the signal. With n bits there are 2 to the n levels, so a sine wave using the full scale has a peak amplitude of 2 to the n times D, divided by 2. The average power of a sine is half the square of its peak, giving (2 to the n × D)² ÷ 8. Divide signal power by noise power and the step size cancels: [(2 to the n × D)² ÷ 8] ÷ [D² ÷ 12] = 12 × 2 to the 2n, over 8, which is 1.5 × 2 to the 2n.

Convert to decibels and the famous constants appear. Ten times the base-10 logarithm of 1.5 × 2 to the 2n equals 10 log 1.5 plus 2n × 10 log 2, and 10 log 1.5 = 1.7609 while 20 log 2 = 6.0206. So the dynamic range is 6.0206 n + 1.7609 dB — the identity usually quoted as 6.02 × bits + 1.76. Evaluating it: 8 bits give 49.93 dB, 16 bits give 98.09 dB, 20 bits give 122.17 dB, 24 bits give 146.26 dB and 32 bits give 194.42 dB. Computing the ratio directly at each depth returns the identical figures to two decimal places, which is the check that the derivation is right rather than remembered.

One honest caveat: 24-bit converters do not deliver 146 dB. Thermal noise in the analogue front end puts a floor around 120 to 125 dB on the best of them, so the extra bits buy headroom during recording — room to set levels conservatively and normalise later — rather than audible resolution. That is a real benefit while tracking and a largely theoretical one at the delivery stage, which is why masters are cut at 24 bits and released at 16.

A 320 kbps MP3 does not care about your sample rate

This is the point where intuition built on PCM stops working. A lossy file is not a list of samples; it is a stream of encoded frames, and the encoder is told how many bits per second it may spend. Size follows directly from that instruction: bytes = bitrate × seconds ÷ 8. At 320 kbps that is 40,000 bytes per second, so a minute is 2,400,000 bytes and a three-and-a-half-minute track is 8.40 MB. At 128 kbps a minute is 960,000 bytes and the same track is 3.36 MB.

Notice what is absent from that formula: the sample rate, the bit depth and the channel count. Encode the same three-minute piece from a 44.1 kHz source and from a 48 kHz source, both at 320 kbps, and the two files come out the same size — 2,400,000 bytes per minute either way. The sample rate still determines what the encoder can represent, so it affects quality, but it has no bearing at all on how much space the result occupies. The same is true of stereo versus mono: at a fixed bitrate, mono does not halve the file, it simply gives the encoder twice as many bits to spend on one channel.

Variable bitrate loosens even this. Under VBR the encoder targets a quality level rather than a rate, spending more bits on dense passages and fewer on sparse ones, and the number reported afterwards is the average over the whole file. A track quoted at 245 kbps VBR might have run at 320 during the choruses and 160 during a solo piano introduction. Multiplying that average by the duration gives a good estimate and not an exact size, which is the practical difference between VBR and CBR from a storage-planning point of view.

Where lossy stops saving anything

Because the two size models are different functions, they cross. The crossing point is the bitrate of the source, and it is easy to compute: multiply sample rate by bit depth by channels. CD audio is 44,100 × 16 × 2 = 1,411,200 bits per second, or 1411.2 kbps. A 48 kHz, 24-bit stereo file is 2304 kbps. A 96 kHz, 24-bit stereo file is 4608 kbps, and eight tracks of it is 18,432 kbps.

Encode above that figure and the lossy file is bigger than the lossless original it came from — a perfectly possible and completely pointless thing to do, since you have paid for extra storage in exchange for information that was thrown away. Nobody sets out to do it deliberately, but it happens by accident in transcoding pipelines with a fixed high bitrate applied to sources of different depths, and it happens routinely when someone re-encodes speech recorded at 8 kHz mono, whose lossless bitrate is only 64 kbps.

In between sits lossless compression. FLAC, ALAC and their relatives reconstruct the original samples bit for bit, so the quality question does not arise, and they typically land somewhere around 55 to 70 percent of the PCM size on ordinary music — roughly 780 to 990 kbps from a CD source, though quiet or sparse material compresses much further and loud, dense material barely at all. Unlike PCM, the size depends on the content, so it cannot be computed in advance; unlike lossy, it cannot be chosen. That is the practical taxonomy: PCM size is exact arithmetic, lossy size is a decision, lossless size is a measurement.

One minute
Uncompressed and lossy sizes, computed from rate × depth × channels ÷ 8 and from bitrate × duration
FormatBitrateBytes per secondOne minuteOne hour
44.1 kHz / 16-bit / stereo (CD)1411.2 kbps176,40010.58 MB0.635 GB
48 kHz / 24-bit / stereo2304 kbps288,00017.28 MB1.037 GB
96 kHz / 24-bit / stereo4608 kbps576,00034.56 MB2.074 GB
96 kHz / 24-bit / 8 tracks18,432 kbps2,304,000138.24 MB8.294 GB
MP3 / AAC at 320 kbps320 kbps40,0002.40 MB144.0 MB
MP3 / AAC at 128 kbps128 kbps16,0000.96 MB57.6 MB

Worked with our own calculator

Audio file size calculator

Given

Duration (minutes)
6
Sample rate (kHz)
48.5
Bit depth
32
Channels
4

Result

File size (MB)
279.36

These figures are produced by the calculator below, not typed in by hand — they are recomputed whenever the tool changes.

Run it on your own figures

Frequently asked questions

Does recording at 48 kHz instead of 44.1 make my MP3 bigger?
No. Not by a single byte. A lossy file's size is bitrate × duration ÷ 8, and the sample rate does not appear in that expression. Encode the same one-minute piece at 320 kbps from a 44.1 kHz source and from a 48 kHz source and both come out at 2,400,000 bytes. What the sample rate changes is what the encoder has to work with: 48 kHz can represent frequencies up to 24 kHz where 44.1 stops at 22.05, so at a fixed bitrate the encoder has slightly more spectrum to describe with the same budget. In practice that is inaudible at 320 kbps and marginal at 128. The confusion comes from PCM, where sample rate does drive size directly — 48 kHz, 16-bit stereo is 192,000 bytes per second against 176,400 for CD, about nine percent more. If you are exporting WAV, the rate matters to your disk. If you are exporting MP3, AAC or Opus at a fixed bitrate, only the duration and the bitrate matter.
Why is my WAV so much bigger than the MP3 I made from it?
Because the WAV stores every sample and the MP3 stores a description. Put numbers on it: a CD-standard WAV runs at 1411.2 kbps, and a 320 kbps MP3 is by definition 320 kbps, so the ratio is 1411.2 ÷ 320 = 4.41 to one. At 128 kbps the ratio is 11.0 to one. A minute is 10,584,000 bytes as WAV, 2,400,000 as a 320 kbps MP3 and 960,000 at 128. The saving is not compression in the sense that a ZIP file compresses; it is discarding. A psychoacoustic model decides which parts of the signal will be masked by louder parts nearby in frequency or time, and those parts are not stored at all. That is why the process is irreversible and why re-encoding an MP3 to a higher bitrate cannot recover anything. If you want the file smaller without discarding, use FLAC or ALAC: they reconstruct the original bit for bit and typically land around 55 to 70 percent of the WAV, so roughly 780 to 990 kbps from CD material.
Is 24-bit actually worth the extra space?
While recording, yes; for delivery, almost never. The arithmetic says 16 bits give a dynamic range of 6.0206 × 16 + 1.7609 = 98.09 dB and 24 bits give 146.26 dB, an apparent gain of 48 dB for a fifty percent increase in file size. But no converter delivers 146 dB: thermal noise in the analogue input stage puts a practical floor around 120 to 125 dB on the best available hardware, so most of that theoretical range is unreachable. What the extra bits genuinely buy is headroom during capture. You can set levels 20 dB below full scale to be safe from unexpected peaks and still have more usable range than 16 bits would give at optimal levels, then normalise afterwards without exposing quantisation noise. That is a real working advantage, and it is why sessions are tracked and mixed at 24 bits. At the delivery stage the listening environment sets the floor — a quiet room has a noise level around 30 dB SPL and no one plays music at 128 dB — so 16 bits with proper dither is transparent, and the file is a third smaller. Track at 24, deliver at 16.
Why does my file manager report a different size from the calculator?
Almost always the megabyte, not the audio. A minute of CD-standard audio is 10,584,000 bytes. Call a megabyte a million bytes and that reads as 10.58 MB; call it 1,048,576 bytes and the same file reads as 10.09 MiB, a difference of about 4.9 percent. Storage manufacturers, network engineers and most online calculators use the decimal sense; several operating systems have historically displayed the binary quantity under the decimal label MB, which is where the argument comes from. The gap widens as the units grow: it is 2.4 percent at the kilobyte, 4.9 at the megabyte, 7.4 at the gigabyte. Two other small effects can show up. WAV files carry a header of a few dozen bytes, which is invisible at these scales but not zero. And a file's size on disk is rounded up to a whole number of allocation blocks, so a short clip can occupy noticeably more space than it contains. If a calculator and a listing differ by roughly five percent per unit step, it is the megabyte; if they differ by a few hundred bytes, it is the header; if a tiny file shows as 4 KB, it is the block size.
How much space does a multitrack session need?
Multiply the per-channel rate by the number of channels and by the wall-clock length of the session, not the length of the finished piece. A 96 kHz, 24-bit eight-track session runs at 96,000 × 24 × 8 ÷ 8 = 2,304,000 bytes per second, which is 138.24 MB per minute and 8.29 GB per hour of recording. At the more common 48 kHz and 24 bits, eight tracks come to 1,152,000 bytes per second, or 69.12 MB per minute. The number people underestimate is the wall-clock part: a session that yields four minutes of usable take may have the transport rolling for two hours across all channels, and every one of those hours is stored in full because PCM does not care whether anyone was playing. Add roughly thirty to fifty percent on top for edit history, freeze and bounce files, and undo state, depending on the workstation. Two working habits control the total more than any format choice: stop the transport between takes, and record only the channels that have a source connected rather than arming the whole desk.

Articles you may find interesting

All guides
ExplainerFrame Rates, Timecode, and the Drop-Frame That Drops NothingFrames = duration × rate is trivial until the rate is 29.97. Non-drop timecode then drifts exactly 3.6 seconds an hour. Drop-frame corrects it by skipping 108 frame numbers — the same 108 — but the correction is not perfect: counting every frame shows a residual of 3.6 milliseconds per hour.ExplainerScreen Resolution, Pixel Density, and the Numbers Marketing UsesA diagonal plus an aspect ratio gives you width and height by Pythagoras, and the answer is not what the marketing implies: a 27-inch 21:9 has 16.2% less area than a 27-inch 16:9. Then pixels per degree, which shows the highest-PPI phone is not the sharpest thing you own.ExplainerCrop Factor: What It Changes and What It Does NotCrop factor is a ratio of sensor diagonals. It changes framing, not the lens — proved by computing field of view both ways — and it applies to the f-number as well as the focal length, which is the half most articles leave out.ExplainerDepth of Field: What Actually Controls ItFour variables set depth of field, and subject distance dominates the other three. The exact formulas, a computed table, why the circle of confusion is a decision rather than a measurement, and what "full frame has less depth of field" really means.ExplainerHow Unix File Permissions Work: Reading 755 Without GuessingRead is 4, write is 2, execute is 1, and each of the three digits describes a different party. The part most explanations get wrong is what the execute bit does on a directory — it grants traversal, not the right to run anything.How-toHow Long Does It Take to Upload a File? The Size Times 8 Divided by Speed FormulaEstimate upload time with one formula: file size in bits divided by your upload speed. Learn why upload is usually slower than download and how overhead affects the result.

Related tools

Sources

Spotted a mistake in this article?