Decompressing problems

[felice2011]

The result seems to be obvious ...

pzlib+srep64+zcm

-↓- [ CMD Bench.Test.Info v0.6.9c ] -↓- Compressed Archive Completed At -↓- 18/11/2016 13:06:20
=============================================================================================================================================
 ○ [ ALGORITHM ] ○ [ INPUT SIZE ] ○ [ OUTPUT SIZE ] ○ [ RATIO.% ] ○ [ ARCHIVED FILES ] ○ [ COMP.TIME ] ○ [ SYNTAX - OPTIONS - ARGUMENTS ] ○

             Arc         981,1°MB          453,2°MB        46,19%              1°Files    00:11:11:329   a -ma9 -ds -lc1024 -ld1024 -ep1 -di -i2 -ed -r -s; -w"temp" -mpzlib+srep64+zcm 
=============================================================================================================================================

srep64+pzlib+zcm

-↓- [ CMD Bench.Test.Info v0.6.9c ] -↓- Compressed Archive Completed At -↓- 18/11/2016 13:18:14
=============================================================================================================================================
 ○ [ ALGORITHM ] ○ [ INPUT SIZE ] ○ [ OUTPUT SIZE ] ○ [ RATIO.% ] ○ [ ARCHIVED FILES ] ○ [ COMP.TIME ] ○ [ SYNTAX - OPTIONS - ARGUMENTS ] ○

             Arc         981,1°MB          693,5°MB        70,69%              1°Files    00:10:52:408   a -ma9 -ds -lc1024 -ld1024 -ep1 -di -i2 -ed -r -s; -w"temp" -msrep64+pzlib+zcm 
=============================================================================================================================================

I do not understand what benefits or on what files with pzlib support, should be inserted the "pzlib" pre-compressor at second reading in a concatenated method ...

[ChronoCross]

----edited---
thanks felice for your bench. i was right.

[felice2011]

Originally Posted by ChronoCross

If the first method extract correctly, i was wrong.

The first method extracts correctly in 9 min... the second method I not tested the extraction...

[ChronoCross]

The first method is the correct way to get a small size.
The second method is not good. You noob guy's precompressors goes first always.

[aswadd]

Lol all this comments and tests to know the smallest Guys it's extremely plain , ofc srep64+zcm after the pre-compressor will be better
it would be a waste of time & data & ratio if u used it like this srep64+pzlib+zcm
it's look like u're telling arc to compress then decompress then compress so why the first one !!

[Razor12911]

Originally Posted by ChronoCross

You noob guy's precompressors goes first always.

Not always, sometimes you just have to be smart, a precompressor can come after srep, that is if you're compressing some data that has a lot of repetitions of the same thing provided it has zlib streams, especially if they are big.

I can provide you some file that is compressed using level 9 and memory 1 zlib method, and it is compressed to 10mb, I then make repetitions of the 10mb to a 1GB file, there's going to be 100 repeated streams because 10x100 = 1GB.

If you apply a precompressor first here, remember I said memory 1, this is the slowest setting so the precompressor will process the same stream at very slow speeds 100 times rather than telling srep via command that there is a repetition, it should only accept a minimum of 10mb repetitions, srep will combine all those repetitions then precompressor will only process that one stream, meaning you will get same ratio while getting 100 times more speed, who's the noob now?

But in order for you to notice this, you have to thoroughly check the input you're about compress before compressing before making this attempt of making a repetition reducer before a precompressor.

Originally Posted by felice2011

The result seems to be obvious ...

pzlib+srep64+zcm

-↓- [ CMD Bench.Test.Info v0.6.9c ] -↓- Compressed Archive Completed At -↓- 18/11/2016 13:06:20
=============================================================================================================================================
 ○ [ ALGORITHM ] ○ [ INPUT SIZE ] ○ [ OUTPUT SIZE ] ○ [ RATIO.% ] ○ [ ARCHIVED FILES ] ○ [ COMP.TIME ] ○ [ SYNTAX - OPTIONS - ARGUMENTS ] ○

             Arc         981,1°MB          453,2°MB        46,19%              1°Files    00:11:11:329   a -ma9 -ds -lc1024 -ld1024 -ep1 -di -i2 -ed -r -s; -w"temp" -mpzlib+srep64+zcm 
=============================================================================================================================================

srep64+pzlib+zcm

-↓- [ CMD Bench.Test.Info v0.6.9c ] -↓- Compressed Archive Completed At -↓- 18/11/2016 13:18:14
=============================================================================================================================================
 ○ [ ALGORITHM ] ○ [ INPUT SIZE ] ○ [ OUTPUT SIZE ] ○ [ RATIO.% ] ○ [ ARCHIVED FILES ] ○ [ COMP.TIME ] ○ [ SYNTAX - OPTIONS - ARGUMENTS ] ○

             Arc         981,1°MB          693,5°MB        70,69%              1°Files    00:10:52:408   a -ma9 -ds -lc1024 -ld1024 -ep1 -di -i2 -ed -r -s; -w"temp" -msrep64+pzlib+zcm 
=============================================================================================================================================

I do not understand what benefits or on what files with pzlib support, should be inserted the "pzlib" pre-compressor at second reading in a concatenated method ...

Reason this happened is either srep placeds headers between repeated data, maybe but if that's the case then zlib streams are truncated (m3), if I completed pzlib properly, you should get roughly the same size using srep+pzlib+lzma, you'll only gain speed, however, the whole method of srep+precompressor+lzma, backfires as well because a precompressor itself produces more repetitions so if the input is big, you'll lose ratio but you can encounter that by using srep twice.
srep+pzlib+srep+lzma, a very weird method but it should give roughly ratio, obvious that ratio will be a bit bigger but you gain speed.

[felice2011]

A pre-compressor, as rule should be put at the beginning of a method, which alters the content of the file, so that a compressor will get better results, that without pre-compressor ...
Logically everyone can experience any concatenated method, for better compression ratios or best speed of execution, but unaware of a new discovery in a new concatenated method, you can encounter errors during decompression.

Compression :

"pzlib+srep64+lzma" In= 1 GB / pzlib = 2.07GB > srep64 = 2.23GB > lzma = 466MB /T = 00:04:50:48

"srep64+pzlib+lzma" In= 1 GB / srep64 = 1.0GB > pzlib = 1.54GB > lzma = 697MB /T = 00:04:48:45

"srep64+pzlib+srep64+lzma" In= 1 GB / srep64 = 1.0GB > pzlib = 1.54GB > srep64 = 1.65GB > lzma = 685MB /T = 00:05:05:40

"pzlib+srep64+pzlib+lzma" In= 1 GB / pzlib = 2.07GB > srep64 = 2.23GB > pzlib = 0GB > lzma = 466MB /T = 00:05:10:30

************************************************** **************************

Decompression :

pzlib+srep64+lzma = OK - /T = 00:01:18:965

srep64+pzlib+lzma = ERROR

srep64+pzlib+srep64+lzma = ERROR

pzlib+srep64+pzlib+lzma = OK - /T = 00:01:20:59

[ChronoCross]

My tv is smart. You got speed because the first step of the method srep, resuce the size of temp file

[EzzEldin16]

@ ChronoCross
LOL like i don't know that
are you talking to an idiot or something ?

[ChronoCross]

Originally Posted by EzzEldin16

@ ChronoCross
LOL like i don't know that
are you talking to an idiot or something ?

I just say pzilb always goes first, and lz77 pre-prosessor in second place.

EDIT by Grumpy ... No Memes! Leave that crap for Social Media, don't bring it here.

[EzzEldin16]

@chronocross (did you know flac compressor is better than tak and tta for compress wav audio files. Now you learn something. ) i'm not talking about pzlib place in methods