BCM v0.04 is here! [!]

[vi6hd8]

here's results of a small test on video dvd disc

2,194,866,176 (2,04gb) - original iso
2,012,827,345 (1,87gb) - WinRAR 3.80b5 (best, all filters)
1,943,719,107 (1,80gb) - FreeArc (-mx -ld=1gb)
1,930,752,565 (1,79gb) - 7-Zip (ultra, 128mb dict)
1,861,798,652 (1,73gb) - CCMx 1.30c (model 7)
1,822,283,097 (1,69gb) - BCM 0.004
1,779,106,230 (1,65gb) - NanoZip 0.06a (-cc -m64m)
1,756,546,785 (1,63gb) - NanoZip 0.06a (-cc -m1.5g)
1,756,449,884 (1,63gb) - NanoZip 0.06a (-cc -m2g)

can't wait to test bcm with adjustable memory usage
and would be nice to see multithread support in one of next versions

ps. imho memory parameter should be in MBs

[encode]

bcm v0.05 by ilia muraviev
usage: bcm [options] input [output]
options:
  -b# set block size to # kilobytes (default: -b65536)
  -d  decompress
  -f  force overwrite of output file

The last thing is an EXE-filter, not decided yet keep new or completely remove any filters. The thing is an old and the best filter is not that good with a large blocks (>64 MB), it may degrade the compression. The filter that works with all block sizes is not that good in practice...

[joerg]

@encode

if you not sure about the filter
i think
you should it remove for the next release
or give us the possiblity to "switch on/switch off" the filter

best regards

waiting for bcm 0.05 ..

[m^2]

+1 for megabytes.

[encode]

Actually, we should able to set block size in kilobytes due to some reasons:
1. Ability to compare with older BWT compressors like BZIP2 (bzip2 -9 = bcm -b900)
2. More precise block size can play a segmentation role. Say, with some binary files, including calgary.tar, setting a smaller block may help in terms of compression

OK, new BCM v0.05 is done. The last thing is the default block size:

option, mem. usage

-b10000, 51 MB
-b20000, 101 MB
-b30000, 151 MB
-b40000, 201 MB
-b50000, 251 MB
-b60000, 301 MB
-b70000, 351 MB
-b80000, 401 MB
-b90000, 451 MB
-b100000, 501 MB