-
Notifications
You must be signed in to change notification settings - Fork 0
FAQ
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.
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.
-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.
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.
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.
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.
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.