I am a long time lurker here and this is my first post.
In the past I wrote programs (never published) on DMC, LZ and PPM/CTW, then I started developing cmv about 2 years and half ago to play with CM.
I wanted to check if there was improvements in using a counter that is a mix of 1 slow and 1 fast non-stationary counter, and the "best" of them, pointed out by the mixer, has an influence on the other (speeding up or slowing down the adaption rate of the "worst"). These are the standard counters used in cmv.
Cmv is a closed source, badly written, very slow (my main focus is on compression ratio, not speed), CLI Windows program.
At the moment there is only a 32 bit version of the program, it can use up to 4 Gb RAM on 64 bit O.S. but full options needs ~4.1 Gb, so, in this case, I often disable the bit 12 of the switches (variable order and memory model) because it seems already modelled quite well by order N and match models. In the next days/weeks I would install a new C/C++ compiler compatible with Windows 8.1 to make a 64 bit executable to test all the options enabled.
Cmv is a single file compressor, not an archiver; it handles file size up to 4 Gb - 1, it saves original and compressed file size, it doesn't save and restore date, hour, attributes, etc..
Cmv hasn't filters, you can use paq8pxd16 -s0 or -f0, DRT, DC, etc..
Initialization of the models can take some time.
The switches shortcuts and operators are the worst characters I can choose, but I like them: enclose the model+switches with "".
Use cmv only for test on saved files. Future versions will break backward compatibility.
"cmv -h" for a short help, "cmv -hv" for the long one.
If you have any questions, feel free to ask.
Code:Some benchmarks: - 9.594.090 Maximum Compression corpus - 35.570.898 Silesia corpus - 18.153.319 ENWIK8 150.226.739 ENWIK9 (-m2,3,+, to do with better options) - 613.782 Calgary corpus (14 files, tarball) - 331.785 Canterbury corpus (tarball) - 840.486.023 Huge Files Compression Benchmark (vm.dll) (-m1,3, to do with better options) - 1.286.407.213 Lossless Photo Compression Benchmark (-m1,3, to do with better options) - 62.002.677 Testing compressors with artificial data - 0.97376289 Generic Compression Benchmark More benchmarks are in the file Benchmarks-00.01.00-2015.09.06.zip. Some files compressed well by cmv compared with the best known: - LOG.txt and NUM.txt (Specific case - High redundant data in a pattern) 23.009 LOG.cmv (-m2,0,0x01ec039f (^0x02000008)) 23.571 LOG.nz (-cO) 819 NUM.cmv (-m2,0,0x00ec8bd9 (^0x0300884e)) 3.404 NUM.nz (???) - SRR062634.filt.fastq (Compression Competition -- $15,000 USD) 14.958.423 SRR062634.filt.fastq.cmv (-m2,3,0x03ededff (>&b12)) 15.035.056 test0-8.paq8px (paq8px_v69 -8 !?) 15,165,514 test0.paq8px (paq8px_v69 -5 ?) - x-ray (Silesia Open Source Compression Benchmark) 3.568.??? x-ray.cmix7 3.568.??? x-ray.cmix6 3.568.??? x-ray.cmix5 3.569.??? x-ray.cmix4 3.569.??? x-ray.cmix3 3.570.??? x-ray.cmix2 3.571.523 x-ray.cmv (-m1,0,0x00a3619f (*^0x034e9400)) 3.577.??? x-ray.cmix1 - FFADMIN.EXE (Why Does NanoZip Compress This File More Than PAQ8 And cmix?) 5.015.668 FFADMIN.nz (-cc ?) 5.265.328 FFADMIN.cmv (-m2,3,0x03ededff (>&b12)) 5.292.665 FFADMIN.cmix (v6 !?)