CLS-Srep
 

Hey, tired of greeting y'all with new CLS every time.

Here's another one but for SREP.

Absolutely no drawbacks, you can choose to use CLS for compression and/or decompression.

From my perspectives, it has absolutely no important advantages over the one done by ProFrager but maybe if it runs the srep64.exe there could be some.

It only has one advantage though, it launches srep.exe if system is x86 and if srep64.exe is not present but if you're a 64-bit user and have srep64.exe nearby, it will use it and 64-bit gives that 30% or so boost I think...

Enjoy!

Is srep.exe and srep64.exe are exchangeable, i mean if we compress through srep64.exe and decompress through srep.exe, is it possible with this vls?

Yes it does. Even u cn unpack without cls nd with smooth progress too bt it has been seen that profrager cls is faster

Could you give a link for CLS by profager?

That's true, there isn't a middle man with ProFrager's CLS which is why it is fast, the only problem I have with it and the reason I created this CLS is because of x86 limitations, Freearc is x86 which means the CLS must also be x86 for them to be compatible and since there is no middle man it means DLL itself will be limited to how much RAM is supported by x86, which is mainly 2GB, 4GB after patching it, I have repacked GTAV using reflate+srep+lzma
46.7GB became 105GB then after that, wrote this after processing the 105GB file.

Decompression memory is 602 mb. // it was 11GB actually, 602 mb is just a quoted example, once it says 11GB, just know that a virtual temp file will be created and just know that the whole thing will be slow during decompress because srep couldn't allocate 11GB because of x86 limitations even if you had 20GB free ram at the time, this CLS however solves that problem, it will let srep use 11GB ram, the DLL is x86, but the exe it uses is x64.

Hello Mate, I found a bug in CLS-Srep, here are one screenshot of that -

http://image.prntscr.com/image/d4d22...def1441e97.png

I get the batch file with the real progress in the setup!

I have attached the files and setup!

This isn't a bug

If its not a bug, then can you please tell me fix for that?

If it isn't a bug then how can u say u need a fix for that

Man, even i know that it needs only few coding to hide that bar from razor in delphi, i mean from bug that only to hide that, nothing more!

try this, I forgot the highlighted part.

:o

i think you archive is damaged.try recompressing the bin/cab that is damaged.

Problem fixed bro! Thanks for the update ;)

Is great . Thanks Razor12911

Is it possible to have a Multi Tasking srep? Like precomp?

Srep just needs a good drive, it isn't slow at all.

I am asking because I know 2 guys who compressed same data (20 GB), with srep+lzma on SSD and the first one packed this data in approx. 40 mins. the second one in approx. 2 hrs. And the unpacking time for the first one is about 5 mins with heavy load on CPU and DISK DRIVE whilst for the second one is about 20 mins, both on SSD. I wanted to take a look in the temp folder to see what files are generated by the setup, but they seem to be hidden. So, any ideas on this one?

RAM also needs to be considered.

RAM is 1GB during unpacking. I still can`t understand what the first guy is using, but he is definitely using something :D So my thought was that he`s been using something like precompmt but with srep instead.

Dude, there are programs that need the technique of precompmt, srep isn't one of them. For example, I made zstd multi threaded but it was only during compression, during decompression, it's like a disk is capable of 3gbps I/O, if the program itself suffers IO bottleneck from this, it doesn't mean multi threading will fix it, instead if you try to make it multi threaded, either you get 5% more speed which is not much or you lose speed overall.

Plus with regards to srep and different time taken, firstly the hardware is probably different, srep is single threaded, first guy might have had i7, second guy might have had a weaker CPU, secondly RAM, srep operates mostly using RAM, if ram speed is high, it equals to more speed, secondly with regards to ram too, bigger the better, this will make windows not adjust itself to keep system alive, those adjustments actually contribute to bottleneck, SSDs as well are also different. Too many variables, but all depend on hardware, SrepMT will not solve this. It's like trying to make wheels of an airplane work while on midair, those wheels will just spin but they will make little or no difference whatsoever.

srep doesn't need multithreading. or, srep is m/t already, but second thread is only 10% or so of the main one. and srep offloads i/o to separate thread

let's see - in -m3 mode, you can use higher -a value to boost speed. with -a16 i get >500 MB/s - much-much fasterthan any lzma

in -m4/m5 mode it has even less computations to perform, but limited by I/O speed. yeah, on SSD multithreading I/O should be a good idea - you are right here

lzma may be multithreaded too, like lzham/rar5

Thanks everyone for the reply. I will test soon.

the best thing is that it works with compression & dec.. unlike the one made by ProFrager it works only in dec.. however i prefere the cls for both :)

i have Problem, i compression Max Payne 3 Only files needd with pZLib version 2 + SREP 3.93 beta + lzma:a1 and after done compression say need 7600mb ram for decompression I want limited ram uesd decompression srep I tried in every way using this and does not help

[External compressor:srep]
header = 0
unpackcmd = srep -mem228b {options} -d -s - - <stdin> <stdout>

[External compressor:srep]
header = 0
unpackcmd = srep -mem512mb {options} -d -s - - <stdin> <stdout>

[External compressor:srep]
header = 0
unpackcmd = srep --mem75% -d -s - - <stdin> <stdout>

or --mem50% or --mem25%

Also edited inside
innosetup

if not SrepInit('',228,0) then break;
if not PrecompInit('',128,PCFVer) then break;
if not FileSearchInit(true) then break;

and Still used more than 5gb ram and I have another problem
why srep withme uesd virtual memory Load on ram not HDD
i want Create virtual memory temp on HDD how do this?

look photos

https://s18.postimg.org/f5yyw9nsp/Untitled.png

https://s16.postimg.org/5viyermsl/image.png

This was happened because you added srep two times in arc.ini remove one of them and everything will be fine again. ;)

No, not the cause of this i used one srep in arc.ini
I unpack file with method this pzlib+srep+lzma:a1:mfbt4:d512m:fb273:mc1000:lc8
by Install Run in innosetup i try with BlackBox_2.5.1 and BlackBox_2.5.0 and Impossible unpack say CRC Check

I think not supported unarc.dll for this method And surely i add

[External compressor:pzlib]
header = 0
unpackcmd = pZLib d -t8 - -o - <stdin> <stdout>

in arc.ini and sill CRC Check

@CAT8K it's normal because u used a16 option which require more much ram
so the bigger the file size the more much ram will require so try a1\a2 instead oh a16 & see if something will change :)

Thanks bro I try with -m3f -a4 or a2 but first i make test on just 2gb files with pzlib Will become up 4gb if come
Fine Then i make mp3 again 21gb with pzlib

I recommend u to use only a1\a2\a16 those are the best I know there are other options but i made many tests & only a1\a2\a16 are the best and most suited to all PCs

after test 2gb with -m3f -a4 size decompression Little by small But that is a very small size
he is l2048 c2048 block size so I decided make 21gb again with -m3f l1024 c1024 -a4
and after done take me 6000mb decompression + Size increase 43mb For the first one
In any case After grief :D and fatigue my hdd for many tests I decided not despair
I looked good inside instructions decompression memory srep The only thing that settle the matter This

unpackcmd = srep -mem25p -d -s -- <stdin> <stdout>

-mem25p = uesd only 2gb ram decompression Now I control ram decompression im very happy :)

Thanks again bro I flouted srep Not check good well on Settings srep like -l -c -a4 8 16
But now, well understood and i will make many tests with srep for get best Settings On large sizes

Thank you Razor12911
Please update it.
CLS-Srep.ini add. CLS-Srep.tmp to APP

Will do as soon as I get back home.

Thank you Razor12911
Please update it.

Patience...

Update available

Since people are really impatient, decided not to spend more time on working on making this cls to switch between this one and the one done by ProFrager for effcient speed when more than 2GB decompression memory is required. You really do lose speed when you use this dll instead of ProFrager's on stuff that does not need a lot of decompression memory, but on stuff that does or might need more, while using regular disk drives, because that's where these virtual temps are created resulting in more IO on disk resulting in slower installations when you do have enough ram for srep. (Just a theory though...)

Anyways, here's the update.

Added srep.dll, this is basically cls-srep by profrager, if dll is found instead of srep.exe, it's loaded instead.

Thank you Razor12911
Good Work:D
http://s8.picofile.com/file/8299537292/SrepCLS_Test.png

Thank you Razor12911

help! Decompressing error