FAQ

FAQ

Is packMP3 really lossless?

Yes. packMP3 a never writes an archive it can't reconstruct exactly. If you want the strongest guarantee, pass -ver: it compresses, decompresses in memory, and byte-compares against the original before writing anything to disk — if that comparison fails, no archive is written and an error is shown instead.

The one way to lose byte-exactness is asking for it explicitly with -p (proceed on warnings) or -d (discard ID3 metadata) — both are documented trade-offs, never silent.

Why was my MP3 rejected / not compressed?

packMP3 needs to fully understand the MP3 bitstream to re-encode it, so it's stricter than a media player. Common reasons:

• Not MPEG-1/2/2.5 Layer III. Layer I (.mp1) and Layer II (.mp2) use a different, non-Huffman coding scheme — currently disabled (see Format).
• Free-format bitrate. Rare in practice; rejected cleanly.
• Mixed block types within one granule (long and short blocks mixed). Some encoders emit this on transients; rejected cleanly.
• A genuinely malformed/corrupt file.

In every case above, the file is left untouched — packMP3 never produces a broken or partial archive.

What's the difference between -th and -k?

-th<n> parallelizes across files in a batch (each file still processed on one thread). -k<n> parallelizes within one file, splitting it into independent chunks. See Benchmarks for the numbers. They compose: -th4 -k4 on an 16-core machine uses all 16 cores across a batch of large files.

Does -k change the ratio?

Yes, a little — -k1 (default) gives the best ratio; higher -k values trade some ratio for speed because each chunk's model starts fresh instead of learning from the whole file. Every -k value is still fully lossless. See the trade-off table in Benchmarks.

Are .pm3 archives portable across Linux/Windows?

Yes — a .pm3 archive is byte-for-byte identical regardless of which platform produced it, for the same -k value. Verified on Linux x64, Windows 7 SP1 (x86/x64) and Windows 10 x64 in this release.

Can old .pmp files (pre-v2.0) still be decompressed?

No — v2.0 changed the entropy models and archive format. v1.x .pmp archives need a v1.x binary to decompress; v2.0 gives a clean incompatibility error rather than garbage output. See Format.

Will Layer I/II (.mp1/.mp2) support come back?

The codec for it already exists in the source (a separate arithmetic model, never touching the Layer III path) but is disabled for this release. Those files are rejected cleanly with a message, never damaged. Re-enabling is a future decision, not a technical blocker.