ZCM with Freearc
 

As I seen, many people told that ZCM is not supported for freearc, and aswadd wants a working example of ZCM with freearc, so I thought to make a new thread instead which could help people, (don't mind if it is called as 'SPAM')

One more things guys, I have heard that ZCM 0.93 is case sensitive, anyways, as I think it will not matter with FreeArc because freearc already made it in one file input only.

You could rename zcmx64 to zcm if you have 64bit processor and you are running 64bit Operating System

Some commands and switches details (you could apply them in arc.ini) -

<Commands>
a Add files to archive
x Extract files in destination path
l List archive

<Switches>
t<0...8> number of task (0=autodetect,default=1)
r Recurse subdirectories
s Solid Mode ON
v Verbose Mode
m [default -m4] Compression Method/Memory (-m0 ... -m7) (m8 is available for x64)


Use above commands and switches with the CLS.ini in the encode line

Thanks Razor12911 for making CLS


Here some test pics -
http://i.imgur.com/IXKonH0.png
http://i.imgur.com/AeNmYVK.png

I'm thinking about a concept of adding external conpresseur dynamically, so any external compressor compatible with FreeArc interested me much thank you for this.

Your welcome.

O.o something wrong is going on it increases the size not compressing
Compressed 20 files, 75,397,181 => 93,247,590 bytes. Ratio 123.6%

Use srep+lzma after zcm and you will see the final size and compare with precoml+srep+lzma, you will see almost same results ;)

arc is collecting the final compressed file and the first packed file into the last output :(

Archive is I:\1\MyMask\temp\freearc313767405.tmp\$$arcdatafil e$$.tmp
argc=*
100% Compressed 75397181 bytes to 17850408 bytes
100%
Errorlevel=0
Compressed 20 files, 75,397,181 => 93,247,590 bytes. Ratio 123.6%
Compression time: cpu 0.14 secs, real 32.22 secs. Speed 2,340 kB/s
All OK
=======================================
75397181+17850408=93247589
it's not a precompressor it's an issue :( it collects the original data & the compressed data in one archive

Hmm matey, I didn't get you, but whatever you are saying is not happening and zcm works like this way only, see this bench also, you will know -

http://encode.ru/threads/1432-Experi...ll=1#post27672

here is the solution :D
packcmd = zcmx64 a -s -r -m8 $$arcpackedfile$$.tmp $$arcdatafile$$.tmp
================================================== =======
Compressed 20 files, 75,397,181 => 17,850,409 bytes. Ratio 23.6%
Compression time: cpu 0.06 secs, real 32.83 secs. Speed 2,297 kB/s
All OK

OK matey, give me some hours, I have to go for now, will sort out this issue soon :)

Matey, BTW which method you used in arc.ini?

ok :) I'm waiting

only zcm :) the idea to get it work is to reverse $$arcdatafile$$.tmp $$arcpackedfile$$.tmp
but i still get decompression failed :D

I'm using zcmx64 last version it already has m8 method but maybe other versions don't have it :)

Matey, as per me this is fully wrong process in the view with freearc, anyways, you give me results with -m7, I can't test everything right now because I am on mobile

Nope matey, anyhow the latest version is 0.93 which is included with my release, and if you don't believe me then please readout the last forum of zcm and even then you not believe then just checkout help area eight hat tool, you will know that am right!

m7
Compressed 20 files, 75,397,181 => 17,849,995 bytes. Ratio 23.6%
Compression time: cpu 0.12 secs, real 29.21 secs. Speed 2,581 kB/s

http://i.imgur.com/kMaa8ct.png
it has m8 method :) zcm 0.93 X64 version
x86 version has only until m7 method :)

OK matey, you are right, I just turned on my PC and seen that the infile should be placed after the archive output, so the pattern is correct ;) I will update my thread my tools, thanks for telling the mistake, am always in hurry like now too ;)

the main problem not in the ratio or compression :( it's from the decompression it always failed :(

we need to know where is the problem to solve it Compression is always success but decompression whatever i did it always fail .. we need to open freearc temp files to see where is the problem ? or it's not comp table with arc :(
Errorlevel=1
ERROR: invalid compression method or parameters in zcm
============================================
My arc.ini
[External compressor:zcm]
packcmd = zcmx64 a -s -v -m8 archive.zcm *
unpackcmd = zcmx64 x archive.zcm
packedfile = archive.zcm

@aswadd ..you're having the same problem that I had in the past by integrating zcm settings inside the configuration arc.ini files, try to eliminate fazip configuration, decompression should be successful.
Now I am in the company to update a management software, but in the evening I think to solve the problem, in order to integrate with other 30 compressors the zcm without this going at odds, especially with fazip and the classic error : "ERROR: write error (disk full?) in compression algorithm lzma:mfbt4:d1m".:rolleyes:

Hey guys zcm not support pipes!.
The only way is
7z a -ttar
srep
and finally zcm.

Ya actually that's the real thing, it don't support pipes

even not using fazip still have this error
Errorlevel=1
ERROR: invalid compression method or parameters in zcm
in the end , zcm is not comptable with arc but what i want to know why ?
where is the problem exactly 'cause maybe i can do something external to correct this error :D

can someone explain in details why arc doesn't work with zcm ? where is the problem exactly located ? .. in the temp folder i can see zcm already extracted the arcdatafile but then something wrong happens with arc ?? if the final data was successfully decompressed so where is the problem ??

When the mate @MAK opened this thread I thought there was something new, but I was wrong, @aswadd the problem is just one "ZCM" we have already dealt with this issue in other threads without any solution, plus I have had no response positive to problem from Nania Francesco.:rolleyes:

ZCM is a compressor that uses a compression method similar to fat Context Mixing (Mixing of contexts or orders) characterized by compression and decompression speeds comparable in terms of time with high compression efficiency, and personally I think it's one of the best compressors in circulation.;)

I was intrigued by the fact that @MAK was able to decompress zcm with the FA support, but the decompression was done in a positive manner in this order only with compression setting "packcmd = zcmx64 a -m8 -r -s -v $$arcdatafile$$.tmp $$arcpackedfile$$.tmp" but in this case the archive was reflate increasing in size and not compressed.
On the contrary the exact setting for compression I think it's this "packcmd = zcmx64 a -m8 -r -s -v $$arcpackedfile$$.tmp $$arcdatafile$$.tmp" where the archive is created rightly smaller of input data. But the decompression does not work with the now known error: invalid compression method or parameters in zcm.

I give up...:D, tests of zcm I made them in the past always with the same result, if someone succeeds a thank and of merit.:)

Actually matey, I was little bit confused with arcdatafile and arcpackedfile, so I wrote them in irregular manner, and then I simply found it working so I posted here because I seen decompression was working and later when I seen help from zcm and know which one is the input file and output file made by freearc, then I corrected it. Sorry for the SPAM :(

:eek: Hey @MAK do not have to apologize to anyone, nothing happened, you do not have any guilty, I just thought that the problem had been fixed.:D

It has been just 2 days totally from the time I meet with inno code and this forum. And some the projects here I seen for the first time

Anyways, I have talked with razor about this zcm problem, maybe he could apply my fixes told in his CLS for zcm, if so, then we be able to decompress zcm at least ;) Actually am not a programmer related to inno stuff and that's why can't write a CLS code, so I just told him the things needed to fixed there in CLS ;)

Cls-zcm
 

Here's CLS, only ran one test.

It shows progress as well.

was a little bit quicker than you. :p

Ohhhhhhhhhhhhhhhhhhhh....you're unique:eek:

Thanks but it was nothing, took 20 minutes to make, big projects take months to make.

:D you are the big boss here , Just one question how can i open the temp files of arc [ $$arcdatafile$$.tmp ] , I feel like if i could open it & see the content , i can do something external to fix zcm problem

why would you want to open those? if the temp is produced by freearc, then it's just concatenation of all the files that are about to be compressed, can't open that because there are literary no headers of some sort but if the temp is produced by previous compressor then just use previous compressor to decompress.
For example, precomp+srep+zcm
the first data temp is for precomp which is just pure concatenation, srep will have data temp but the only thing that can open it is the previous compressor which was precomp, zcm will have its own data temp which is created by srep to decompress so all in all, there'll be 3 data temp, you decompress, you get data srep data from zcm, decomrpess again, you get precomp data from srep, decompress again, you get the concatenated data which is useless but from precomp, long story short, there is no point in trying to do what you want to do.

Tested on Battlefield 4 update files, compressed with LZMA2 then ZCM, diff was 5mb but ****, life is too short people. 1mb/s compression speed, 1mb/s decompression speed, is it really worth it? 5mb better off but have grey hair.

It all depends from the viewpoints, I personally think that the comp/time ratio is not bad.:p

http://i67.tinypic.com/2iv1y11.png

Well

HOOO ...:eek: HA HA HA.....but we're not on Top Gear with Jeremy Clarkson :p:p

Dude, I live by the speed code, if something can't reach 30mb/s, it's not good enough, I'm not really a person of size, storage devices sizes are getting bigger and bigger, I don't mind trading a few mbs or gbs for more speed.

What I don't like is sitting in front of PC like this bear.