$ xmp 2years.mod.bz2 Extended Module Player 3.5.0 [...] Loading 2years.mod.bz2... (1 of 1) Depacking bzip2 file... done Module title : 2years [...] (xmp plays file) $ bzip2 -d 2years.mod.bz2 $ lzma -9 2years.mod $ xmp 2years.mod.lzma Extended Module Player 3.5.0 [...] Loading 2years.mod.lzma... (1 of 1) xmp: 2years.mod.lzma: unrecognized file format $ less /usr/share/doc/xmp-3.5.0/README.bz2 [...] SUPPORTED PACKERS [...] Format Helper Native environment [...] lzma lzma Unix [...]
It should support both LZMA (the older XZ format) and XZ. Which format exactly was your file compressed with?
(In reply to comment #1) > It should support both LZMA (the older XZ format) and XZ. Which format > exactly was your file compressed with? With that created by "lzma -9" ;) However I tested now with "xz -9" and xmp actually manages to play that file. So, maybe it doesn't consider file extension but just looks at the headers searching for magics (which don't exist in plain LZMA format).
xmp-3.5.0/src/misc/load.c line 142 } else if (b[0] == 0x5d && b[1] == 0 && b[2] == 0 && b[3] == 0x80) { packer = "lzma"; cmd = "lzma -dc \"%s\""; } else ... b[0] is the properties field of the LZMA header. It can be any value from 0 up to 0xE0. It's (pb * 5 + lp) * 9 + lc with pb = position bits, lp = literal position bits and lc = literal context bits. The most common lc/lp/pb values are 3/0/2 (yielding to the 0x5d above) but any combination is possible. XZ Utils has an additional requirement: lc + lp <= 4 - but that is a tool requirement, not a file format constraint. b[1..4] is the dictionary size. It can be any arbitrary value. It's recommended only to use values 2^n or 2^n+2^(n-1) but that is just that: A recommendation. (Source: xz-5.0.2/doc/lzma-file-format.txt) My file uses 3/0/2 as values for lc/lp/pb so, first byte is indeed 0x5d - no problem here. But with that test above, dictionary size must be 8M + n*16M with n=[0,255] (which leaves only 8M and 24M from the recommendation). My file has dict size 64M. So it's rejected. Solution: One can't really identify LZMA files by their content, there is no magic. One has to believe the user, when he gives a file name ending in ".lzma" that it is indeed an LZMA file.
Created attachment 314051 [details, diff] Fixes the problem described in this bug report for LZMA files.
Reported upstream via E-Mail.
removed from the tree
