Peter Hyman

@twekkel , this is instructive.What I am noticing is zpaq has code which heuristicly determines N2 and N3. N2 is ease of compression (higher = easier), and N3 is set...

I pushed some changes that will allow the max possible block size (N1). It may help. But to be honest, lrzip can't be customized for every situation. It will create...

Thank you for your interest and your feedback.There are improvements in compression levels generally, and certainly speed improvements. But as we learned, for very small files like yours and easily...

This will be the final change on this version and branch. See #146 .Further development will be conducted on my fork for the [LZMA SDK 19.00 branch](https://github.com/pete4abw/lrzip/tree/lzma-sdk-19.00).Thank you for your...

Wrapping lrzip or [lrzip-next](https://github.com/pete4abw/lrzip-next) is challenging. It is and has always been meant to be a command line tool. Reporting progress with multiple threads running simultaneously is hard. With ZPAQ...

Hi @ThomasAdam . I was inspired by your [Release Version Script](https://github.com/fvwmorg/fvwm3/blob/master/utils/fvwm-version-str.sh), and created a project specifically for using `git describe` to update m4 variables in a `configure.ac` file. Currently, it...

> Hey @pete4abw > > Oh that's cool! Thanks for letting me know! Would you consider sending a PR to fvwm3, switching out the current implementation for yours? I'll take...

A first step at #402 . Briefly, `configure.ac` will no longer need to be modified. Using **m4_macros**, and updating fvwm_version_str.sh to fetch log info using `git describe` and `git show`....

[This commit](https://github.com/ckolivas/lrzip/commit/469074b4a59d26566d388680a1154c522d9395c7) may be the culprit.

Each chunk of data to be compressed is split into blocks and passed to the ZPAQ backend in individual threads. In your case, 5 threads were passed to ZPAQ separately....