Hi Antonio, > As you can see, lzip adjusts the dictionary to the file size.
Yep. > > $ stat -c '%s %n' * | sort -k1,1n -k2 > > 20957117 foo.xcf.lzip-m64-s64MiB > > 21001368 foo.xcf.xz-9 > > You may perhaps obtain slightly better results with the shorter > command 'lzip -9s26'. Right, maximum `-m' of 273, with same `-s 64MiB'. I settled on `lzip -9 -s 96MiB' in ~/bin/tolz because 96 MiB × 10 is about the maximum I can dedicate to compression on this particular machine, and I'm happy that 96 MiB, plus a bit, will always be available for decompression. > > 2^12 to 2^29 bytes. Note that dictionary sizes are quantized. > > If the specified size does not match one of the valid sizes, it > > will be rounded upwards by adding up to (BYTES / 8) to it. > > > > Could info's last sentence be extended slightly with a clue why? > > It has nothing to do with lzip's algorithm. It is simply for > efficiency. As the dictionary size is just the minimum size of the > buffer needed to decompress a file, it does not hurt to allocate a > slightly larger buffer. This allows the size to be coded in just one > byte, instead of the four bytes used by lzma-alone. Ah, `DS (coded dictionary size, 1 byte)' in the info. Perhaps a reference to that part of the format could be added to the `rounded upwards' above. > BTW, do you know zutils' zupdate? > http://www.nongnu.org/zutils/zutils.html No, I wasn't aware of zutils at all. I'm familiar with zgrep(1), etc., and here on Arch Linux they're present from the gzip package so zutils would clash as there's no `alternatives' system like Debian. Also, I'm familiar with tolz's logic and tests so I'm happy to stick with that. BTW, I noticed the info here has a few mispelt words. ✗ Additionaly posible substract substracting ✓ Additionally possible subtract subtracting -- Cheers, Ralph. https://plus.google.com/+RalphCorderoy _______________________________________________ Lzip-bug mailing list [email protected] https://lists.nongnu.org/mailman/listinfo/lzip-bug
