Decompressing problems

[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.

[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.