Benchmarks

Benchmarks

Measured on the v2.0 release build, an 11-file corpus of real-world and lame-generated MP3s covering CBR (128/160/320 kbps), VBR (-V0/-V2), mono/stereo/joint stereo, and MPEG-1/MPEG-2. Percentages are compressed size ÷ original size — lower is better. Timings are per-file averages.

packMP3 vs general-purpose compressors

packMP3 understands the MP3 bitstream (Huffman-coded spectral data, scalefactors, side info) and re-models each field with a dedicated adaptive arithmetic coder. General-purpose compressors see MP3 as already near-random bytes, since the Huffman coding and quantization already squeezed most of the redundancy out — that's exactly the redundancy packMP3's format-aware models can still find.

Compressor	Avg. size (smaller = better)
packMP3 -k1	88.6%
brotli -q11	98.3%
zstd -19	98.8%
gzip -9	99.0%
bzip2 -9	99.0%
xz -9	99.3%

packMP3 saves ~11.4%; the best general-purpose compressor (brotli) saves ~1.7% on the same files — roughly 6-7× more compression, because it's the only one exploiting MP3-specific structure.

The trade-off is CPU: packMP3's arithmetic coding is much slower per byte than gzip/zstd (hundreds of ms vs tens of ms per file in this corpus). brotli -q11 is the one general-purpose compressor that's also slow, and it still doesn't approach packMP3's ratio on MP3 input.

-k ratio vs. speed

-k<n> splits one file into n independent chunks so encode/decode can use multiple cores — at a small ratio cost (see Format for why). All values are fully lossless; only the ratio/speed trade-off changes.

-k	ratio	encode (avg)	decode (avg)
1 (default)	88.6%	265 ms	274 ms
2	89.2%	142 ms (~1.9×)	153 ms (~1.8×)
4	89.8%	82 ms (~3.2×)	85 ms (~3.2×)

Pick -k1 for archival/bandwidth-constrained use where ratio matters most; pick -k4 (or -k0 for auto) for interactive/batch use where wall-clock time matters most.