Audio Bitrate, Explained

For uncompressed audio it is not a setting, it is arithmetic: sample rate × bit depth × channels. Nothing is chosen and nothing is discarded. We measured six PCM files to confirm the formula holds exactly:

For lossy audio, bitrate becomes a budget you hand the encoder, and its whole job is deciding what to throw away to fit. This is why a bitrate number means something different for MP3 than it does for Opus even though both describe the same bytes per second. Same budget, different shopper.

Lossless codecs sit in between. FLAC has no bitrate setting at all; the number ffprobe reports is whatever the file turned out to be. Our music fixture came out at 1,009,513 bps, which is 71.5% of the WAV, and that ratio would be different on different material.

These three get used interchangeably and they describe completely different things.

Bit depth does not survive into a lossy file. An MP3 has no bit depth; asking what bit depth a 192 kbps MP3 is does not have an answer, because the encoder stores frequency coefficients rather than samples. It decodes to whatever depth you ask for.

And sample rate does not change the size of a lossy file. We encoded the same mono speech at a fixed 48 kbps from five sample rates:

216 bytes of variation across a nearly threefold change in sample rate. The budget was fixed, so the size was fixed. What changed is what the encoder bought with it: fewer frequency bands to describe means more bits per band, which is why a low sample rate can improve a very low bitrate encode while capping the treble.

Opus takes the decision away entirely. It operates at 48 kHz internally and resamples everything, so every Opus file we produced reported 48,000 Hz no matter what went in.

CBR spends the same bits on every second. VBR spends bits where the audio is complicated and saves them where it is not, hitting a quality target rather than a size. ABR varies locally but steers toward an average you name.

Measured on a fixture built specifically to expose the difference: 10 seconds of dense audio, 7 seconds quiet and low-passed, 4 seconds of digital silence, 9 seconds dense again. Same 5,292,078-byte source for all three.

VBR came out 24% smaller than CBR by dropping to 32 kbps through the silence instead of faithfully describing nothing at 192 kbps. That is the entire case for VBR, and it is why LAME 4.0’s own --longhelp output opens with RECOMMENDED: lame -V2 input.wav output.mp3 rather than a bitrate.

Two footnotes the folklore misses. CBR is not exactly constant: our 192 kbps file measured 191 to 196 kbps per second, because MP3 frames carry 1,152 samples and do not align to second boundaries, and because LAME uses a bit reservoir to lend bits between frames. And the amount VBR saves depends entirely on the material. On a spectrally uniform tone bed, the same V2 setting stayed between 172 and 178 kbps all the way through, because there was nothing to vary.

This is the second half of “Convert mp3 to wav using FFmpeg for VBR” on Super User, asked 13 November 2013, score 65 with 190,838 views and three answers as of 26 September 2026: “how would I know whether that source audio is fixed bitrate or variable?”

For MP3 there is a one-line answer, and it is reliable. LAME writes a header frame at the top of every file, tagged Xing for variable bitrate and Info for constant:

head -c 4096 track.mp3 | LC_ALL=C grep -a -o -m1 -E 'Xing|Info'

We ran it across eight files covering every mode and it was correct on all of them: the 128, 192 and 320 kbps CBR encodes reported Info; V0, V2 and the ABR encode reported Xing.

It also told us something about our own app that we would not otherwise have published. Smol’s MP3 compression path writes Info, because it produces 192 kbps CBR. Its MP3 conversion path writes Xing, because it produces LAME V2. Two operations, two bitrate strategies, same output extension.

The codec-independent version is to look at the frame sizes themselves, which cannot be faked by a header:

ffprobe -v error -select_streams a:0 -show_entries packet=size \
        -of default=nw=1:nk=1 track.mp3 | sort -n -u | wc -l

Our 192 kbps CBR file returned 2 distinct frame sizes, 626 and 627 bytes. The VBR and ABR files each returned 7, ranging from 104 to 1,044 bytes. A handful of distinct sizes means constant; a spread means variable.

Because the number describes the budget, not the purchase. Both files are the same size. Opus was designed two decades later, with a hybrid speech and music model, and it spends the budget differently.

The difference that can be measured without a listening panel is at the bottom of the range. Asked for low bitrates on 44.1 kHz stereo speech:

MP3 has a hard 32 kbps floor at 44.1 kHz and clamps without complaint: our 16, 24 and 32 kbps requests produced three byte-identical 257,193-byte files. Apple’s AAC encoder refuses to go below roughly 64 kbps for 44.1 kHz stereo and prints [aac_at] Bitrate 32000 not allowed; changing to 64000. Opus honored every request down to 17 kbps.

Look at the last two Opus rows, though, because they go the other way and they will cost you bytes if you miss them. ffmpeg runs libopus in unconstrained VBR by default, where -b:a is a target rather than a ceiling. Asked for 64 kbps stereo it delivered 82,128 bps. Adding -vbr constrained brought it to 64,601 bps, and -vbr off to 64,644. If you are budgeting file size in Opus, say so:

ffmpeg -i in.wav -c:a libopus -b:a 64k -vbr constrained out.opus

On where transparency sits, we will only repeat what the codec authors publish. LAME recommends V2. Xiph, who wrote Opus, state on their recommended settings page that “Opus at 128 KB/s (VBR) is pretty much transparent”, and list 24 kbps mono and 32 kbps stereo for podcasts and 96 to 128 kbps for stereo music storage. Anyone telling you a single number is transparent for all listeners on all material is guessing. The test that settles it is a blind ABX on your own ears and your own tracks.

Per hour, computed from bitrates we measured rather than from nominal settings. Use this to budget backwards from a size limit.

Two things fall out of this table. The jump from 192 to 320 kbps costs 57.6 MB an hour for material the encoder was not struggling with. And the gap between an hour of CD-rate WAV and an hour of podcast-rate Opus is 58 to 1.

If you got here to understand a number rather than to change one, nothing on this page needs buying. Every measurement above came from ffmpeg, ffprobe and afconvert, two of which you already have and the third of which is free.

To inspect a file, use ffprobe. ffprobe -v error -select_streams a:0 -show_entries stream=codec_name,bit_rate,sample_rate,channels -of default=nw=1 file answers every question this article defines, in one line, on any file.

To change one file’s bitrate, use ffmpeg or afconvert. Both are one line. Neither costs anything.

Smol is a bitrate control attached to a drop target: audio compression targets aac, m4a, mp3, wav, flac, ogg and opus, with bitrate from 16 to 512 kbps and sample rate from 8 to 192 kHz. It produced byte-identical output to ffmpeg everywhere we compared them, which is the point: you are buying the folder, not the encoder. If that is the job, it is $29 once and it runs entirely on your Mac. If the job is one file, use the command.

The pages that apply these numbers to specific decisions are compressing an audio file on a Mac, compressing a podcast episode for speech, and converting WAV to MP3 for the VBR settings in context. If cover art matters to you, converting FLAC to MP3 has the measurement that decides which tool to use.