In this test we use common test files to provide additional benchmark data for all compressors including those that did not qualify for the main benchmark.
| Prog | Ver | Arg | WR |
|---|---|---|---|
| CompressionRatings.Com | |||
| paq | 8p | -5 | 9.770 |
| lpaq | 8 | 7 | 8.224 |
| ZPAQ | 1.00 | cmax.cfg | 7.912 |
| UDA | 0.301 | 7.529 | |
| EPM | r9 | 7.353 | |
| CCM | 1.30c | x 5 | 7.306 |
| PPMonstr | Jr1 | -m512 -o16 | 7.279 |
| ASH | 0.6 | /m512 | 7.242 |
| CMM4 | 0.1e | 75 | 7.117 |
| BWMonstr | 0.01 | 6.616 | |
| RZM | 0.07h | 6.519 | |
| Bee | 0.78 | -m3 -d7 | 6.379 |
| ENC | 0.15 | 6.335 | |
| BWTmix | 0 | c1000 | 6.316 |
| Blizzard | 0.24b | c 100000000 | 6.238 |
| GRZipII | 0.24 | -p -b8m -m1 | 6.235 |
| bcm | 0.09 | -b112 | 6.225 |
| bbb | 1 | cm400q | 6.193 |
| mnzip | 0 | 5 | 6.142 |
| RINGS | 1.5c | 9 | 6.123 |
| Dark | 0.51 | -b112m | 6.044 |
| PPMd | Jr1 | -m256 -r1 -o8 | 6.044 |
| ZZIP | 0.36c | -mx -a -16m | 5.957 |
| Flashzip | 0.93c | -m2 -s7 -b5 | 5.957 |
| Mix | 3e21a | 5.925 | |
| YBS | 0.3f | -m16m | 5.910 |
| BSSC | 0.95a | -b16383 | 5.847 |
| Hook | 1.4 | 512 | 5.846 |
| chile | 0.5 | 5.836 | |
| XWRT | 3.2 | -l12 -b32 -m32 | 5.807 |
All compressors that pass the qualification without an error are tested here with known test files to provide additional benchmark data. Another reason to run benchmarks with these files is that some experts may prefer to see the results for these files despite the problems that arise using them. Because of the problems discussed below it is recommended for non-experts to keep to the the main Compression Ratings benchmark instead.
The files used here are often part of collections (like Calgary Corpus) that are supposed to sample various types of data to give broad evaluation over wide range of data types. These test files are flawed for various reasons that include:
Using these files may work for developing a compressor (evaluating changes to algorithms), but the files suit poorly for comparing 2 or more compressors. We can observe that the main Compression Ratings benchmark by large does not suffer from any of these points.
To address the point 4. We have not included some files that fit into this category especially. Because of 1. it follows that the measured timings are skewed for programs that slow down as the size of input grows and compression ratio is difficult to measure (also because of 3.) as the decoder program size takes large portition of the output size. To address this, we introduce "weighted compression ratio" (WR) [2] that discounts 90% of the decompressor program size, but no more than 85000 bytes (roughly 90% of the median decompression program size). So the 90% discount is an arbitrary number to limit random effect from including the decompressor size to the results for small files. We limit the discount to the median because the purpose is to eliminate this effect, but not to eliminate the decompressor size (such as static dictionaries) completely. No ratings are provided in these tests because of the results require interpretation even to establish compressor performance for these specific files. (We cannot make conclusions about compressors strenght over certain types of files because of 2.)
Currently there is an issue with programs that are configured to use SFX. We are unable to display all numbers for these programs (since no decompressor size is known). This will be fixed in the future.
[1] Files are too esoteric (performance doesn't translate to other data) that small tweaks to compressors may improve compression ratio dramatically (but have no effect in other files). Or files that are already compressed or contain errors (like book1).
[2] WR=sizeof(input)/(sizeof(output)+sizeof(decompressor)-0.9*min(95kb,sizeof(decompressor)))