SuperREP (SREP)

SuperREP (SREP) 3.92

Нет прав для скачивания
В смысле замену параметра? Вместо {app} ставите свое значение и все
 
А есть какая-то разница в плане возможностей между исполняемыми файлами для win32/64 и linux? под линуксом если пытаюсь обработать большой файл (более 5-6гб вроде) с такими настройками: -m3 -l512 -c64, srep ругается на невозможность зарезервировать необходимый объем памяти, хотя у меня свободен такой объем + своп есть, ну и там смешные цифры могут быть типа 4гб. Если увеличиваю парметр -с, то требования к памяти снижаются и проблема ичезает, но так снижается и ратио. Использую версию 3.93а.

upd. Проблема заключалась в собственной ошибке. Я использовал исполняемый файл для 32 битной архитектуры, считая что он 64 битный по умолчанию. Взял srep64 и теперь все работает как и задумано.
 
Последнее редактирование:
Доброго здравия Shegorat и спасибо за программу.
Подскажите пожалуйста.
Srep лучше использовать версии 3.2. в 3.9x были ошибки, особенно велики шансы нарваться на ошибку, появившуюся в 3.93
Эта информация всё ещё актуальна на 2022 год?
Заранее благодарю.
 
Эта информация всё ещё актуальна на 2022 год?
Да, учитывая тот факт, что обновлений пока больше не выходило. Булат пока так и не закончил вносить исправления для новой версии. А мне не хватает времени чтобы во всём этом разобраться
 
Да, учитывая тот факт, что обновлений пока больше не выходило. Булат пока так и не закончил вносить исправления для новой версии. А мне не хватает времени чтобы во всём этом разобраться
Shegorat, благодарю вас за ответ.
Очень рад это слышать, потому как, начал использовать версию 3.2. Хотя грешным делом протестил и 3.92 и 3.93a.
Я не сильно понимаю в подобных высоких материях, поэтому в таких вопросах прислушиваюсь к таким людям как Вы,
Булат Зиганшин, ProFrager и другим мастерам с этого форума.
Берегите себя и будьте здоровы)
 
В общем, имеется такая ситуация.
Есть данные из игры Cities Skylines 2 общим размером в 50 гб. Данные внутри сжаты ZSTD. В разжатом виде они весят под 160 гб.
Собственно в чем проблема?
Среп на первом проходе уменьшает эти 160 гб до 85 гб. На втором проходе, на разных процентах он просто отваливается и в результате имею Errorlevel=XXXXXXXXX.
Compressing 166,810,254,275 bytes with srep -m3f -a0/0 $$arcdatafile$$.tmp $$arcpackedfile$$.tmp
SREP 3.92 beta (July 23, 2013): input size 159082 mb, memory used 9553 mb, -m3f -l512 -c512 -a0/0 -hash=vmac -b8mb
100%: 166,810,254,275 -> 95,100,014,539: 57.01%. Cpu 39 mb/s (4074.781 sec), real 35 mb/s (4531.904 sec) 10.0%
Sorting match 10.0% Second pass: 10.0%
Errorlevel=-1073741819
10.0%
ERROR: general (de)compression error in srep
Были перепробованы разные версии SREP c разными параметрами. Ничего это не дало. Как отваливался среп так и продолжает это делать.
Какой прекомпрессор использовать - ZSTDRec или XTool - значения не имеет.
Я этот вопрос задавал на FF, но там помочь не смогли.
Кто что подскажет?
ЗЫ. Примечательно, что самая первая версия игры сжалась без всяких проблем.
ЗЫ2. C ОЗУ и дисками полный порядок. ОЗУ кстати 16 гб. Это так для наводки))
 
@dixen18,
Судя по всему там 0xC0000005. А это Access Violation. Попытка обратиться к участку памяти, который недоступен программе. Есть несколько вариантов
1) На втором проходе идёт активное выделение памяти под индексы, возможно не удалось выделить память но проверки на это нет - отсюда вылет.
2) Косяк где-то в самой программе, идёт переполнение переменной индексации, отсюда кривой расчёт адреса - и в следствие этого Access Violation

Нужно проверить 1-й вариант на машине с бОльшим количеством памяти.

ЗЫ. Ещё можно попробовать увеличть -l до 1024
 
Последнее редактирование:
Hi guys. These are my settings to compress with srep 3.93 beta:

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

I used it for years but only recently I noticed of a problem with srep. It stucks decompressing huge files and the installation folder starts to increse in size with hundreds of GB (and the installer is blocked at the same percentage of the installation) and no error appears. I have to terminate the setup with task manager.

I have encountered this bug with the game "Broken Arrow", it has one file named "e766727c2cfea45ae21d23be6a8005760_1.gtp" (38.2GB).

I tried the decompression of the file "e766727c2cfea45ae21d23be6a8005760_1.gtp" on two different computers, one with ryzen 3800x + 16GB ram + 437GB SSD free space, second computer ryzen 7700 + 64GB ram + 721GB SSD free space.

I solved using xtool with -dd3 parameter instead of the normal srep. In this way the decompression works on both computers.

Another game where I encountered the bug is S.T.A.L.K.E.R. 2 decompressing the file "pakchunk25-Windows.ucas" (34.1GB). The decompression of this files stucks but only on the computer with ryzen 3800x/16GB ram. Also with this game I solved using XTool with -dd3.

I would like to know if I'm using srep with wrong commands/parameters and if you encountered this same problem with it.
 
you don't need to unpack srep yourself) there is CLS-srep for this, in the CLS.ini settings you need to limit memory usage
 
you don't need to unpack srep yourself) there is CLS-srep for this, in the CLS.ini settings you need to limit memory usage
I know. I'm using the same setup/installer from years and yes CLS-srep.dll is included. I always limited the srep decompression memory inside the file arc.ini of the setup and always worked, for years, so I doubt the problem is that.

Edit: I found how to solve the problem. Testing the decompression of the file "pakchunk25-Windows.ucas" from Stalker 2, if I limit the ram usage for the decompression to 10% of my ram (16GB of ram) the decompression stucks at some point. Instead if I limit the ram usage to 50% the decompression works fine without problems. But I don't know why this is happening. Limiting the srep decompression memory to 10% always worked for me in the past.
 
Последнее редактирование:
you can probably take srep_new and use it together with xtool. try it, srep_new also has a trick like using gpu memory when unpacking
 
Назад
Сверху