» FreeArc (часть 4)

cdman67

Цитата:

Устойчиво работает с вышеуказанными опциями, жалоб и нареканий нет. Правда, статистика пока слабовата - пару репаков всего лишь (FA 0.67 + SREP 2.96 + ISDone 0.6), но тем не менее...

странно, а у другого репакера вот наоборот юзеры через один писали об ошибке crc.

Цитата:

странно, а у другого репакера вот наоборот юзеры через один писали об ошибке crc.

367 скачавших на данный момент - и ни одного нарекания - это о чём-то говорит ? Согласен, что один репак - это не показатель, но что имеем, то и имеем. Бум нарабатывать статистику дальше )))

Aerogiz


Цитата:

Встроенный во FreeArc SREP работает хуже чем отдельный?

В FreeARC нет встроенного SREP. Там есть REP. Поэтому когда ты пишешь -msrep и в arc.ini отсутствует секция srep, то srep просто игнорируется и ты получаешь просто
exe+delta+lzma:512mb:normal:bt4:273:lc8


Цитата:

Уже много сжимал различные данные сначала цепочкой SREP 2.95 (с параметром -m3 -l512)

-m3 -l512 используются по умолчанию, так что можешь их не указывать и сэкономить время.


Цитата:

а затем FreeArc 0.666 (с параметром delta+exe+lzma:512mb:normal:bt4:273:lc8)

У тебя неправильная строка. Ты хочешь использовать match finder BT4 со словарем в 512 mb, что невозможно. При BT4 и словаре больше 64 mb используется примерно 10.5 x d памяти, где d - это размер словаря. А так как FreeARC является 32-битным приложением, то выделить 5375 мегов памяти не выйдет по определению. Поэтому FreeARC просто понизит размер словаря и ты получишь
delta+exe+lzma:177mb:normal:bt4:273:lc8, а ведь можно задрать и побольше.

Highpass спс за очень подробный ответ

shidow
не бери в голову - скорость может меняться в процессе, поскольку зависит от многих причин - характера сжимаемых данных, их расположения на диске, фазы сжатия и т.д.


Цитата:

пару репаков всего лишь (FA 0.67 + SREP 2.96 + ISDone 0.6), но тем не менее...

интересна статистика - сравнивал srep с rep на них? распаковка идёт без временных файлов? какая скорость процесса распаковки в общем достигается?

кстати, натолкнулся при перепаковке LostPlanet2 на интересный приём. там после SREP данные уже почти не ужимаются, процентов на 10 с lzma:max:256m всего. из-за этого распаковка в lzma идёт довольно медленно - если обычно на моей тачке можно получить 40-50 мб/с, то там порядка 20, что гораздо медленней скорости чтения/записи дисков. пробовал tornado - он быстро распаковывает, но теряет в сжатии. зато если заменить lzma на xlzma:max, то получается самое то - распаковка становится в 2-4 раза быстрее за счёт многопоточности, а степень сжатия почти не падает

Добавлено:

Цитата:

у другого репакера вот наоборот юзеры через один писали об ошибке cr

skymmer на английском форуме тоже сообщил что в stdin-to-stdout mode данные считываются не до конца. как минимум в этом проблема. плюс ещё неясности по порче памяти

Добавлено:
добавил в шапку Форум Krinkels Inc

Bulat_Ziganshin

Цитата:

skymmer
So. -m1 processing

ды с -m1 (-msrep:m1f:s250m) упаковка проходит корректно
но с распаковкой проблемы и у FreeArc и у Arc

Цитата:

ОШИБКА: ошибка записи (диск полон?) в алгоритме (рас)паковки srep:m1f:s250m

4 репака - полёт нормальный
упаковка - arc a -r -di+$ --display -mt2 -s -w. -m=srep:mem75%%-150mb:f:a1:l128:c128+lzma:128mb:max:1024:bt4 -dpE:\WORK\SOLYANKA ns2011.arc

2 Bulat_Ziganshin:

Не знаю поднимался ли вопрос, но я в него уткнулся - EXE-архив НЕ распаковывается под NT4 (Service Pack6 ENG)

Понятно, что эта операционка уже почти раритет, но как всегда, в самый неожиданный момент...

cdman67

Цитата:

-m=srep:mem75%%-150mb:f:a1:l128:c128+lzma:128mb:max:1024:bt4

А что это за параметр 1024 ты задаешь? Уж не fb ли ?

Highpass, ну да, и что ?

cdman67
Да ничего. Просто ты заблуждаешься, считая что такое значение параметра FB допустимо.
FB имеет диапазон от 5 до 273 (ранее до 255) включительно.

Цитата:

FB имеет диапазон от 5 до 273 (ранее до 255) включительно.

ранее было 256, если не изменяет память.

Изменяет
Диапазон был расширен до 273 в версии 7-zip 4.30 beta. А вот выписка из файла помощи версии 4.29

fb={N}
Sets number of fast bytes for LZMA. It can be in range from 5 to 255. Default value is 32 for normal mode and 64 for maximum mode. Usually big number gives a little bit better compression ratio and slower compression process.

Чтобы уже наверняка.

Highpass, да хз, чисто экспериментально выяснил, что при 1024 лучше жмёт - ненамного, но, как гриттся - мелочь, а приятно.

egor23

Цитата:

Результат получается битый, т.е. архив должен был получиться 74МБ, а получился 40Мб
причём в папке темр временный файл получается 74МБ, т.е. srep отрабатывает правильно, а вот в архив попадают не все 74МБ, а только 40МБ.

попробуй с этой версией:

http://www.freearc.org/download/research/srep296b.zip

напомню, что речь шла о работе в режиме stdin-to-stdout

Bulat_Ziganshin

Цитата:

;options = mem75%-400mb (for decompresssion with srep+exe+delta+lzma:256mb)
packcmd = srep {options} <stdin> <stdout>
unpackcmd = srep -d {options} <stdin> <stdout>

Упаковка работает

arc a a296b -msrep:m3f:s250m pdf.TAR11.pcf
FreeArc 0.67 (March 18 2011) creating archive: a296b.arc
Compressed 1 file, 249,562,113 => 77,720,120 bytes. Ratio 31.1%
Compression time: cpu 2.13 secs, real 37.56 secs. Speed 6,644 kB/s
All OK

Распаковка с {options} не работает

Цитата:

unpackcmd = srep -d {options} <stdin> <stdout>

arc x a296b
FreeArc 0.67 (March 18 2011) extracting archive: a296b.arc
Extracting 1 file, 249,562,113 bytes. Processed 0.0%
ERROR: write error (disk full?) in compression algorithm srep:m3f:s250m

Распаковка без {options} работает

Цитата:

unpackcmd = srep -d <stdin> <stdout>

arc x a296b
FreeArc 0.67 (March 18 2011) extracting archive: a296b.arc
Extracted 1 file, 77,720,120 => 249,562,113 bytes. Ratio 31.1%
Extraction time: cpu 1.94 secs, real 5.88 secs. Speed 42,479 kB/s
All OK

Я правильно понял, что FreeArc в zip не сжимает? и не конвертирует?

1ANP
версия 0.666 - нет. версия 0.67 - сжимает, но с ошибками. если очень нужно, надо поставить 0.67 и заменить в ней 7z.dll на стандартную от 7-zip

SREP 2.97 release candidate:

* show original/compressed size with commas: 1,234,567
* -mem75p made equivalent to -mem75%


bugfixes:

* fixed bug in compression from stdin
* fixed crashes when decompressing corrupted data
* fixed crashes when real filesize is larger than one specified with -s


Recommended sections for arc.ini:

This section is optimized for srep:f (future-lz) compression, therefore compressed data are sent immediately to stdout:

Код: [External compressor:srep]
packcmd = srep {options} $$arcdatafile$$.tmp - <stdout>
unpackcmd = srep -d {options} - - <stdin> <stdout>

Bulat_Ziganshin

Цитата:

SREP 2.97 release candidate

[more=Упаковка "не проходит"..]
Упаковка с новыми рекомендациями "не проходит"


Цитата:

packcmd = srep {options} $$arcdatafile$$.tmp - <stdout>

arc a a297 -msrep:m3f:s250m pdf.TAR11.pcf
FreeArc 0.67 (March 18 2011) creating archive: a297.arc
Compressing 1 file, 249,562,113 bytes. Processed 75.8%
Compressing 249.562.113 bytes with srep -m3f -s250m $$arcdatafile$$.tmp -
48 mb, -m3f -l512 -c256 -a4
Compression ratio: 234,881,024 -> 72,710,139: 30.96%. Cpu 25.653 mb/sec, real 20.798 mb/sec
ERROR! Input file is larger that filesize specified

Errorlevel=3

ERROR: general (de)compression error in srep:m3f:s250m


Цитата:

packcmd = srep {options} $$arcdatafile$$.tmp $$arcpackedfile$$.tmp

arc a a297 -msrep:m3f:s250m pdf.TAR11.pcf
FreeArc 0.67 (March 18 2011) creating archive: a297.arc
Compressing 1 file, 249,562,113 bytes. Processed 100.0%
Compressing 249.562.113 bytes with srep -m3f -s250m $$arcdatafile$$.tmp $$arcpackedfile$$.tmp
48 mb, -m3f -l512 -c256 -a4
Compression ratio: 234,881,024 -> 72,710,139: 30.96%. Cpu 25.222 mb/sec, real 20.708 mb/sec
ERROR! Input file is larger that filesize specified

Errorlevel=3
Compressed 1 file, 249,562,113 => 249,562,114 bytes. Ratio 100.0%
Compression time: cpu 2.73 secs, real 14.63 secs. Speed 17,064 kB/s
All OK
[/more]

Добавлено:
-msrep:m3f:s250m

Упаковка проходит при
packcmd = srep {options} <stdin> <stdout>
packcmd = srep {options} - - <stdin> <stdout>

Распаковка проходит
unpackcmd = srep -d {options} - - <stdin> <stdout>

Распаковка не проходит
unpackcmd = srep -d {options} <stdin> <stdout>

пищит динамик ПК, "данные в консоль идут"

egor23
блин, глупая ошибка, попробуй с s260m

Bulat_Ziganshin

Цитата:

блин, глупая ошибка, попробуй с s260m

пробывал и 350 и 550 тоже самое
и без -s, тоже выскакивает

Цитата:

пищит динамик ПК, "данные в консоль идут"

прошлым летом разбирался с пайпом и имел те же проблемы в своей проге, этим кстати так же грешат [ccmx, tak, rar], по крайней мере на тот момент. Думал, раз эти не могут нормально, то и рыпаться не стоит. Но когда заметил что в 7-zip отсутствует это бадяга, пришлось изучить вопрос детальней, на WinAPI есть функция GetFileType, которая позволяет мониторить такие ситуации. Мне по крайней мере помогло.
http://msdn.microsoft.com/en-us/library/aa364960%28v=vs.85%29.aspx

GetFileType - хорошо, только не портабельно. есть стандартная isatty

в 2.97 глупейшая ошибка, из-за которой она с файлами вообще не может работать а с stdin только если указать в -s больший размер файла. в общем, подождите 2.98

Bulat_Ziganshin
Планируете ли вы добавить в среп работу с папками?

vasulpr
нет, я планирую интегрировать алгоритм srep в fa, а пока советую использовать srep через arc.ini

SREP 2.98 release candidate:

* fixed the stupid bug
* improved calculation of output filesize in -m1f mode

напишите пожалуйста инструкцию как использовать srep через arc.ini как можно подробнее, желательно с готовым arc.ini

vasulpr
Как ты думаешь, зачем внутри архива лежит файл readme.htm ?
Кстати тебе еще понадобится редактор текстовых файлов с поддержкой перевода строки 0x0A, ибо notepad понимает только 0x0D 0x0A