» FreeArc (часть 4)

Bulat_Ziganshin
Дай пожалуйста пример для запаковки файла срепом версии 2,95 чтоб при распаковке требовалось 128 мб ОЗУ

упаковка: srep -f file
распаковка: srep -d -mem128m file.srep

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

Bulat_Ziganshin
что-то svn не пашет, или он куда-то переместился?

Bulat_Ziganshin
Яжал так srep32.exe -m3 -l32 coalesced.tfc data.srep с срепом 2,95 теперь мне сжимать так

srep32.exe -m3 -l32 -f coalesced.tfc data.srep ?
или просто srep -f file

Добавлено:
Bulat_Ziganshin

Цитата:

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

я 128 мб привёл для примера в среднем планирую использовать 512мб

Bulat_Ziganshin, смените на сайте

Цитата:

FreeArc — планы на будущее
Трекер: список планируемых улучшений по версиям
Версия 0.70 (декабрь 2011)
•полная поддержка zip, rar, 7z и других архивных форматов

А то время потерял пытаясь найти 0.70 для скачивания. и версия 0.67 после установки пишет что появилась что-то новое, но по факту скачать можно её-же..

Цитата:

Версия 0.75
•алгоритм сжатия SREP
•поддержка LZMA со словарём до 1 гб

В версии 0.67 в виде экспериментальных опций включены (работают)?

Что-то не могу сохранить настройки через GUI, при повторном заходе чекбоксы и все остальное по дефолту..
p.s. В идиале было бы приятно видеть автоматическое обновление сабжа как это происходит с лисой, хромом, лунаскейпом (браузеры) и другими безплатными программами.

Цитата:

srep32.exe -m3 -l32 -f coalesced.tfc data.srep ?

да

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

Bulat_Ziganshin
то есть прописывать в arc.ini ?

Добавлено:
дописать вот это ?
[External compressor:srep]
packcmd = srep {options} $$arcdatafile$$.tmp $$arcpackedfile$$.tmp
unpackcmd = srep -d - - <stdin> <stdout>

Bulat_Ziganshin

Цитата:

1. твоим результатам по настройке параметров fb и т.п. я не очень доверяю

Для lzma:fast и lzma:normal поведение существенно отличается. В последнем fb заметно влияет на скорость.

Цитата:

2. предлагаемые тобой методы сжатия требуют много памяти для распаковки

их можно использовать и с другими размерами rep. Правда, эффективность упадет...

Я вообще хочу сказать вот что.
Тестируя с одним размером rep-а, разница по сжатию между последущими tor и lzma очень небольшая (в последнем тесте 2%), они по-существу выполняют роль дожатия. Очень много зависит именно от rep-а.
1. Поэтому для быстрых методов (-m1) нужен именно быстрый rep.
2. Для более сильного сжатия нужен rep с оптимизацией не на скорость, а на сжатие (если такое возможно), как полноправный метод
3. Для ультра сжатия возможно вот что.
У меня часто бывает так: скопировал из интернета прорамму/книгу/музыку, распаковал и оставил вместе с архивом. Или, допустим файл word-а запаковал, отправил по e-mail, да и оставил оба экземляра.
Короче: у меня на компьютере часто хранятся архивы и они же, но распакованные. Возможно, у других пользователей то же самое.
Зачем сжимать 2 раза одно и то же?
Можно модифицировать rep так: он распаковывает в доплнительную область ОЗУ (tempfile) все архивы rar, zip, exe (которые попадают в область сжатия), а "простые" файлы в другую область и сравнивает. Если находятся совпадения, данные в "архивном" ОЗУ не трогаются, а в "простом файловом" дается ссылка на соответствующий архив.
Время займет немало, но, возможно увеличит степень сжатия.
Кто-нибудь такое уже реализовывал?

Добавлено:
Или другими словами, все архивы распаковываются, и используются как словарь.

ALExey1995

Цитата:

то есть прописывать в arc.ini ?

Добавлено:
дописать вот это ?

если ты юзаешь isdone, то используй все как есть, только в начале скрипта раскомментируй #define SrepInside. Настройки для распаковки срепа просто задаешь в SrepInit (все что надо автоматом в arc.ini дописывается).

Bulat_Ziganshin
Цитата:

лучше использовать srep в контейнере .arc - это позволит распаковывать без промежуточных файлов, но требует большей квалификации

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


Добавлено:
и все таки внешнее приложение (srep.exe в данном случае) ищется и в CurrentDir) а не только во временной папке фриарка, переменной path, системном пути и т.д.

Цитата:

А то время потерял пытаясь найти 0.70 для скачивания.

спасибо, исправил


Цитата:

и версия 0.67 после установки пишет что появилась что-то новое, но по факту скачать можно её-же..

считай, издержки альфы


Цитата:

В версии 0.67 в виде экспериментальных опций включены (работают)?  

нет, я это буду делать после выпуска 0.70


Цитата:

Что-то не могу сохранить настройки через GUI, при повторном заходе чекбоксы и все остальное по дефолту..

в диалоге settings всё сохраняется


Цитата:

p.s. В идиале было бы приятно видеть автоматическое обновление сабжа как это происходит с лисой, хромом,

согласен но тут и так много недовольных задержкой с выходом 0.70

Добавлено:

Цитата:

что-то svn не пашет, или он куда-то переместился?

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


Добавлено:

Цитата:

Тестируя с одним размером rep-а, разница по сжатию между последущими tor и lzma очень небольшая

ты на чём-нибудь кроме своего бэкапа тестировал? вот на первом же нормальном файле:

D:\Testing>fazip 4x4:lzma:8m:fast dll100.dll nul
100%: 100,000,000 -> 31,546,433: 31.55% Cpu 7 mb/s (13.868 sec), real 36 mb/s (2.647 sec) = 524%

D:\Testing>fazip 4x4:tor:8m dll100.dll nul
100%: 100,000,000 -> 36,668,388: 36.67% Cpu 28 mb/s (3.354 sec), real 142 mb/s (0.671 sec) = 500%


Цитата:

Можно модифицировать rep так: он распаковывает в доплнительную область ОЗУ (tempfile) все архивы rar, zip, exe (которые попадают в область сжатия), а "простые" файлы в другую область и сравнивает. Если находятся совпадения, данные в "архивном" ОЗУ не трогаются, а в "простом файловом" дается ссылка на соответствующий архив.

блестящая идея, я лично её раньше не встречал

В последних альфах FA внешние упаковщики работают скрыто в GUI.
А обратно это как-то можно настроить?

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

alexseb2007
-ap=dir1 - распаковать файлы только из папки dir1 внутри архива

Цитата:

ты на чём-нибудь кроме своего бэкапа тестировал?

Я не о том.
Я о
rep +tor
rep+lzma
!!!
В том то и дело, что отдельно взятый tor сильно уступает lma, а в связке с rep эта разница становится почти символической.

Цитата:

-ap=dir1 - распаковать файлы только из папки dir1 внутри архива

а в isdone0.6 получится как то задать распаковку из папки в архиве?

Shuld
D:\Testing>C:\Testing\rep\017\fazip rep:64+4x4:tor:8m dll100.dll nul
100%: 100,000,000 -> 32,368,300: 32.37% Cpu 28 mb/s (3.448 sec), real 129 mb/s (0.738 sec) = 467%

D:\Testing>C:\Testing\rep\017\fazip rep:64+4x4:lzma:8m:fast dll100.dll nul
100%: 100,000,000 -> 29,434,451: 29.43% Cpu 7 mb/s (14.492 sec), real 43 mb/s (2.236 sec) = 648%

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

alexseb2007
читаем справку и юзаем параметр ExtractedPath.

Bulat_Ziganshin
http://forum.ru-board.com/topic.cgi?forum=5&topic=34920&start=520#11

Добавлено:
Пытаюсь сделать деинтерливер dds'ок фильтром к фриарку (-mdds+lzma). Вчера мучился с ошибкой, которая возникала при перегонке данных посредством stdin+stdout, фриарк при распаковке писал, что crc не совпадает. При этом в режиме file to file (с временными файлами) все без ошибок извлекалось. Думал может какой косяк в алгоритме буферизации моего exe-шника. Сегодня пришел - все пашет.. Я уныл

В первом случае случае (без rep) разница 5%, во втором - вдвое меньше. Вот об этом я говорю.
А если взять rep +xtor:6:4m:h8m?

во-первых, я считаю разницу от размера сжатых данных. далее - сравни:

D:\Testing>C:\Testing\rep\017\fazip rep:64+4x4:tor:6:8m dll100.dll nul
100%: 100,000,000 -> 31,352,957: 31.35% Cpu 18 mb/s (5.288 sec), real 94 mb/s (1.014 sec) = 522%

D:\Testing>C:\Testing\rep\017\fazip rep:64+4x4:lzma:8m:fast dll100.dll nul
100%: 100,000,000 -> 29,434,451: 29.43% Cpu 7 mb/s (14.492 sec), real 43 mb/s (2.236 sec) = 648%

D:\Testing>C:\Testing\rep\017\fazip rep:64+4x4:lzma:normal:8m dll100.dll nul
100%: 100,000,000 -> 27,779,433: 27.78% Cpu 3 mb/s (31.871 sec), real 22 mb/s (4.293 sec) = 742%


как видишь, lzma:fast находится посредине между lzma:normal и tor:6 и по сжатию, и по времени работы, т.е. обеспечивает формирование равномерной линейки методов. в третьих, в tor встроен упрощённый аналог delta, lzma же надо использовать вместе с ним, и тогда разница становится ещё больше:

D:\Testing>C:\Testing\rep\017\fazip rep:64+delta+4x4:tor:6:8m dll100.dll nul
100%: 100,000,000 -> 31,144,107: 31.14% Cpu 18 mb/s (5.179 sec), real 72 mb/s (1.325 sec) = 391%

D:\Testing>C:\Testing\rep\017\fazip rep:64+delta+4x4:lzma:8m:fast dll100.dll nul
100%: 100,000,000 -> 28,523,697: 28.52% Cpu 7 mb/s (13.634 sec), real 40 mb/s (2.357 sec) = 578%

D:\Testing>C:\Testing\rep\017\fazip rep:64+delta+4x4:lzma:normal:8m dll100.dll nul
100%: 100,000,000 -> 26,980,494: 26.98% Cpu 3 mb/s (31.637 sec), real 22 mb/s (4.435 sec) = 713%

Цитата:

alexseb2007
читаем справку и юзаем параметр ExtractedPath.

спасибо! уже разобрался

получается такого вида - if not ISArcExtract ( 0, 0, ExpandConstant('{src}\data.arc'), ExpandConstant('{app}'), 'dir1', false, '', '', ExpandConstant('{app}'), notPCFonFLY {PCFonFLY}) then break;

Цитата:

Вчера мучился с ошибкой, которая возникала при перегонке данных посредством stdin+stdout, фриарк при распаковке писал, что crc не совпадает.

ну а если с lzma.exe протестить.

Bulat_Ziganshin
Цитата:

тебя не устраивают исходники, которые я публикую с альфа-версиями?

в svn я мог увидеть разницу между предыдущим и следующим билдом прям в проге, которая показывает различия в исходниках между этими двумя билдами. И при этом ты там пишешь более информативные комменты для конкретного фикса, чем указываешь при релизе альфы.

Bulat_Ziganshin

кажется нашел по какой причине возникают глюки с внешним фильтром..
Юзаю WinAPI функции ReadFile и WriteFile (думаю и в сишных прогах весь ввод/вывод в конечном итоге работает через них).
копипаст с msdn
Код: BOOL WINAPI ReadFile(
__in HANDLE hFile,
__out LPVOID lpBuffer,
__in DWORD nNumberOfBytesToRead,
__out_opt LPDWORD lpNumberOfBytesRead,
__inout_opt LPOVERLAPPED lpOverlapped
);

Bulat_Ziganshin


Цитата:

как видишь, lzma:fast находится посредине между lzma:normal и tor:6 и по сжатию, и по времени работы, т.е. обеспечивает формирование равномерной линейки методов

Согласен.
Это и есть примерно мой вариант.

Добавлено:
Только шаг в 2 раза слишком большой

пакую папку(куча мелких файлов zip,exe,rar) -70Мб без сжатия
получаю arc - 70Мб
открываю - внутри всего три файла - 8Мб
распаковываю - внутри всего три файла - 8Мб??
все настройки дефолтные

Profrager
согласен. собственно, вопрос был в том, нужно ли это кому-нибудь. раз желающий нашёлся, постараюсь сделать фильтрованный репозиторий hg. можно и svn, но там в любом случае будет более бедное, линейное дерево коммитов


Цитата:

Это и есть примерно мой вариант.

ну да? ты вроде предлагал заменить lzma:fast на tor:6

Всем привет.
Подскажите свои настройки сжатия FreeArcа, чтобы сжимало ОЧЕНЬ хорошо, пожалуйста.
У меня FreeArc альфа.

В основном проблема между методами tor:6 и lzma:fast. Здесь зазор заполнять нечем.

Добавлено:
У меня
84 = rep:1gb+4x4:tor:6:4mb:h8mb
85 = rep:1g+xlzma:4mb:h512k:fast:128:mc8

Где я пытался сколько можно ускорить Lzma:fast

Добавлено:
Здесь перечислял:
http://forum.ru-board.com/topic.cgi?forum=5&topic=35164&start=1260#19

Volt_M

Цитата:

(куча мелких файлов zip,exe,rar)

косяк, уберите 7z.dll

Ваше мнение?
http://sourceforge.net/projects/sevenzip/forums/forum/45797/topic/3327567

The unarchiver project has an implementation of WinZip JPEG compression.
http://code.google.com/p/theunarchiver/source/browse/#hg%2FXADMaster%2FWinZipJPEG