Srep64 Errorlevel=-1073741819

[mixtro]

Hey guys, so I've been trying to compress Outlast 2 using uelr+msc+srep64+lolz, however the game size flies from 26gb to 39gb. Whenever SREP64 starts compressing, as soon as it reaches the second pass it fails and shows Errorlevel=-1073741819.

Here's the log:

Compressing 40,692,579,062 bytes with "tools\srep\srep64.exe"  -m3f -a2 $$arcdatafile$$.tmp $$arcpackedfile$$.tmp
 10.4%SREP 3.2 (April 6, 2013): input size 38807 mb, memory used 2175 mb, -m3f -l512 -c256 -a2
100%: 40,692,579,062 -> 27,398,243,706: 67.33%.  Cpu 65 mb/s (599.625 sec), real 19 mb/s (2056.522 sec) = 29%
Second pas 10.4%
Errorlevel=-1073741819
 10.4%
ERROR: general (de)compression error in srep64

My system specs are:
CPU: AMD Ryzen 5 2600
RAM: 16GB 3200Mhz

Clock rate is stable/stock.

Srep64 is v3.2.

Could it be that I do not have enough RAM for it to use? 14GB was available. This is the fourth try. Tried placing it in a shorter path "C:\Folder" to see that it might be a character limit, but error still persists.

Any ideas?

[Joe Forster/STA]

That error code converts to hexadecimal 0xC0000005, access violation. Probably a pointer went astray.

[FitGirl]

Use -c512 instead of -c256

[mixtro]

Originally Posted by FitGirl

Use -c512 instead of -c256

Compressing 40,692,579,062 bytes with "tools\srep\srep64.exe" -c512  -m3f -a2 $$arcdatafile$$.tmp $$arcpackedfile$$.tmp
SREP 3.2 (April 6, 2013): input size 38807 mb, memory used 1103 mb, -m3f -l512 -c512 -a2
100%: 40,692,579,062 -> 27,613,438,940: 67.86%.  Cpu 96 mb/s (404.641 sec), real 60 mb/s (644.086 sec) = 63%    %
Second pas 10.4%
Errorlevel=-1073741819
 10.4%
ERROR: general (de)compression error in srep64:c512

I'm going to try with c1024 and srep 3.93 and see how it goes.

[doofoo24]

just use m3f -d1g -a2

[78372]

Do you have enough space in your harddrive?
And use stdout for srep as you use m3f

[mixtro]

Originally Posted by 78372

Do you have enough space in your harddrive?
And use stdout for srep as you use m3f

Yes, I have 700 gigabytes of free space.

I've tested this more than 7 times and at this point I'm just going to skip srep.

Edit: I'll give it one last try with <stdin> <stdout>. Crossing fingers.
Edit2: Srep doesn't work with <stdout>, so I'm just going to split the data in half and move on.

Thanks for your help guys.

[shazzla]

@comp,use tempfiles ! Not stdio.

@decomp, do not use arc.ini/stdout for srep.
Instead it,go for razor's cls-srep.dll.

[78372]

Not stdio. Just stdout.
packcmd = srep64 -m3f $$arcdatafile$$.tmp - <stdout>

[shazzla]

I mean stdin/out..

[ZAZA4EVER]

i notice you are from dubai
if you repack game with arabic files this will make error with you in srep
cause arabic files ,, you must repack arabic files with srep + lolz
dont repack it with uler+srep+lolz
this error appear for me and asked everyone dont solved it , i repack arabic files only without game files ,, repacked well ,,, srep 3.92

[External compressor:lolz]
header = 0
packcmd = lolz_x64.exe {options} $$arcdatafile$$.tmp $$arcpackedfile$$.tmp

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

[External compressor:uelr]
header = 0
packcmd   = uelr.exe uv $$arcdatafile$$.tmp $$arcpackedfile$$.tmp

Bat File Code Patch

@echo off
color 0a

bin\arc.exe a -ep1 -r -ed -s; -w.\tempUelr -muelr+srep:m3f:a16:d1g+lolz:dtb1:d128m:mtt1:mt8:tt8:mc1023:fba0 Data1.bin "1\*"
rmdir /s /q tempUelr

pause

[mixtro]

Originally Posted by ZAZA4EVER

i notice you are from dubai
if you repack game with arabic files this will make error with you in srep
cause arabic files ,, you must repack arabic files with srep + lolz
dont repack it with uler+srep+lolz
this error appear for me and asked everyone dont solved it , i repack arabic files only without game files ,, repacked well ,,, srep 3.92

Unfortunately all my files are in English so that is not the case.
Thank you for posting this, should help me out if I ever decide to include Arabic files.

Just want to update that splitting the archive to 20gb each prevented the issue from happening.