» FreeArc (часть 4)

Цитата:

я попробовал zrle5 на 3 своих тестовых файлах - везде получилось хуже.

Да действительно, на одиночных файлах не получается. Я кажись догадался, в чем дело. Я когда жал каталог windows, zrle стоял до разбиения на солид-блоки. Соответственно, каждый блок содержал в среднем больше файлов, отсюда и получился плюс.

Однако, это навело меня на мысль, может быть имеет смысл ставить некоторые процессоры до разбиения на solid-блоки...

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

Цитата:

проще увеличить размер солид-блоков

это приведёт к соответствующим осложнениям при распаковке, особенно файлов по-одиночке. А то, о чём я говорил - нет.

новая альфа:GUI: option to show/hide hidden files (Hidden/System on Windows and ".*" on Linux) and Ctrl-H key toggling the option
CUI: at the end of program execution, prints "\n" even on Windows
CLS: implemented CLS_INIT/CLS_DONE and cls-*.dll unloading when unarc.dll is unloaded
CLS: pass all parameters to the cls-*.dll, delimiting them with ':' as usual
CLS: now supports execution in directories with non-Latin1 names (and non-Latin1 method names too)
unarc.dll: added encryption support
unarc.dll: in the case of error/UserCancel, wait for all decompression threads to be finished before returning from FreeArcExtract()
unarc.dll: Addons\Unarc-DLL directory now contains readme-rus.txt describing dll usage and examples written in C++/Delphi/InnoSetup
unarc.dll: a lot of changes in FreeArcExtract() callbacks, see readme-rus.txt for details
arc.ini: improved bzip2 support
GUI: опция для показа/скрытия невидимых файлов (с атрибутом Hidden/System в Windows или именами ".*" в Linux) и кнопка Ctrl-H, переключающая эту опцию
CUI: в конце работы печатает "\n" - теперь и в Windows тоже
CLS: реализованы вызовы CLS_INIT/CLS_DONE, cls-*.dll выгружаются перед выгрузкой unarc.dll
CLS: в фильтр передаются все параметры, с разделением как обычно ':'
CLS: теперь cls-фильтры могут загружаться из каталогов с русскими (куитайскими...) именами и могут сами иметь русские имена
unarc.dll: поддержка зашифрованных архивов
unarc.dll: в случае экстренного выхода (при ошибке или по нажатию Cancel) ждёт завершения всех тредов распаковки перед возвратом из FreeArcExtract(), советую выводить в это время на экран что-то вроде "Отмена распаковки..." поскольку это может продолжаться несколько секунд
unarc.dll: каталог Addons\Unarc-DLL теперь содержит readme-rus.txt, описывающий использование dll, и примеры на C++/Delphi/InnoSetup
unarc.dll: множество изменений в колбеках FreeArcExtract(), см. readme-rus.txt
arc.ini: улучшена поддержка bzip2

Цитата:

новая альфа:

надеюсь к финальной версии осталось немного!

PS: Спасибо за двуязычную историю изменений!

Profrager
а precomp оригинальном системные функции запускались напрямую с kernel32/msvcrt?
или так же с packJPG.dll, если нет, то как ты их перенаправил в dll без модификации precomp.exe ?

я к чему все это, к тому что раз cls-precomp использует объекты синхронизации и packJPG подменный чтобы распаковывать "налету"
может как то можно их и упаковывать, потому как при работе прекомпа фал постепенно увеличивает размер (хотя дома та же версия программы ведет себя по-другому, имея размер 0 байт все время перед окончанием)

Цитата:

множество изменений в колбеках FreeArcExtract

->

множество изменений в вызовах FreeArcExtract

это ж вроде по-русски

Vladimyr
Цитата:

множество изменений в вызовах FreeArcExtract

Вызов - это вызов. Колбек - это обратный вызов, типа события.

Bulat_Ziganshin
а CLS_DONE точно вызывается?
у меня что то не пишет нечего

я добавил вот эти строки в simple_codec.cpp

Код:     case CLS_INIT:
        {
            printf("\nInit sample cls\n");
            break;
        }
    case CLS_DONE: //printf("Params: %s",param);
        {
            printf("\nDone sample cls\n");
            break;
        }

kalpak
Цитата:

а precomp оригинальном системные функции запускались напрямую с kernel32/msvcrt?
или так же с packJPG.dll, если нет, то как ты их перенаправил в dll без модификации precomp.exe ?

напрямую с kernel/msvcrt. Когда загружается моя подставная дллка, она правит ссылки на системные функции в основном ехешнике, и перенаправляет на свои. По идее подобным образом можно сделать универсальный cls фильтр для любого пакера/анпакера, с единственным условием, что он не будет использовать fseek (или SetFilePointer). Или по крайней мере не перемещать указатель вне буфера cls фильтра (~несколько мегабайт). precomp отличается от обычных пакеров, т.к. он может патчить свое распакованное добро парой байт далеко за сотней мегабайт сзади.


Цитата:

я к чему все это, к тому что раз cls-precomp использует объекты синхронизации и packJPG подменный чтобы распаковывать "налету"
может как то можно их и упаковывать,

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


Цитата:

а CLS_DONE точно вызывается?
у меня что то не пишет нечего

CLS_DONE вызывается в самом конце, перед завершением процесса (по крайней мере в unarc.dll так). Попробуй MessageBox поставить вместо printf, авось покажется.

kalpak
CLS_DONE вызывается только из UnloadDLL(), выполняемой перед выгрузкой unarc.dll. можно сделать иначе, просто пока не надо было

какие у тебя задачи?

Profrager
Bulat_Ziganshin
да я просто пока на работе сидел хотел проверить эти вызовы.
а так я думал может как то можно сделать посредника внешних упаковщиков, но вот если он будет перемещать указатель то тут конечно труба, хотя такое наверное не часто встретишь

просто не нравится смотреть как выходной файл растет а ты должен сидеть и ждать окончания операции (а дома проц/хард медленные еще дольше ждать приходится)

а насчет CLS_DONE, dll не пользовался, только [un]arc.exe

протестировал сейчас сжатие в zip:

Z:\vhd>Arc.exe -tzip a a.zip -t
Compressed 1 file, 98,420,528,640 => 47,215,067,186 bytes. Ratio 47.9%
Compression time: real 495.72 secs. Speed 198,540 kB/s
Testing time: real 823.18 secs. Speed 119,561 kB/s

т.е. упаковка работает быстрее распаковки

Bulat_Ziganshin
Булат, а как на счет предварительного теста всех методов сжатия, который я описывал выше? Это совсем не актуально?

Цитата:

kalpak
Слушай, а как думаешь, можно ли сделать тест всех вариантов? Ну прям к примеру сжимаешь 20Гб, ставишь на ночь - он у тебя проходится всеми возможными комбинациями, после каждой проходки архив удаляется, чтобы не засорять хард - потом выдается отчет - время, размер на выходе и выигрыш.
Bulat_Ziganshin
Булат, как ты на это смотришь?

а я тут причём? делай

Bulat_Ziganshin
Ахаха, я же не кодер. Был бы программистом - сделал бы для себя. Я имею в виду - опционально встроить это в архиватор.

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

Bulat_Ziganshin
Смотри, к примеру мне нужно сделать репак - и просчитать какой метод сжатия в FreeArc выгоднее всего. Соответственно я выбираю файлы для упаковки, ставлю опцию "Тест сжатия" и ухожу. В это время он пробегается по файлам всеми возможными комбинациями и записывает это в таблицу сравнения, после чего я делаю вывод и выбираю для себя оптимальный вариант.

типа того есть в UPX ( в precomp вроде то же брут но на определенном потоке) кажется
но там то другая ситуация
там размер не большой файла

а твой репак долго делаться будет каждым из методов
проще сделать батник

хотя, тогда надо будет знать какие методы комбинировать и как

kalpak
Ну да, вот я и думаю, что было бы удобно в FreeArc реализовать подобное. Ну ничего, что долго, зато автоматизированно и в итоге оптимальный результат

Цитата:

хотя, тогда надо будет знать какие методы комбинировать и как

Когда-то на форуме видел сообщение автора Ultra7z и, по его словам, он хотел сначала написать пограмму типа UltraFA, но остановился на Ultra7z, т.к. ему было проще разобраться с опциями 7-zip, чем с FreeArc.

ruduk
ну так потому как в 7z только lzma,ppmd эффективны да и нету там возможности подкл. внешние архиваторы.
а тут очень гибкий архиватор
ну наверное кроме ppmd для текста и lzma для остального хватит, правда тут еще есть препроцессоры разные так что все равно сложная задача

kalpak
У меня была идея чтобы (перед сжатием) анализировать какие у сжимаемых файлов расширения и, на основе этого анализа, составлять "свой" arc.groups, в котором были бы только расширения файлов, которые сжимаются, и методом перекидывания определенных расширений файлов между группами $text, $binary, $default, ... каждый раз сжимать FreeArc'ом методом [-max] и с отключенной опцией "Авто-определение типов файлов".
Сжимать сразу файлы всех расширений не нужно, сжимать сначала только файлы какого-то одного расширения.
Наименьший архив даст "правильный" arc.group -файл, в котором можно будет увидеть в какой группе были те или иные расширения файлов, что поможет выбрать наиболее эфективные цепочки методов.
Потом переходить к другому расширению... вроде того как работает Ultra7z.
Конечно никакого анализатора я не писал (ибо незнаю как), я просто сжимал пару раз одни и те же файлы, но расширения сам вписывал в разные группы. Выигрыш в размере архива получался в лучшем случае от 2 до 3 % меньше по сравнению с сжатием, когда опция "Авто-определение типов файлов" была включена. А в остальных случаях даже 20% увеличение размера.
Т.е. то, как сжимать файл, пускай выбирает сам FreeArc.

Bulat_Ziganshin
Насколько я понял ФА определяет тип файлов по их расширению, но часто расширение файла не совпадает с его содержанием.
Но есть такая утилитка которая независимо от расширения правильно определяет тип файла, если ее интегрировать в ФА то можно просто получить халявный прирост сжатия.

Очень хотелось бы увидеть ее в ФА, хотя бы опционально. Что скажите?

vasulpr
ФА использует файле групп
а то что с расширением xxx имеет тип не подходящий для группы - это разве проблема архиватора
это хитрость и проблема пользователя, хотя я не знаю когда бы это расширение не совпадало с его содержимым
даже если .dat файл это фильм или не фильм то для него используется lzma
откуда такой пессимизм ?можно примеры, которые часто встречаются, потому как для редких случаев это не реентабельно

тем более можно самому предложить свой файл групп или изменить существующий
а ФА делает анализ но только кажется на проверку мультимедия

или же не надеется на архиватор и самому прописать метод сжатия

vasulpr
Булат знает что такое TrID - http://forum.compression.ru/viewtopic.php?p=3799#p3799

Цитата:

Но есть такая утилитка которая независимо от расширения правильно определяет тип файла

К сожалению она не может идентифицировать даже FA SFX архивы, ибо нет сигнатур для них в базе.

а нельзя сделать так чтобы при использовании внешних упаковщиков
можно было указывать уже готовый файл с данными
т.е. например precomp создает файл file.pcf
а мы его просто используем в цепочке методов типа такого:
arc a -mprecomp:slow+lzma:fast:128:64mb:mc100 -pfl1:file.pcf
где 1 - это порядковый номер метода сжатия в цепочке алгоритмов
и тогда можно будет ен ждать каждый раз пока например прекомп или среп сделают свою работу
а просто хранить эти файлы
чтобы например потом проверить на них другой метод сжатия (после внешних упаковщиков)

тем более совместно с PrecompInside и SrepInside будет выигрыш в распаковке таких архивов

сделал сервер для загрузки файлов напрямую на мой комп: http://freearc.no-ip.org:8080/

http://freearc.no-ip.org:8080/ --> http://localhost:8080/!HFS/~upload

Цитата:

Firefox can't establish a connection to the server at localhost:8080.

или же там что-нибудь с логином и паролем ?