ERROR: write error <disk full?> in compression algorithm pzlib

Pipocooling

Участник
Обрабатываю папку с файлами размером 2.39 ГБ через pZlib v3
В arc. ini прописано packcmd = pZLib e -m2 -c256m -t2 - -o - <stdin> <stdout>

посл обработки 6.6%, через секунд 30 выдает ошибку ERROR: write error <disk full?> in compression algorithm pzlib

Обрабатываю те же самые файлы с тем же arc. ini, но через pZlib v2, и все проходит успешно, никаких ошибок.

Кто сталкивался с такой ошибкой ? и почему с pZlib v3 выдает её а с pZlib v2 все нормально ?
 
Последнее редактирование:

Pipocooling

Участник
Какой алгоритм используется после pzlib?
В обеих случаях один и тот же
Код:
*** data.bin "pack\*"
но это тут не причем, всего-то из-за замены pZlib v2 на pZlib v3 выдает эту ошибку
на диске 100 ГБ свободного места, оперативки более чем достаточно, как может со старой версией место хватать а с новой нет o_O
 
Последнее редактирование:

L-e-o-N

Старожил
Попробуй написать <stdout> вручную, какая команда используется для srep?
 

L-e-o-N

Старожил
как это вручную ? если можно сразу пример

для srep
Код:
packcmd = srep64 -a1 -mem256m -m5f -l256 $$arcdatafile$$.tmp $$arcpackedfile$$.tmp
на клавиатуре в английской раскладке набрать <stdout> (без копипаста), у меня похожая проблема из за копипаста была, когда я набрал все вручную все заработало.
На диске E достаточно памяти?
 

Pipocooling

Участник
L-e-o-N, хотя у меня тоже самое попробовал, но результат тот же, попробовал еще без <stdin> <stdout>, с v2 все четко с v3 ошибка




мистика какая-то :scare:
 
Последнее редактирование:

Pipocooling

Участник
L-e-o-N, если не сложно можешь скинть свой готовый вариант со всеми файлами, батником и arc.ini, а то смотрю больше некому помочь
 

L-e-o-N

Старожил
L-e-o-N, если не сложно можешь скинть свой готовый вариант со всеми файлами, батником и arc.ini, а то смотрю больше некому помочь
Файлы скинуть могу, а батником я не пользуюсь. Сдесь на форуме я выложил программу GamePacker я использую ее, сейчас обновлю версию и скину ссылку.
 

vint56

Ветеран
Проверенный
Pipocooling, попробуй так
arc.exe a -ep1 -r -ed -s; -w.\temp -mpzlib+srep+4x4:b100mb:lzma:a1:mfbt4:d50m:fb273:mc10000:lc8 data.bin "pack\*"
 

Pipocooling

Участник
vint56, попробовал, та же беда, попробовал и без 4x4:b100mb, v3 с параметром -c256m тупо отказывается работать пробовал поставить -c64m работает, но результат сжатия очень плохой, выше 64 на начальном этапе выдает <disk full?>
 

vint56

Ветеран
Проверенный
Pipocooling, у тебя памяти не хватает для сжатия

Here are some tips guys:

-The increment of -c# does give better output, but uses more memory, pzlib will reach 40GB ram usage if you set it up like an idiot, 16MB is the default value, there are very less inputs that will need a higher value like for example, Mad Max will need something like 256MB-320MB, GTAV with 128MB is fine, and DOOM needs something like 600-700MB to catch the most biggest stream I've ever seen.

-If you still want to get all the streams that a game has but you want to lower down the RAM usage as I explained with "-c#" then you have to adjust -st# scanning threads assigns the number of threads to scan data with, more threads = more speed = more ram usage, size is maintained whichever number you set here but speed and memory usage isn't.

-the fast verification option, this does break CRC sometimes, it quickly determines ways of precompressing data, it has a 95% accuracy, the other 5% is when it breaks CRC, you should use this when you use -m1 as method, with m2, accuracy goes down to 70%.

-decompression memory, well pzlib is actually not memory hungry, it all depends on what settings you used when encoding so, you might wonder if pzlib used 12GB memory when encoding, how much memory is it going to need for decompression. Well this is how you calculate, you must find out what ratio was the data inflated to, let's say GTAV for example, you used -c128mb and pzlib ended up using 8GB memory for encoding, pzlib encoded 47.6GB and made it become 95.7GB for example, the ratio is 201%. to calculate it's chunk size (-c128MB) multiplied by 2.01 which is 256MB, that's roughly the memory which will be used, things like IO buffer and processing memory will make it roughly 300-350MB as a result.

-this last version utilises raw2hif_dll.dll and hif2raw_dll.dll, these are reflate functions, the moment you place them near pzlib.exe, pzlib utilizes them and switches off internal functions, I ran many benchmarks, the usage of these libraries make pzlib slower than when it's using internal functions, however, with DOOM, you really don't have a choice but to use them because internal function cannot process the streams that game has, this is why precomp and pzlib v2 never works on that game, however I blended the internal functions with reflate to give the same size when reflate is used alone but more speed, meaning the best method to use when using pzlib is pzlib -m2 -x...., "-x" gives a better output than pzlib alone.

-for DOOM and some games that pzlib fails to process, remember I created ZlibChecker, you can first use this program to see what size should you really get and pzlib must give that output. for example, zlibchecker might report that 20GB became 37GB, but when you use pzlib, pzlib gives 21GB as inflated size, actually this is what happens when you use pzlib on DOOM, then you have to use "-s" for those special streams because clearly the game has special deflate streams. For DOOM, the best method you can use is -m2 -c640m -x -s -r9....
 
Последнее редактирование:

Pipocooling

Участник
vint56, перед ошибкой 10ГБ свободной памяти, да и вообще в таком случае почему тогда при аналогичных параметрах с pZlib v2 хватает, а с pZlib v3 не хватает ? если реч о диске, то на диске 100ГБ свободного места, а пакет файлов разжимается до 4.5 ГБ
 

Pipocooling

Участник
vint56, спасибо заработало с экзешником x64, а я думал запакованный архив через pZLib.exe x64 нельзя потом распаковать через x86 экзешник при установке.
 
Сверху