-
Notifications
You must be signed in to change notification settings - Fork 0
Troubleshooting
Layer I (.mp1) and Layer II (.mp2) use a fundamentally different
coding scheme from Layer III (no Huffman coding). packMP3 has a
separate codec for them in the source, but it's disabled in this
release — the file is left untouched. See FAQ.
You're most likely trying to decompress a .pmp/.pm3 archive made by
an incompatible major version — v2.0 changed the archive format
entirely, so v1.x archives need a v1.x binary. See
Format#version-compatibility. This is a
clean error, not data corruption.
By default packMP3 refuses to compress a file if doing so would risk
non-byte-exact reconstruction (see the
-p/-d/-ver trade-off
in the README). Common triggers:
- Free-format bitrate.
- Mixed block types within one granule (long + short blocks mixed — some encoders emit this on transients).
- Malformed/corrupt frame headers.
Pass -p to proceed anyway — the reconstructed MP3 will be audibly
identical but may not be byte-for-byte identical to the original.
-ver does a real encode → decode → byte-compare. If you're also
passing -p or -d, verification is expected to fail — both flags
intentionally trade away byte-exactness (see the README section linked
above). Don't combine -ver with -p/-d.
That archive was made with -k > 1 (intra-file parallel chunking). It
still decompresses losslessly regardless of chunk count — chunks: N
is purely informational. See Format.
This is a Windows shell limitation with drag-and-drop of very large file
selections, not specific to packMP3. Use the command line
(packMP3 a *.mp3 or with -r for folders) instead — packMP3 has been
tested with thousands of files from the command line without issue.
Open an issue at https://github.com/YadeWira/packMP3/issues with the
command you ran, the packMP3 version (packMP3 with no arguments
prints it), and — if possible — a way to reproduce it.