» FreeArc (часть 4)

в одном репаке игры встретил запакованные арком файлы
но открыть его нельзя требует пароль
однако unarc.dll без пароля его распаковал, тогда как freearc/arc/unarc (exe) требуют пароль
проверил сделав архив с паролем и unarc.dll не смог распаковать его
получается тот архив из репака сделал как-то хитро?
что это за хак такой ?

и еще насчет unarc.dll
важно кодировать параметры FreeArcExtract в UTF-8 есkи там только англ/рус. буквы ?
просто у меня проблема использовать его с AutoV3
пишу так


Код: $handle = DLLCallbackRegister ("FreeArcCallBack", "int", "str;int;int;str")
DllCall("unarc.dll", "int:cdecl", "FreeArcExtract", "ptr", DllCallbackGetPtr($handle), "str","l","str","archive.arc")
DllCallbackFree($handle)

Func FreeArcCallBack($what, $pararm1,$param2,$str)
Return 0 ; Return 1 to continue enumeration
EndFunc

я не понял твоего вопроса

Цитата:

нет. может тебе прочесть наконец доку + описание -mc?

да, вот же, уж четвёртый день даже не закрываю, изучаю-экспериментю.
так-то вроде более-менее разобрался что к чему, но этот самый srep меня немного тормозит, хотя желание его попользовать велико (и, если верить, что он ест памяти всего 7-15% относительно размера словаря, то оно мне оч необходимо).


Цитата:

-mc$default+srep:256m

результат - прерывание упаковки с выводом:
Errorlevel=2
17.3%
ERROR: general (de)compression error in srep:256m
скриншот - http://savepic.su/1978392.png (оперативки - 12 гигов, из них свободно почти 10)

А, грубо говоря, если я хочу задать условия, схожие с "-m9x -i2 -lc- -ld-" (т.е., "дать асинхрон" и выжать полный максимум из максимально возможного сжатия), на что следует заменить выделеное цветом?
И осуществима ли здесь асинхронка вообще?

Цитата:

в одном репаке игры встретил запакованные арком файлы

можешь мне скинуть этот архив?


Цитата:

важно кодировать параметры FreeArcExtract в UTF-8 есkи там только англ/рус. буквы ?

для всех, кроме английских - да

Цитата:

вообще в srep есть что улучшить. я например знаю как увеличить скорость сжатия в несколько раз, но кому и зачем это нужно?

ну в общем то не особо нужно, но полезно

Цитата:

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

Ну сейчас в основном пакуют rep(.arc)->srep->lzma, дабы снизить многократные рандомные обращения к винту в момент распаковки srep убрав излишки rep'ом.
Цитата:

тогда получится что временный файл при распаковке не нужен - можно данные копировать напрямую из ранее распакованных файлов. проблем две - первое, тогда из архива нельзя распаковать только часть файлов (или можно, записывая данные пропускаемых файлов всё же во временный файл). второе - цепочка srep+precomp+lzma жмёт хуже, нежели precomp+srep+lzma

тож думал об этом, только проблем таковых не видел) Да и не вижу сейчас 1)как бы не проблема вовсе - не думаю, что кому то понадобится из срепа распаковывать только часть данных, все равно времени это займет не меньше, чем все. 2) дак никто не мешает сначала все (или пофайлово) в прекомп сунуть, а потом srep+lzma пакануть. Я тут ничего проблемного не вижу.
Цитата:

сейчас precomp, как и положено LZ, записывает откуда из истории надо скопировать данные на текущее место

наверное ты имел ввиду srep.
Цитата:

при декодировании данных сразу будут определяться места в выходном файле куда их надо записать. эта идея должна была разрешить проблемы с нагрузкой на кеш диска при распаковке

тока пакер будет небось раз в 10 сложнее текущего)
Цитата:

архиватор при распаковке обычно считает crc распаковываемых файлов для проверки целостности, здесь это придётся делать отдельным проходом

нда, реально проверочный проход был бы лишним..
Цитата:

во-вторых, при кусках данных в 512 байт запись такого куска в выходной файл, я боюсь, может потребовать сначала чтения целого кластера (4кб, а на ssd и все 128 кб)

так и вижу анти-рекламу: srep - убийца ssd В текущей реализации lz винда будет кешировать запись, а там уже фигушки на таких расстояниях..)


Цитата:

я не понял твоего вопроса

фильтр=еще один алгоритм, типа delta, rep и т.д. Хочу алгоритм оптимизации dds'ок попробовать вделать.

Bulat_Ziganshin

Зачем в новой альфе приписывать арку стандартные параметры для прекомпа? Пиши -mprecomp, а оно его в 042 переименовывает и само добавляет парамы. Теперь при распаковке через анарк длл пишет что метод не поддерживается.

вот (49МБ)
только если не открывается смогу залить завтра
у меня на внешние ресурсы скорость 56Кб/с и будет долго заливаться

Цитата:

По теме топика.
Возможно ли реализовать фильтр в ФА с динамически меняющимся размером блока? Т.е. на входе надо детектить необходимый заголовок и соответственно подстраивать текущий блоксайз

да, конечно. на уровне API, предоставляемого FA, есть просто операции "прочитать N байт из входного потока" и "записать N байт в выходной поток". и вообще проще написать прогу, работающую с stdin/out, а затем уже думать о фильтре. может тебе и внешнего фильтра хватит


Цитата:

1)как бы не проблема вовсе - не думаю, что кому то понадобится из срепа распаковывать только часть данных, все равно времени это займет не меньше, чем все

ну а как инсталяции, где можно установить то или это?


Цитата:

2) дак никто не мешает сначала все (или пофайлово) в прекомп сунуть, а потом srep+lzma пакануть. Я тут ничего проблемного не вижу.

проблема в том, что можно srep интегрировать в fa чтобы при распаковке не создавать временных файлов. но только с этими двумя ограничениями. без них - только так, как уже сейчас работает, только exe-шник внещний вызываться не будет

Добавлено:

Цитата:

тока пакер будет небось раз в 10 сложнее текущего)

нет. можно даже сейчас реверсировать файл и сжать его нынешним srep - тогда ссылки на "прошлое" автоматом станут ссылками на будущее ну а затем "реверсировать" выходной файл srep и готово

а распаковку сделать так - в памяти выделяется блок заданного пользователем размера (порядка 500 мб), при распаковке LZ-строк они в него записываются и ссылки на них хранятся в отсортированном по destination offset виде. ну и соответственно используются и удаляются из буфера по мере распаковки файла

если же буфер переполнился, то из него выкидывается *содержимое* наиболее далёких и длинных LZ строк (в надежде что на практике будут выкидываться только строки с длиной >>4кб), при этом:

- если у нас есть физический выходной файл (не stdout) и строка достаточно велика (N*128kb), то мы её сразу на нужное местои записываем
- если у нас есть физический входной файл, то строку просто выкидываем - потом скопируем из него
- иначе - скидываем строку в temp file

ну и вместо самой строки делаем отметочку как мы с ней поступили. когда дело дойдёт до декодирования этого места - поступаем соответственно этой отметке

что тут действительно имеет нехилую логику - так это декодер. зато реализуется вековая мечта человечества - распаковка с 10 гб словарём с буфером в 500 мб


хотя может всё это и не TRUЪ, а правильно - разбить данные на 128 кб куски, посчитать между ними корреляции (тем же самым srep в частности), и затем разложить эти куски в правильном порядке чтобы их дальше уже по человечески ужал обычный lzma

Цитата:

Подскажите, делаю распаковку так unarc.exe x files.arc -pPass -o+ -dpC:\path1
видна консоль, её можно скрыть?

да. спрашивай в теме по своему инструменту программирования


Цитата:

ERROR: general (de)compression error in srep:256m

я mem пропустил - сложно догадаться?


Цитата:

И осуществима ли здесь асинхронка вообще?  

асимметрия != асинхронность. будь внимательней. думай сам вместо того чтобы задавать тривиальные вопросы


Цитата:

Зачем в новой альфе приписывать арку стандартные параметры для прекомпа? Пиши -mprecomp, а оно его в 042 переименовывает и само добавляет парамы. Теперь при распаковке через анарк длл пишет что метод не поддерживается.

можно конкретней, в чём проблема? у меня такой принцип - "precomp042" и т.п. означают конкретные версии precomp, а "precomp" заменяется на "precomp042" или другую свежую версию. это позволяет сжимать с -m=precomp и не думать, какая там сейчас версия последняя - например, не менять батники

единственное в чём возможно я неправ - это надо перенести определение precomp в стандартный arc.ini

Добавлено:
packMP3 v1.0c release

kalpak
скачалось

Цитата:

ну а как инсталяции, где можно установить то или это?

Обычно где есть выбор либо то, либо это устанавливать, архив(ы) с этими файлами на выбор не на столько велики, чтобы для них использовать srep, rep'а хватает. Не знаю, мне пока такое не требовалось на больших объемах данных
Цитата:

проблема в том, что можно srep интегрировать в fa чтобы при распаковке не создавать временных файлов. но только с этими двумя ограничениями.

в любом случае и в цепочке srep->precomp->lzma будут временные файлы...если ты, конечно, прекомп не хочешь в ФА встраивать
Цитата:

без них - только так, как уже сейчас работает, только exe-шник внешний вызываться не будет

и то хорошо
Цитата:

и ссылки на них хранятся в отсортированном по destination offset виде.

представляю сколько времени надо будет декодеру отсортировывать список каждую итерацию..особенно где нить в конце, когда уже записей под несколько десятков тысяч. Тормозить же будет не хило
Цитата:

а распаковку сделать так - в памяти выделяется блок заданного пользователем размера (порядка 500 мб), при распаковке LZ-строк они в него записываются и ссылки на них хранятся в отсортированном по destination offset виде. ну и соответственно используются и удаляются из буфера по мере распаковки файла

подобная идея у меня родилась давно, но даж боюсь браться за такое
Цитата:

а правильно - разбить данные на 1228 кб куски

а почему именно эта цифра?
Цитата:

посчитать между ними корреляции (тем же самым srep в частности), и затем разложить эти куски в правильном порядке чтобы их дальше уже по человечески ужал обычный lzma

это типа xdelta будет с автоматической разбивкой файла на нужные куски и сравнением их друг с другом?

Добавлено:

Цитата:

и вообще проще написать прогу, работающую сstdin/out, а затем уже думать о фильтре. может тебе и внешнего фильтра хватит

кстати заметил такую штуку: lzma_x64 (или как его там) в виде внешнего фильтра один раз из 10 вешает упаковку на 0%. При чем он как бы чего то ждет, не отъедая % от проца. Закрываешь, запускаешь заново - норм отрабатывает.

Bulat_Ziganshin
тот самый случай, когда unarc.dll с пассом "xbn02320797b24x0b1f4h43a7l39b" этот архив распаковывает, а любой arc.exe не могёт. Интересно сколько времени надо, чтобы сбрутфорсить этот пасс для unarc.dll, имея лишь архив упакованный arc.exe с известным паролем, и не разбираясь в исходниках и алгоритмах шифровки..

Цитата:

в любом случае и в цепочке srep->precomp->lzma будут временные файлы...если ты, конечно, прекомп не хочешь в ФА встраивать

precomp вполне может распаковывать stdin->stdout, просто его автор не чешется


Цитата:

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

почитай какую-нибудь книгу про алгоритмы и структуры данных. вставка в упорядоченное дерево/B-дерево/пирамиду - log N


Цитата:

а почему именно эта цифра?

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


Цитата:

это типа xdelta будет с автоматической разбивкой файла на нужные куски и сравнением их друг с другом?

наверно да

Цитата:

я mem пропустил - сложно догадаться?

если досконально знать - то не сложно, а так - увы...
спасибо, поправлю и попробую упаковать

Цитата:

асимметрия != асинхронность. будь внимательней

да, точно.. это уже усталось сказывалась, пардон!

Цитата:

-m9x
не использует rep

а как их тогда можно совместить для максимального ассиметричного сжатия?
(в доке искал, но, правда, в упор не вижу ответа на этот вопрос. по ходу, в 0.40, по которому она написана, этого срепа ещё не было что ль)

Добавлено:

Цитата:

я mem пропустил - сложно догадаться?

только что перепроверил, у меня (оказывается) там c указанием параметров всё нормально, "mem" - на месте:
-m9x -i2 -lc- -ld- -di -mc:rep/srep:mem256mb -ag

Не обращаем внимания

Profrager
этот архив распаковывается вообще без пароля
я проверил FreeArcExtract, просто скинул этот файл туда переименовал с расш. arc и все
он его распаковал
даже можно программой на Delphi воспользоваться
а пароль скорее всего был использован или в ранних репаках или для отвлечения
ну я с ним намучился пока додумался проверить (через vfp9 нельзя было запускать))


Цитата:

Интересно сколько времени надо, чтобы сбрутфорсить этот пасс для unarc.dll, имея лишь архив упакованный arc.exe с известным паролем, и не разбираясь в исходниках и алгоритмах шифровки..

скорее всего тот кто это сделал изучил как работает арк
вот только я не пойму где этот хак находится

Bulat_Ziganshin
По GUI улучшения не придвидятся ?
Показ иконок, поддержка перетаскивания мышью и прочие радости.
Я пока немогу мотивировать всех в компании перейти на FA

new alpha version:arc.ini: removed outdated definitions for exe2 and precomp
unarc.dll: changed meaning of returned value for "overwrite?" and "password?" callbacks; please update your code that makes use of unarc.dll
unarc.dll: full english and russian docs in Addons\Unarc-DLL\readme*.txt
unarc.dll: fixed bug encountered when callback==NULL
SFX/unarc/dll: fixed bugs sometimes preventing extraction of encrypted archives
External: fixed bug - hangup after attempt to execute non-existing external compressor



Новая альфа-версия:arc.ini: удалены устаревшие определения для exe2 и precomp
unarc.dll: изменена трактовка результата, возвращаемого из колбеков "overwrite?" и "password?"; пожалуйста обновите ваш код, использующий unarc.dll
unarc.dll: полная английская и русская документация в файлах Addons\Unarc-DLL\readme*.txt
unarc.dll: исправлена ошибка, возникавшая при callback==NULL
SFX/unarc/dll: исправлены ошибки, иногда препятствовавшие распаковке зашифрованных архивов
External: исправлена ошибка - зависание после попытки выполнить несуществующий внешний упаковщик

это как раз те две вещи, которые в gtk2hs очень сложно реализовать

kalpak
Ссыль на репак можно?

Мб он скачал исходники и поправил их (при открытии требует пасс при распаковке нет), а потом скомпилил?

мдя, жаль ... будем ждать.
сдаётся мне неизбежать перехода на 7z, а затем на FA - как он подоспеет.

Цитата:

ALExey1995

ссылка выше на 1 из архивных файлов

Цитата:

Мб он скачал исходники и поправил их (при открытии требует пасс при распаковке нет), а потом скомпилил?

нет, требует пароль как будто он зашифрован паролем
но dll спокойно его распаковывает, хотя она не меет запароленые файлы распаковывать вообще

Мда,неплохой проект чую как обычно будет пользоватся популярностью ток у продвинутых юзеров готовых пользоватся бетами и альфами

insorg
во времена 0.40 у нас были два основных алгоритма - lzma требует 10*dictsize памяти для упаковки и 1x для распаковки, rep - 1x для того и другого

соответственно было две стратегии:

1) максимальное сжатие при заданной памяти для распаковки подразумевало использование только lzma, в целом алгоритм при этом получался асимметричным (скажем 2.5 гб для упаковки и всего 256 мб для распаковки)

2) максимальное сжатие при заданной памяти для упаковки достигалось применением rep+lzma, при этом те же 2.5 гб обеспечивали 1.5 гб словарь rep и 256 mb словарь lzma, а памяти и для упаковки, и для распаковки требовалось 2-2.5 гб

srep имеет совсем иной профиль памяти - порядка 10% от размера словаря и для упаковки, и для распаковки. соответственно, в твоём случае имея 2.5 гб памяти для упаковки и 500 мб для распаковки, мы можем использовать lzma:256mb плюс srep со словарём 25 гб

Добрый вечер!
Хотел спросить, нельзя ли с делать следующее:
1. чтобы srep сам паковал все файлы в один целый файл, а то просто цепочка, например, 7z (не сжатый) => srep, не всегда удобна для ее распаковки. и можно сделать так, чтобы он был наточен на srep
2. объединить srep + delta, просто как бы цепочка srep => delta, опять таки не всегда удобна

И еще, если кто знает подскажите пожалуйста, здесь.

kalpak
да, все таки пасс тут вписан от балды для отвлечения внимания, видимо. А unarc.dll его распаковывает и без паролей на ура) Но в любом случае на этом архиве висит пароль. Вот только опять же как его можно было так сбрутить для unarc.dll..

slech

Цитата:

Я пока немогу мотивировать всех в компании перейти на FA

А оно надо ?
Зачем менеджеру по экологической обстановке комп ?
Прошло время архиваторов для масс.

Bulat_Ziganshin
т.е., для "lzma:256mb плюс srep со словарём 25 гб" получаем нечто вида:
"-m9x -i2 -lc- -ld- -di -mc:rep/srep:mem2560mb -ag"
, верно?

ndch
надо, разработчики используют WinRar.

Profrager
почему там пароль?мне кажется что просто как то заставили принять пустой пароль при упаковке
потому как там есть aes метод