CLS-Srep [Archive] - FileForums

View Full Version : CLS-Srep

Razor12911

16-06-2016, 06:18

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!

Amsal

16-06-2016, 07:55

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?

truerepacks

16-06-2016, 09:39

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

Amsal

16-06-2016, 10:27

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?

Mini

16-06-2016, 10:55

Could you give a link for CLS by profager?

http://krinkels.org/resources/srepinside.2/

Razor12911

16-06-2016, 23:47

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

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.

Amsal

12-07-2016, 05:36

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

http://image.prntscr.com/image/d4d22adec53241e5b155eedef1441e97.png

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

I have attached the files and setup!

truerepacks

12-07-2016, 05:44

Amsal

12-07-2016, 05:54

This isn't a bug

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

truerepacks

12-07-2016, 06:00

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

Amsal

12-07-2016, 06:02

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!

Razor12911

12-07-2016, 11:10

try this, I forgot the highlighted part.

LuzhinE

12-07-2016, 11:37

mikey26

12-07-2016, 12:43

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

Amsal

13-07-2016, 03:34

try this, I forgot the highlighted part.

Problem fixed bro! Thanks for the update ;)

Simorq

04-08-2016, 08:53

Is great . Thanks Razor12911

MCWRX

08-10-2016, 13:12

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

Razor12911

08-10-2016, 13:46

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

MCWRX

08-10-2016, 15:17

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?

Razor12911

08-10-2016, 15:29

RAM also needs to be considered.

MCWRX

08-10-2016, 15:55

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.

Razor12911

08-10-2016, 16:26

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.

Bulat

09-10-2016, 04:56

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

MCWRX

09-10-2016, 13:16

Thanks everyone for the reply. I will test soon.

aswadd

04-11-2016, 13:27

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 :)

CAT8K

22-11-2016, 17:18

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

Amsal

22-11-2016, 17:42

CAT8K

22-11-2016, 18:18

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

aswadd

22-11-2016, 19:53

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

CAT8K

22-11-2016, 20:46

@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

aswadd

23-11-2016, 02:35

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

CAT8K

23-11-2016, 13:46

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

Simorq

17-06-2017, 16:36

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

Razor12911

26-06-2017, 06:15

Will do as soon as I get back home.

LuzhinE

01-07-2017, 23:21

Thank you Razor12911
Please update it.

Razor12911

03-07-2017, 03:16

Thank you Razor12911
Please update it.

Patience...

Razor12911

03-07-2017, 11:15

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.

Simorq

03-07-2017, 12:42

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

LuzhinE

03-07-2017, 21:57

Thank you Razor12911

LuzhinE

22-07-2017, 16:54

help! Decompressing error

EzzEldin16

22-07-2017, 23:34

Write down the error
like that no one can help you

LuzhinE

22-07-2017, 23:53

solved

Simorq

13-08-2017, 05:42

Thanks to Razor12911 and also PrinceGupta2000
ISDone
#ifdef SrepInside
SaveStringToFile(ExpandConstant('{tmp}\cls-srep.ini'), '[srep]'+#13#10+'Decode=-d -s'+#13#10+'Decode64=-d -s -mem75%'+#13#10+'Temp='+ExpandConstant('{app}'), True);
ExtractTemporaryFile('CLS-srep.dll');
ExtractTemporaryFile('srep.dll');
ExtractTemporaryFile('SREP.exe');
ExtractTemporaryFile('SREP64.exe');
#endif

kj911

06-12-2021, 13:52

Please help me identifying this CLS-SREP variants! Downloaded from unknown source.

Files:

CLS-srep.dll: 15 872 byte*
cls_srep_x86.exe: 169 984 byte

*different small copies had 16384/17408 bytes and minimally bigger had 58/87/92k byte sizes.

x64 version EXE its missing. x86 version works on SREP 3.2/3.92 compressed archives.

Edison007

07-12-2021, 23:50

kj911
https://krinkels.org/threads/cls-srep.3646/

kj911

08-12-2021, 04:21

Edison007: I've looked through this thread, but I didn't find the answer to my question there. SrepInside could be the solution to a strange problem. If you had the 64bit version of the 32bit cls-srep.exe variant, you might find out if it could solve the following problem. I attach the incriminated package. What's interesting is that there is no text output for the SREP unpacker.

I was given an installer that works fine with the test data under 32bit Win XP, using SREP 3.92 with the icon version. Also, on 64bit. I have the strange case, using ISDone 0.6 and the base unarc.dll (2014 release), that if I replace the 32MB test file with the real multi-GB archive (2.58GB), I get the strange situation that at 6.65%, the installer simply hangs (it would finish at 25% with the first archive, 4db in total) and the Xtool process just idles. (v0.12 x86) But, this only occurred under 64bit Windows. (Win7 SP1 and Win10) Not on Win XP and it runs fine there. The arc.ini and cls.ini files are configured correctly, because then I would not be able to unpack the archive in the command line window. This was fine under 64bit Windows. With Profrager's cls-rep 0.3.3, this seems fine, my only problem with it is that. I can't limit its memory requirements. 4-500MB more than if I used SREP.exe instead. (~800MB vs. 1200MB) optimized for 1GB of memory.

Also, the installer should be as small as possible, avoiding unnecessary frills (videos, music, etc..), files not used when unpacking. (7.exe/dll, nz, rz, precomp and any more.)