» FreeArc (часть 4)

Andrey_Verkhoglyadov
ну да, это пустая писанина. если ты пользуешься программой часто, оно просто начинает мозолить глаза. я стараюсь сделать такую постоянную информацию как можно меньше мешающей восприятию того, что действительно нужно увидеть. например, freearc - единственная программа, выделяющая цифры жирным шрифтом, и по сравнению с rar/7-zip это имхо делает упрощает восприятие

Добавлено:
вот ещё что мне насоветовали:



Цитата:

a new suggestions for decompression in freearc:
freearc in merged methods for both compression and decompression [precomp+srep+lzma] needs some free space drive, for example:

max payne 3 files [except audio and video files] : 17.2 GB
max payne 3 files ---> copying to temp folder ---> 17.2 GB
17.2 GB ---> precomp ---> 40 GB [need 57.2 GB space]
40 GB ---> copying to temp folder ---> 40 GB [need 80 GB space]
40 GB ---> srep+lzma ---> 5.96 GB
for decompression reverse...
so for decompression we need 80 GB space and need many times

you can use cls-precomp.dll and cls-srep.dll files that have function can decompress archive with precomp+srep+lzma in parallel mode by 3x faster than your default decompression and need very little disk space.

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

Цитата:

Не распакуются они не потому, что памяти нехватает (есть же Ultra, у которого 2гб в требованиях, его же не убирают из-за этого!), а потому что поддержки тех методов нет в старых Freearc, но это вполне логично.

манипуляциями с arc.ini в принципе нельзя сделать архивы, несовместимые с другими версиями freearc. все эти -m80 - просто новые сокращения, которые расшифровываются до названий встроенных методов и только в таком виде запоминаются в архиве. прочти доку, ты ведь достаточно глубоко используешь fa и без чтения доки всё это напоминает известную басню

Bulat_Ziganshin
Тогда чего ты боишься, каких таких "доставаний" пользователей ?
Доку я читал, мало ли что там в прошлых версиях, может раньше не было какого-нибудь xtor в FA.

Bulat_Ziganshin

Цитата:

...упрощает восприятие

согласен

Цитата:

...оно просто начинает мозолить глаза.

согласен

Цитата:

ну да, это пустая писанина.

и тут согласен

Цитата:

если ты пользуешься программой часто, оно просто начинает мозолить глаза

и опять согласен

Цитата:

...что действительно нужно увидеть

единственное что хочется видеть при процессе упаковки - это сколько осталось времени до завершения процесса и на сколько уменьшился объем первоначальной информации. И мне совершенно все равно что и как будет выглядеть на самом деле, но если есть вариант, то конечно хочется воспринимать информацию так чтобы не отвлекаться от основной задачи и просто контролировать (не задумываясь) процесс. Ведь согласитесь, по большому счету задача архивирования - второстепенная задача.
И все-таки оставьте старый (v0).

p.s. проведите опрос среди англоязычной публики ...

p.s.s. а почему бы не подумать на счет коммерческой составляющей, а !? если правильно построить маркетинговую политику по сравнению с конкурентами существующими на рынке, я думаю что успех может быть (англоязычные страны). отвечать по поводу коммерции не надо дабы избежать не нужный флуд.

90 = rep:2gb:256:c256+xlz4
91 = rep:2gb:112:c64:d4m:s64+xtor:3:4m:h32k
92 = rep:2gb:64:c16:d4m:s32+xtor:4:4m:h512k:l4
93 = rep:2gb:64:c16:d4m:s32+xtor:4:4m:h1m:l8
94 = rep:2gb:96:c16:d4m:s48:h25+4x4:tor:6:4mb:h8mb
95 = rep:2g:48:c16:d4m:s32+xlzma:4mb:h512k:fast:128:mc8
96 = rep:2g:48:c16:d4m:s24+xlzma:4m:h1m:normal:24:mc8

Да, методы -m9* с rep:2g определённо лучше -m8* с rep:1g, особенно -m94, -m95 и -m96, так что при свободном количестве памяти больше 2Gb можно использовать именно их.
Методы начиная с m97 вылетают с нехваткой памяти, т.к. сам Freearc 32 битный. Что очень жаль, так как на примере тех же x264, Avisynth, mvtools и многого другого я вижу, что x64 даёт прибавку в скорости около 10%-15%, например за счёт удвоенного количества регистров.

Bulat_Ziganshin
и всё-таки, мне кажется, Ratio и Speed как-то "некстати" среди остальных значений
по сути, они не столько к "прогрессу" относятся, сколько к "вспомогательной информации"
и если насчёт Ratio это несколько спорно, то уж Speed однозначно - кандидат в status bar

вот расчехлил paint и сварганил пару вариантов:

(v5) - Ratio и Speed задвинуты в самый низ, в "воображаемый status bar"

(тут несколько напрягает непонятное соседство Ratio и [+])

(v6) - Ratio и Speed в правом углу над progress bar
с одной стороны, не так "заброшены", как в предыдущем варианте, с другой - достаточно отделены от остальных значений

Кроме избавление от создания временных файлов в %temp%, в случае если используется только один внешний упаковщик, есть ещё одно пожелание - возможность параллельной обработки нескольких файлов с запуском нескольких внешних упаковщиков одновременно.
Например, packjpg/packarc используют только один поток, поэтому у меня используют только 13% CPU, поэтому при архивации папки с jpg запуск 8 копий packarc ускорило бы упаковку (и распаковку, если её так же распараллелить) раз в 5.

p.s. кстати, что за --queue ? Внятного описания с примером найти не удалось, в единственной документации http://freearc.org/ru/FreeArc040-rus.htm не упоминается.

Цитата:

Методы начиная с m97 вылетают с нехваткой памяти, т.к. сам Freearc 32 битный.

Дело не хаскеле ?

Цитата:

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

скажу просто: Вам решать. Вы можете сделать это опционально (платно) или не сделать вообще. Что касается меня, то я бы не заморачивался на это ибо сейчас размер жесткого диска (или ssd диска) позволяет делать что и как угодно. Проще говоря человек, говорящий не по нашему делает акцент не на то.

muzf

Цитата:

p.s. кстати, что за --queue ? Внятного описания с примером найти не удалось, в единственной документации http://freearc.org/ru/FreeArc040-rus.htm не упоминается.

что нет в документации, то есть в истории версий FreeArc
http://freearc.org/history/changelog_full_ru.htm

или по тексту в этом топике искать

Andrey_Verkhoglyadov
подобные вещи я делаю в "фоновом" режиме, просто когда наскучивает заниматься более скучными, но важными, так что речь не об этом. у меня вопрос к спецам по freearc - правильно ли я понял что там нужно сделать

Добавлено:
sabio
мне v5 и v6 не глянулись. положил их тоже на свой сервер:
http://freearc.org/download/image/progress5.png
http://freearc.org/download/image/progress6.png

Добавлено:

Цитата:

насчёт "по окончании" - надо просто не очищать поля слева, и асимметрии не будет
да и видно будет заодно, что все файлы и байты были обработаны
(или наоборот, если по какой-то причине файл обработать не получилось, будет видно, что число слева меньше правого)

там сейчас делается по-другому - если что-то не удалось обработать, то уменьшается сам Total. а столюцы справа очищаются именно когда total==current, это между прочим удобней - не надо самому думать, сравнивать их, всё сразу интуитивно ясно

Добавлено:

Цитата:

А еще проценты ratio можно с сотыми долями выводить.

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


Цитата:

а для консоли удобнее будет строки поменять местами

разумеется


Цитата:

только вот с Compressed и Time неувязка

да, не так там всё просто, но как начальная точка отсчёта подойдёт. что мне нравится - идея разместить totals сверху и несколько чисел под ним. в принципе, все 8 меняющихся полей можно вместить в одну строчку (очень длинную )


Цитата:

единственное что хочется видеть при процессе упаковки - это сколько осталось времени до завершения процесса и на сколько уменьшился объем первоначальной информации.

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

Поймал странность.
Есть папка с логами, *.log , попадают под $text в arc.groups.
Так вот, запись в ini 81 = / $text=ex1b сжимает сильнее, чем 81 = rep:2gb:112:c64:d4m:s64+xtor:3:4m:h32k / $text=ex1b . Казалось бы, раз задано $text=, то всё что до этого должно игнорироваться, и итоговый размер должен совпадать. Но он не совпадает!

muzf
-ma-

Bulat_Ziganshin

Цитата:

столюцы справа очищаются именно когда total==current, это между прочим удобней - не надо самому думать, сравнивать их, всё сразу интуитивно ясно

может, тогда, чтобы всё же не появлялось асимметрии по окончании, вместо очистки, например, выключать bold?
хотя, как по мне, и очистка, и выключение жирного в момент окончания архивирования выглядят несколько странно и нелогично, неожиданно - число росло, росло и вдруг пропало
я бы оставлял всё на месте, как есть
а если надо что-то специально выделить (например, в случае ошибки) менял бы цвет на красный что ли?..


Цитата:

мне v5 и v6 не глянулись

я и сам на них посмотрел ещё раз - не то

но всё же, мне кажется, Ratio и Speed не должны быть "вперемешку" со значениями "xxx of yyy"
хотя бы как-нибудь так, может? (v7)

Можно чуть чуть поподробнее ?
-maLEVEL - set filetype detection LEVEL (+/-/1..9)
Описания этой опции в старой документации нет. -ma- снижает уровень детектирования расширения файлов, можно на пальцах рассказать что это значит ? Сейчас неправильно определился тип файлов (не по расширению) и он попал не в $text ? Есть ли режим verbose или debug у Freearc, чтобы увидеть как детектируется каждый файл и в какую секцию попадает ?

Bulat_Ziganshin

Цитата:

для нормального юзера - да, для гика нужно больше

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

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

И ещё, возможно ли при создании очень большого архива через --sync как-то прервать процесс, и затем продолжить его заново снова через -sync ?

sabio
в случае ошибок сообщения о них выводятся под прогрессбаром

Andrey_Verkhoglyadov
а зачем нормальному пользователю использовать freearc, а не rar/zip? вот вам например?

muzf
freearc 0.50+ по умолчанию пытается определить тип файла по его содержимому. если файл похож на текст - его принудительно записывают в группу $text, несжимаемые данные - в группу $precomp или $compressed. вот кусочек кода:

// Тип данных: $precomp/$compressed если не сжимается ни order-0 ни lz77.
// $text если активных символов от 17 до 80, число повторов дистанций невелико и lz-матчи составляют хотя бы 10% данных

те, кто не попали под эти эвристики, остаются в старых группах (определённых по arc.groups)

-ma- отключает это, -ma1..9 равноценны (в будущем предполагается на более высоких уровнях выполнять более тщательный анализ)

включить весь возможный вывод можно опциями -di -di+$ -i2 (опции -di именно в таком порядке). можно также сопоставить вывод команд l и lt чтобы увидеть какой файл сжат какими алгоритмами

Bulat_Ziganshin

Возможно некоторые строки поменять местами,
А также добавить под кнопкой "+" раздел типа "Estimated end of Operation" где вычислялось бы примерное время окончания, путем суммирования текущего системного времени и остатка времени операции.

Теперь понятно в чём была проблема, эти логи, которые я сжимал, содержали много русских букв, причём в UTF-8, поэтому не попадали в $text. Причём PPMd (xppmd:12:192m
) их всё равно сжимает лучше и быстрее чем всё остальное.
Может UTF-8, а также тексты с русскими буквами тоже принудительно записывать в группу $text ?

Bulat_Ziganshin

Цитата:

а зачем нормальному пользователю использовать freearc, а не rar/zip? вот вам например?

мне он нравится тем, что лучше пакует мои данные чем тот же rar или 7-zip для моего домашнего архива - кратковременного. (для длительного хранения я использую zip и только его). Но, извините, для каждодневного использования я выбираю winrar для того, чтобы архивировать данные в rar или zip и отправить их по почте.

muzf
кстати, раз возник интерес к теме - добавил в http://freearc.org/download/research/utils.zip утилиту mmdet.exe, вызывать mmdet.exe -det filename

Добавлено:

Цитата:

Может UTF-8, а также тексты с русскими буквами тоже принудительно записывать в группу $text ?

а спрашивать русские это буквы или татарские, предполагается у пользователя?

Цитата:

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

Вообще идея хороша, но зачем srep? Ведь есть метод распаковки stdin stdout, который по сути не отличается от того же фильтра. Ну и насколько я помню была обещана поддержка srep как внутреннего алгоритма, вместо rep. Вот прекомп конечно бы неплохо было добавить. Так же как и сжатие PCM аудио алгоритмами frog и tak, как это сделано в msc у профрагера (распаковка так же идет с cls фильтром).

Ну да, на логе в UTF-8 показало что текста мало:
File size: 36174875
64kb blocks detection in 0.160 sec:
default 538
$text 14
Entire file detection: default in 0.147 sec

Цитата:

..............Files ....... Bytes . => ... Compressed ...... Time
Processed ....... 8 .. 16,188,368 ......... 6,229,876 ... 0:00:02
Total .......... 35 . 134,844,601 ...... ~ 51,893,133 . ~ 0:00:17
 
Ratio .......... 38 %
Speed ....... 7,970 kB/s

v8 - http://freearc.org/download/testing/progress/FreeArc8.exe:

Обнаружил серьёзный недостаток режима --sync - создаётся копия файла с изменениями/добавлениями.
Это сразу рубит на корню идею бэкапа, когда например один раздел бэкапится на другой носитель такого же объёма, и лишнего пространства под временный файл просто нет.
Жаль, хотелось бы чтобы все изменения были с одним файлом. Не знаю как этом случае будет удаление части файлов из сотни-гигабайтного архива без передвижения всей остальной части, но в dynamic VHD или sparse file это как-то делается. Говорят что NTFS supports hole-punching, с помощью функции DeviceIoControl() (например это умеет утилита http://www.opalapps.com/sparse_checker/sparse_checker.html ), цена этого - фрагментация файла, но для бэкапов это неважно. Похожий эффект можно добиться с помощью флага NTFS Compression, если заполнять неиспользуемые области нулями.

Andrey_Verkhoglyadov

Цитата:

Вы можете сделать это опционально (платно) или не сделать вообще.

Убейся уже, пожалуйста, об стену.

Bulat_Ziganshin

Цитата:

v8

Отлично выглядит!
Строка "Files Bytes Compressed Time" очень упрощает восприятие - взгляд сразу выхватывает нужное.

Burat нашел один баг. Когда делаю бекап папки с параметром -ep3 - архив пакуется. Я в него через FA захожу там первый каталог буква диска, захожу в этот каталог и FA уже переходит физически на реальный диск, т.е. отображает каталоги не из архива, а содержание реального диска. И добраться до файлов в этом архиве не представляется возможным)

Bulat_Ziganshin
1) Почему бы не пересунуть "Ratio" под столбик "Compressed" для наглядности? Юзер будет видеть примерный ~размер архива (после сжатия) и сразу понимать при какой степени сжатия, (Текст "Ratio" выравнять по первой букве с "Compressed")
2) также для Скорости сжатия нужно сделать подпись, что это "Скорость",
"Скорость" (сам текст) подсунуть под столбик "Files" (выравнять по последней букве)
3) неплохо выглядит также линия, которая отделяет зону диалога прогресса "Files Bytes Compressed Time"
а также спасает от неразберихи оригинального v8: - сверху столбика текст "Bytes", но числа почему-то внизу в "kB/s", но строка начинается "Ratio", со временем можно привыкнуть и понимать что к чему, но когда когда есть линия текст после линии уже читается не так сложно.
Вариант 1:


Вариант 2 без линии: