» FreeArc (часть 4)

Bulat_Ziganshin
Может все таки стоит научить SREP работать с папками?

muzf
не мы вместе а я вам объяснил в чём дело. что я записал это как хорошую идею - это одно, а что вам мешает в precomp поддержку jpeg включить?

vasulpr
не хочу этим заниматься, поскольку это повлечёт множество других вопросов. да и зачем? неужели не exdupe/zpaq, ни shar+srep, ни freearc+srep не устраивают?

Bulat_Ziganshin
Если бы я знал что это такое, то я бы не спрашивал.

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

muzf
гм, не пробовал просто включить галочку jpeg в experimental compressors?

vasulpr
пакуй freearc с опцией -mc:rep/srep. или галочку в gui просто отметь. так устраивает?

Цитата:

ты же видишь какую опцию вставляет при этом fa в комстроку

нет, не вижу. Где я должен её смотреть?

Bulat_Ziganshin
Лично я пакую сначала срепом, а затем ФА, это позволяет переупаковывать звено ФА (подбор параметров) без перепаковкы срепа.

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

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

Мы кажется на разных языках говорим.
Включение в настройках GUI precomp jpeg даёт точно такой же результат, как и arc -m9j , то есть никакой. При этом вывоз packarc напрямую ужимает до 76%. На этом же файле ( http://narod.ru/disk/52697814001.0ab47b2f6b6f9e0e29fdc7f5c3b462a4/1.jpg.html )

vasulpr Вы несёте бред

Хочу то, что курит vasulpr.

new alpha version:-m#p/-m#j: definitions moved into arc.ini
REP: fixed bug detected by Paramon111 (files with some sizes crashed REP)
-scaX or -scXa: set up all domains to use charset X
-sc: support for -scD=charset syntax
-sc: strict checking of option syntax
arc.groups: added video files to $compressed group
LZMA-x64: added readme-rus.txt
Autoplay Media Studio: readme.txt pointing to the example download

Новая альфа-версия:-m#p/-m#j: определения перенесены в arc.ini
REP: исправлена ошибка, обнаруженная Paramon111 (крешился на файлах с определёнными размерами)
-scaX или -scXa: настроить ВСЕ домены на использование кодировки X
-sc: поддержка синтаксиса -scD=charset
-sc: строгая проверка синтаксиса опции
arc.groups: в группу $compressed добавлены видеофайлы
LZMA-x64: добавлен readme-rus.txt
Autoplay Media Studio: readme.txt со ссылкой на демо-проект интеграции

Цитата:

vasulpr Вы несёте бред

Цитата:

Хочу то, что курит vasulpr.

Задолбали такие необоснованные выпады. Обоснуй если такой умный!
Почему бред объясните! возможно что-то поменялось с последнего моего пользования srepом в ФА (оно было достаточно давно). или я чего-то не понимаю?

Только что пробовал паковать последним билдом ФА. Ничего не изменилось!

Ждали ждали и наконец дождались !
Давненько новых альф не было.

Цитата:

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

а http://freearc.org/research/SREP.aspx не устраивает?


Цитата:

Лично я пакую сначала срепом, а затем ФА, это позволяет переупаковывать звено ФА (подбор параметров) без перепаковкы срепа.
 
Чтобы в ФА использовать среп нужно много свободного места на диске для промежуточного файла при упаковке да и там беда с прогресбаром.

зачем это нужно - понял. а в каком режиме -m ты пакуешь и сколько у тебя бывает файлов?

Отличная новость!

ndch

Цитата:

ты же видишь какую опцию вставляет при этом fa в комстроку

нет, не вижу. Где я должен её смотреть?

наверху



Цитата:

Включение в настройках GUI precomp jpeg даёт точно такой же результат, как и arc -m9j , то есть никакой.

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

Цитата:

а http://freearc.org/research/SREP.aspx не устраивает?

Это другое дело! Если бы еще по русски


Цитата:

а в каком режиме -m ты пакуешь и сколько у тебя бывает файлов?

В основном использую m2, m3. Честно говоря пока руки не дошли более подробно с параметрами разобраться и подобрать что-то лучше.

Последний раз что я паковал, так это были 2 образы вин7 32 и 64бит 5,4 Гб 2 файла.
Также иногда игры репачу для себя, то там от 2-20Гб и 10-70000 файлов

Bulat_Ziganshin
То есть то что в тесте squeezechart.com в разделе JPEG FreeArc находится позади всех - это не сигнал о проблеме ?

Цитата:

Это другое дело! Если бы еще по русски

эта страница упоминается и в readme.htm, и в подсказке самого srep.exe. хотя это конечно не полноценная документация, а сборник разъяснений, которые я давал по различным тонкостям использования srep. полной доки с описанием всех опций действительно нет


Цитата:

В основном использую m2, m3.

Цитата:

10-70000 файлов

в режимах -m1/-m1f делается всего 1-2 прохода по файлам, так что можно реализовать упаковку каталогов целиком. в остальных режимах входные данные перечитываются в случайном порядке, поэтому нужно или держать все файлы открытыми (что невозможно для 70 тыщ файлов), или держать пул скажем из 1000 последних открытых файлов и менять их по мере надобности, и не факт что это будет работать с приемлемой скоростью

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

---

вообще, я у srep вижу два применения - первое, как профессионального средства для создания инсталяторов. тут мы нацелены на макс. сжатие, т.е. как правило используется режим -m3f -a1. srep вызывается внутри freearc, таким образом во-первых freearc обеспечивает оптимальную сортировку и разбиение на солид-блоки файлов, во-вторых при распаковке не создаётся никаких промежуточных файлов

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

muzf
там протестирован режим "FreeARC 0.67 ultra", т.е. без precomp

Bulat_Ziganshin
Ну тогда может стоит связаться с ними, показать что надо включить precomp+jpeg, или использовать m9j ( и увидеть в результате с обычного jpeg из Lightroom как у меня сжатие всего на 1% вместо 25%).

Bulat_Ziganshin
Спасибо за подробное объяснение!

muzf
1. ну а зачем? он тестирует fa в чистом виде, от того что он будет его тестировать с внешними упаковщиками, никому ни тепло ни холодно не будет
2. я понимаю, что тебе проще решать эту проблему со мной, но вообще-то у precomp есть свой автор. тебе лень обращаться к нему, лень составлять свой конфиг, ты нашёл простой и ненапряжный путь решить свою индивидуальную проблему - переложить это на меня

Ещё один секрет практического использования SREP: режим -m2 практически бесполезен, как можно видеть из таблицы:

4,531 mb Время упаковки Память упаковки Операций в/в Сжатый размер После дожатия LZMA

а чем отличаются файлы с индексами g, i и m в srep архиве, подскажите пожалуйста?

Bulat_Ziganshin
На самом деле проблема не только в precomp. Провёл тесты с чистым precomp 0.4.2 и отписал о проблеме автору - http://encode.ru/threads/1366-Precomp-0-4-2?p=30070&viewfull=1#post30070 .
Чистый precomp сжимает этот проблемный файл 4 307 553 -> 4 174 846 , тогда как freearc с precomp (-m9j) сжимает его до 4 219 424 bytes

Заметил, что у freearc версия zlib 1.2.2, у precomp с сайта автора - 1.2.3 (закрыты некоторые дырки), последняя на сегодня - 1.2.7

SELFY
разные компиляторы - gnu/microsoft/intel. intel самый быстрый, остальные имеют чисто познавательное значение

Bulat_Ziganshin
У меня при подключении lzma x64 перестал работать метод 4x4:lzma. Как можно исправить не возвращаясь к lzma x32?