Decompressing problems
 

hi
i was trying a method [srep64+pzlib:m3f:a64:d1g+nz] it compressed assassins creed unity 43 gigabytes to 20 kilobyte archive the archive is healthy and i can open it with freearc
the problem is i tried almost all unpacking makers here
but nothing
it either gives an known compression method [srep64] while the arc.ini is clean and good
or don't decompress any thing and exit

[External compressor:nz]
;header = 0 -cc = CM algo -cO=BWT algo ;testing = nz:r:v:cc:m8g:br512m:bw512m:p4:t0:nm
packcmd = nz64 a -r -v -cc -m16g -br512m -bw512m -p4 -t0 -nm $$arcpackedfile$$.tmp.nz $$arcdatafile$$.tmp
unpackcmd = nz64 x -m13g -t8 -p0 $$arcpackedfile$$.tmp.nz $$arcdatafile$$.tmp
datafile = $$arcdatafile$$.tmp
packedfile = $$arcpackedfile$$.tmp.nz

[External compressor:srep64]
header = 0
packcmd = srep64 {options} -m3f -d1g -a2 $$arcdatafile$$.tmp $$arcpackedfile$$.tmp
unpackcmd = srep64 {options} -d -s -- <stdin> <stdout>

[External compressor:pzlib]
header = 0
packcmd = pzlib e -m2 -c1024m -t8 - -o -v $$arcdatafile$$.tmp -o $$arcpackedfile$$.tmp
unpackcmd = pzlib d -t8 - -o - <stdin> <stdout>

PLEASE HELP sorry for my english :D

srep64+pzlib:m3f:a64:d1g+nz :(

srep64+pzlib+nz :D

For AC unity their is no need for any pre-compressor
so basically use this
srep64+xz
or
srep64+nz
or
srep64+zcm

We are in the forum of madness answered once and once again the same question.

@ChronoCross you have to pay some attention for them 'cause someday maybe one of them will be a pro in this field

you just defied the laws of compression.

Wooo :eek: maybe one day we'll get..:cool::D

@rez3vil
i don't know it's like i compressed the data and i'll never extract them
and guys please if you have an answer give it if don't have an answer don't go to any thread which there owner willing to learn and listen to tell him this thread was answered okay then give me the answer :3

any admin please delete this thread my mistake sorry :D

dear aswad. You need to pay attention zlib precompressors goes always first. Also if the compressed file have a few kb the file are corrupted. Is easy and very obvious.

Dear ChronoCross , do i look like a guy who don't know where should i put the pre-compressor :D I rewrite the method to fix only the parameters :D also everyone knows that pre-compressors comes in the first place so no need to tell anyone that .. he is free to use it in the first or middle or even in the end :)

Yeah, but we need to post the right answer or the correct way for compress files to get small size. Hey ezzeldin16 did you know flac compressor is better than tak and tta for compress wav audio files. Now you learn something. ;)

if u get ogg into the scene then the compression is even better

If we are talk about tta tak and flac this compressors are lossless. ogg is lossy you can't go back to the original file.

but the loss in the quality can't be sense

>>dear aswad. You need to pay attention zlib precompressors goes always first. Also if the compressed file have a few kb the file are corrupted. Is easy and very obvious.

Not true always, use delta before reflate u will get better speed with little bit decrease in compression

The result seems to be obvious ...:)

pzlib+srep64+zcm

srep64+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 ...:rolleyes:

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

The first method extracts correctly in 9 min...;) the second method I not tested the extraction...:rolleyes:

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.

Lol all this comments and tests to know the smallest :D 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 !!

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.

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.

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.:rolleyes:

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

;)

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

@http://fileforums.com/image.php?u=21...ine=1415375434 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.

@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 :D