» FreeArc (часть 4)

Здравствуйте что можете посоветовать по сжатию файлов после обработки прикомпом и срепом как более максимально сжать?

vishyakov
да. хотя одно время это было запрещено:


-- |При работе с одним физическим диском (наиболее частый вариант)
-- нет смысла выполнять несколько I/O операций параллельно,
-- поэтому мы их все проводим через "угольное ушко" одной-единственной MVar
-- UPDATE: Seems that this is no more holds for Vista
--
--oneIOAtTime = unsafePerformIO$ newMVar "oneIOAtTime value"
--fileReadBuf file buf size = withMVar oneIOAtTime $ \_ -> fileReadBufSimple file buf size
--fileWriteBuf file buf size = withMVar oneIOAtTime $ \_ -> fileWriteBufSimple file buf size

fileReadBuf = fileReadBufSimple
fileWriteBuf = fileWriteBufSimple

WatsonRus

Цитата:

Главная проблема FreeArc - малая распространенность

Я напрмиер сотрудникам предпочитаю ставить 7zip, а не FA.
Если глянуть на интерфейс на данном этапе и учесть ошибки с пустыми каталогами или вложенными архивами, то мой выбор понятен.
Ждём ...

Hell_Dog2011

Цитата:

что можете посоветовать по сжатию файлов после обработки прикомпом и срепом

1) для начала, все-таки читать доку (например, FreeArc040-rus.htm --> разделы "Выбор алгоритмов сжатия", "Параметры алгоритмов сжатия", чтобы узнать что и как можно подстроить в методах "под себя"),
2) скачать и установить себе последнюю версию FreeArc,
3) пробовать файлы на сжимаемость - попробовать сжать файлы разными методами, вместе или по-отдельности, попробовать сжать экспериментальными методами (которые как-раз написаны для использования прекомп и среп, читайте форум),

vasulpr
Польза от rep-а на большом объеме данных, превышающем словарь lzma.
В вашем случае объем данных сравним с объемом словаря lzma, поэтому от него эффекта не чувствуется.
Попробуйте на нескольких ГБ.
Вообще, в моих экпериментах, наоборот, обычно без деления на группы результат лучше!

Hell_Dog2011
в опциях сжатия выбираешь макс. сжатие и отмечаешь снизу галочки srep и precomp

А что за ошибки?

Интерфейс пофиг, ибо отдельно никогда не будет использоваться, ни FA, ни 7Z. Только из файл-менеджера. Меня удерживает лишь малая распространенность.

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

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


Цитата:

озможно надо создать еще одну группу файлов: исполняемые данные?
Поскольку на compressed и binary - exe дает ухудшение сжатия, тай скорость чуть-чуть падает.

фишка в том, что разделение на отдельные группы исполныемых и остальных бинарных данных приведёт к тому, что lzma/rep не сможет закодировать повторы между ними. поэтому так и сделано - в отдельную группу вынесены редкие obj, которым exe-фильтр очень вредит. а бинарные, которым exe-фильтр почти безвреден, объединены с exe - польза от кодирования повторов больше потерь от бесполехзного применения exe


Цитата:

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

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

Bulat_Ziganshin
в моём такого нету может у меня не та версия(666) вот моя.

Цитата:

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

Лично меня удерживает не столько малая распространенность, сколько слабые возможности SFX-модуля этого архиватора. В том же WinRar или 7-Zip есть возможность использования сценариев - куда и как распаковывать данные, а так же что потом сними делать. Да и настойчивое желание GUI SFX-модуля распаковать архив в папку, где расположен самораспаковывающийся архив с созданием дополнительной папки по имени самого архива вместо распаковки по конкретному пути тоже напрягает.

Hell_Dog2011
да, это только в 0.67

Цитата:

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

Цитата:

вместо распаковки по конкретному пути

можно подробней?

Цитата:

в отдельную группу вынесены редкие obj

так я ни одного с файлов этой группы и не сжимал


Цитата:

что lzma/rep не сможет закодировать повторы между ними

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


Цитата:

а бинарные, которым exe-фильтр почти безвреден

халявных 200 кб на 650мб + чуть большая скорость упаковки это по вашему лишнее?

Я все таки протестовал бы ФА с новой группой, поэтому если будет время это реализовать, то я с удовольствием помогу с тестированием!

Цитата:

Ерунда какая-то с последним FreeArc:
1. В GUI настройки при смене верхних пресетов вверху меняются.
2. Нигде не слова о том что надо packjpg.exe положить в папку freearc/bin (нужен подход как в megui с автообновлением компонентов)
3. Подаю на вход чистого packjpg 1.jpg, на выходе - получаю 80%. Запускаю с тем же файлом freearc с -m5p (или -m9p), packjpg пишет в консоле что вроде как работает, но на выходе архив 101%. WTF ?
4. freearc.ini данный здесь не до конца совместим с последней версией freearc, в частности те же -m5p не работают (а в -m81 jpg preprocess вроде как нет).
5. Почему бы не включить эти m81-m87 в официальную версию, в том числе сделать их доступными и через GUI ?

1. не понял
2. не нужно
3. вероятно ты используешь свой нестандартный ini-файл или ini-файл от предыдущих версий. в моём _майском_ arc.ini packjpg при -m5p не используется, вместо него джипеги сжимает precomp
4. это верно
5. первое - можно. второе - ты предлагаешь снова начать цикл смены gui? думаю достаточно того, что ты сам можешь их вставить в freearc.ini или просто набрать "81" в строке выбора метода сжатия

Цитата:

вместо распаковки по конкретному пути

Цитата:

можно подробней?

Скажем, у меня на диске D: в папке есть набор каталогов и файлов. Я делаю из ее содержимого архив с опцией "Сделать EXE: Графический для Windows: freearc.sfx", при этом мне надо, чтобы эта структура распаковалась по-умолчанию в C:\MYDATA. Я помещаю самораспаковывающийся архив на флешку (F: ), то при запуске с нее мне предлагается распаковать архив в F:\<имя_архива>. В WinRar же можно просто достаточно указать абсолютный путь, причем доступна "тихая установка", когда выводится только окно прогресса установки или вообще ничего не выводится. Плюс можно потом автоматом запустить файл из распакованного архива или выполнить другие действия (сценарий)
.

vasulpr
ты можешь реализовать это сам, если разберёшься в доке. предлагаемая тобой система - наиболее очевидна, так что я её рассматривал, не переживай. кстати, именно так работает 7-zip


Цитата:

халявных 200 кб на 650мб + чуть большая скорость упаковки это по вашему почти безвредность?

именно. ты получил лучшие результаты на одном тесте, и не понимаешь, что на других будет наоборот

есть ещё один фактор, который я забыл упомянуть - не всегда файлы, содержащие исполняемый код, имеют расширение exe/dll

ясно. а вообще какой синтаксис скриптов надо реализовывать - как в rar, как в 7-zip или что-то ещё?

Да, половину слов не скопировал
1. В GUI настройки при смене верхних пресетов вверху галочки внизу не меняются.
3. Стандартный ini из последней версии. Что из GUI, что через -m5p размер не уменьшается.
5. С точки зрения удобства людей наиболее лучшие по скорости/уровню сжатия режимы m81-m87 просто обязаны быть в GUI и более того, выбраны по умолчанию. Возможно даже заменить ими стандартные -m1.. Или сделать подход как в x264, есть пресеты вида superfast, medium, slow, и другие, и в разные моменты времени их внутренности меняются, но названия остаются. Так и здесь, ввести superfast, который плавно мигрирует с -m1 на -m81.

Что хочу сказать по поводу packjpg. Дикий тормоз, на фоне того же x264 с теми же алгоритмами арифметического сжатия. Если x264 на i7-860 выдаёт на 2Mpx FullHD -medium в районе 12fps, то та же 16Mpx jpg имеет в 8 раз больший объём, и должна сжиматься как минимум за полсекунды, но 4.5секунды это перебор, тем более там нет никакого motion compensation, как в x264, и просто расжимаются DCT коэффициенты из VLC и пережимаются в AC. Так что поле для оптимизация вижу как минимум раз в 10, неплохо бы автору packjpg взять некоторые готовые процедуры из кода x264.

Лог -m9p

Код:
C:\Program Files (x86)\FreeArc\bin>arc a 1jpg.arc 1.jpg -m9p
FreeArc 0.67 (May 22 2012) creating archive: 1jpg.arc
Compressing 1 file, 4,307,553 bytes. Processed 0%
Compressing 4,307,553 bytes with precomp042 -c- -t-j -intense -o$$arcpackedfile
$$.tmp $$arcdatafile$$.tmp

Precomp v0.4.2 - ALPHA version - USE FOR TESTING ONLY
Free for non-commercial use - Copyright 2006-2011 by Christian Schneider

Input file: $$arcdatafile$$.tmp
Output file: $$arcpackedfile$$.tmp

Using PACKJPG.DLL for JPG recompression.

--> packJPG DLL v2.4WIP4 (11/06/2008) by Matthias Stirner <--
More about PackJPG here: http://www.elektronik.htw-aalen.de/packjpg

100.00% - New size: 4307589 instead of 4307553

Done.
Time: 4 seconds, 477 milliseconds

Recompressed streams: 0/16
zLib streams (intense mode): 0/16

None of the given compression and memory levels could be used.
There will be no gain compressing the output file.

Errorlevel=2
10%
Compressing 4,307,566 bytes with srep -m3f -mem256mb $$arcdatafile$$.tmp -

SREP 3.0 (January 30, 2012): input size 4 mb, memory used 33 mb, -m3f -l512 -c256 -a4
100%: 4,307,566 -> 4,301,537: 99.86%. Cpu 88 mb/s, real 59 mb/s
Second pass: 100%

Errorlevel=0
Compressed 1 file, 4,307,553 => 4,321,369 bytes. Ratio 100.3%
Compression time: cpu 1.01 secs, real 6.88 secs. Speed 626 kB/s
All OK

Bulat_Ziganshin
А если в группу obj внести все другие группы (кроме exe конечно) сделав их как бы подгруппам, такое возможно?
файлы группы obj при архивировании выносятся отдельным блоком в котором не используется препроцессор exe?

Цитата:

а вообще какой синтаксис скриптов надо реализовывать - как в rar, как в 7-zip или что-то ещё?

Вот такой

Цитата:

А если в группу obj внести все другие группы (кроме exe конечно) сделав их как бы подгруппам, такое возможно?

можно просто перенести в неё все расширения кроме exe/dll


Цитата:

файлы группы obj при архивировании выносятся отдельным блоком в котором не используется препроцессор exe?

да

LonerDergunov
ну это вообще было бы круто, поскольку он в исходниках. идеально было бы если б его сделали универсапльным, работающим с архивным форматом через определённое API, и я соответственно это API просто реализовал бы

хотя на мой взгляд, это всё изврат (а этот модуль - особо тяжкий изврат) и надо идти с другой стороны - вставить в sfx рантайм от Lua. Или даже можно сказать наборот - сделать exe, состоящий из рантайма Lua, библиотеки распаковки arc (или 7z, rar...), ну и ffi чтобы любые виндовые функции можно было из него вызывать

Bulat_Ziganshin

Цитата:

4. freearc.ini данный здесь не до конца совместим с последней версией freearc, в частности те же -m5p не работают (а в -m81 jpg preprocess вроде как нет).

Под последние версии архиватора, arc.ini я модифицировал, но не довел до конца (нужно много времени на проверки). Поэтому не выкладывал.
Первые методы из серии -m8. выглядят так:
81 = rep:1gb:64:c32+xtor:3:4m:h64k
82 = rep:1gb:64:c16:d4m:s32+xtor:4:4m:h512k:l4
83 = rep:1gb:64:c16:d4m:s32+xtor:4:4m:h1m:l8
84 = rep:1gb:64:c16:d4m:s32+xtor:4:4m:h8m:l8
и пока все.

Bulat_Ziganshin
Почему возникает такая ошибка?

Цитата:

ОШИБКА: ошибка в сжатых данных алгоритма lzma:169mb:normal:bt4:128

[more=logfile]D:\Supreme Commander>FreeArc a -tarc -mt0 -mx -ld1600m --logfile=freearc.log -dpD:\Supreme Commander -- F:\CacheAndTemp\game.arc SC SC - FA
FreeArc 0.67 (December 25 2011) Creating archive: E:\game.arc using rep:1567428kb+exe+delta+tempfile+lzma:177mb:normal:bt4:128, $obj => rep:1567428kb+delta+tempfile+lzma:177mb:normal:bt4:128, $text => dict:128mb:80%:l8192:m400:s100+lzp:160mb:92%:145:h23:d1mb+ppmd:16:384mb, $wav => tta, $bmp => mm+grzip:8mb:m1:l2048:h15:a
Memory for compression 1811mb, decompression 1539mb, cache 256kb
Compressed 3,906 files, 16,215,667,581 => 6,962,283,626 bytes. Ratio 42.9%
Compression time: cpu 6846.24 secs, real 4682.94 secs. Speed 3,463 kB/s
All OK[/more]

Bulat_Ziganshin

Цитата:

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

похоже вот на это - FreeArc 0.67 (December 12 2012)

1. Хотелось бы видеть иконки файлов и папки внутри архива.
2. Хотелось бы иметь возможность создавать многотомные архивы.
3. Перетаскивание из архива и в архив.
4. Вложенные архивы открывать в том же окне и по умолчанию предлагать путь извлечения как для изначального архива.

Это уже всё в планах есть. Ждём версию 1.0 и можно офис переводить на FA

Цитата:

через -m5p размер не уменьшается.

блин, я уже забыл, а ты доки и не читаешь: "Обратите внимание: режим сжатия -max (-m9p) реализует максимальное сжатие с precomp+srep+dispack, а -m9j делает то же самое плюс пережатие jpeg"


Цитата:

Дикий тормоз, на фоне того же x264 с теми же алгоритмами арифметического сжатия.

запорожец - дикий тормоз на фоне бугатти, несмотря на те же 4 колеса


Цитата:

С точки зрения удобства людей наиболее лучшие по скорости/уровню сжатия режимы m81-m87 просто обязаны быть в GUI и более того, выбраны по умолчанию.

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


Цитата:

В GUI настройки при смене верхних пресетов вверху галочки внизу не меняются.  

при выборе пресета в верхней строке? ага, и это не так просто реализовать. как-нибудь в будущем


Цитата:

Кстати, попробовал packMP3 от создателя pacjJPG, действительно сжимает до 25%. Неплохо бы его тоже включить в FreeARC. mp3zip тоже хорош.

или как вариант - packARC. с precomp проблема в том, что jpeg-поддержка в нём иногда виснет, не знаю как с этим будет в packARC. mp3zip - коммерчески

Shuld
в общем тот, кому хочется это видеть в fa, должен будет взять arc.ini от июньской версии, добавить туда аккуратно твои методы и кинуть мне

WildGoblin
обычно из-за разгона или неисправного компа

Bulat_Ziganshin
Цитата:

хотя на мой взгляд, это всё изврат (а этот модуль - особо тяжкий изврат)

Это лучшее, что есть из SFX-модулей, особенно по простоте настройки. Вот заменять SFX-сценарий каким-то ИнноСетапом - тот еще изврат.
Чтобы не портить совместимость - в идеале сделать сценарии как в вышеприведенном модуле, а запихивать сценарий в коммент архива - между маркерами начала и конца сценария.

Bulat_Ziganshin

Цитата:

обычно из-за разгона или неисправного компа

Разгона нет. Какого рода неисправность компа может вызывать такую ошибку?

Добавлено:
Похоже правда какой-то сбой - из сделанных вчера архивов ещё один не распаковывается.
Надо теперь всегда использовать -t

Цитата:

Цитата:
через -m5p размер не уменьшается.  

блин, я уже забыл, а ты доки и не читаешь: "Обратите внимание: режим сжатия -max (-m9p) реализует максимальное сжатие с precomp+srep+dispack, а -m9j делает то же самое плюс пережатие jpeg"

Всё равно не получается. Compressed 1 file, 4,307,553 => 4,219,424 bytes. Ratio 97.9%
У packjpg выше приводил 79%.
И самое главное, до того как пробовать через консоль включал галочки на precomp jpeg в gui с тем же нулевым результатом (то есть на выходе были те же 98%, которые я считаю ошибкой на фоне packjpg).
Кстати, packjpg консольный уже полгода как версии 2.5, в dll же 2.4.


Цитата:

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

Зачем же. Но если эти методы такие замечательные что на них проводятся тесты и рекомендуются в этой ветке именно они, то почему бы и нет. Идея пресетов позволит менять внутренние параметры от версии к версии, скрывая подробности от неопытных пользователей.

Кстати, очень хотелось бы видеть в документации пример запуска для режима backup с синхронизацией, то есть новые или изменившиеся файлы добавлялись бы в архив, а исчезнувшие файлы соответственно удалялись. Хотел попробовать для этих целей навороченный StuffIt, так он не умеет режима синхронизации, то есть удалять файлы из архива.