schnaader

Some mixed results for older versions (0.4 and 0.4.3) can be found here: http://schnaader.info/precomp_results.php

But both ratio and time heavily depend on if there is data in the file that can processed by Precomp. Since deflate/zlib/zip/gzip is used for other filetypes and containers (.docx/.apk/.jar/...) and stuff like game resource files, so results can be surprisingly well, especially when comparing to traditional compressors that can't handle the compressed data at all. On the other hand, newer compression methods like .xz/.7z/.rar/brotli) aren't supported (yet), so Precomp can't do much about them.

Not being backward compatible is more of a protection in alpha phase and to avoid confusion, the error Precomp gives when trying to process files created with older versions could be changed to a warning. In most cases, the version check could be patched out and the data of older .pcf files would be restored correctly with newer versions.

Yeah, the name was better for the initial versions of Precomp that basically only did the decompression part (like using "-cn" now) and prepared the data before further compressing it with other tools. It also has the downside of being a common term (abbrevation of precomposition) in image/video editing.

Also, for other stream types like JPG and MP3, even "-cn" directly compresses the data without being able to see the intermediate decompressed representation, so in these cases Precomp (re)compresses.

But well, it's just a name and I decided to stick with it, changing it several times would've lead to confusion, too.

Author of Precomp here. First of all, thanks for the attention, the sudden rise of the GitHub stats surprised me, but now I know the reason. So some comments from my side here, I'll answer some of the threads, feel free to ask questions.

The project has been around quite long. I started with it in 2006, but as I'm basically working on it alone (though it got better with the change to open source) and don't have much spare time (studying, work, father of two kids) updates are less frequent than I'd wish to.

The upside of this long time is that the program itself is quite stable, so e.g. it's hard to find data that leads to a crash or incorrect decompression that is not specially crafted for this purpose.

The biggest challenge at the moment is the codebase that is very monolithic (one big precomp.cpp) and mixes newer parts (e.g. the preflate integretation) with old C style code. On the plus side of things, the code is platform independent (in the branch, it even compiles on ARM) and compiling should be no problem using CMake.

Another thing missing because of not-much-time is the documentation. There's some basic information in the README and the program syntax reveals the meaning of most parameters, but there could be much more doc. Very much information can be found at the encode.su forum, but of course, this is very unstructured and often related to bugs, questions about the program/algorithm or problems on certain files.

That said, just throw your data at Precomp and see how it performs. Both ratio and duration heavily depends on what data is fed in, but since some of the supported streams like zLib/deflate or jpg are used everywhere, there are many (sometimes surprising) examples like APK packages and Linux Distribution images where it outperforms the usual compressors like 7-Zip. And last, but not least, the usual GitHub things apply: feel free to check out the existing issues, create new ones, play with the source code, fork it, create pull requests.