» FreeArc (часть 4)

Цитата:

народ, а хоть один комментарий насчёт этих предложений будет?

мне все равно, какая там будет меню, я пользуюсь только кнопкой "добавить"

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

если уж хочется изменить интерфейс, то лучше начинать с окна "добавить в архив" - им пользуются все, я предлагал ранее косметический ремонт этого окна, вы ответили что нужно его полностью переделывать, так начните с него, помогу чем смогу, можно будет провести голосование по некоторым вопросам...
http://forum.ru-board.com/topic.cgi?forum=5&topic=35164&start=1460#12
http://forum.ru-board.com/topic.cgi?forum=5&topic=35164&start=1480#3
http://forum.ru-board.com/topic.cgi?forum=5&topic=35164&start=1480#15

Цитата:

вообще если не хватает сжатия freearc - смотри nanozip, zpaq, zcm

спасибо, пошел копать, скачал fp8_v3 и заодно наткнулся на нанозип и peazip
попробовал на своем файле 417мб (там аудио данные), freearc best assym - 142мб (ультра - 145), нано макс - 139мб, PeaZip (*zpaq-max)-169, fp8_v3(max)-162, zcm-197
в целом PAQ8 не понравился в любой вариации, шибко медленно и слабо, нанозип побыстрее и немного сильнее жмет, с 601мб файлом выиграл у фриарка 4мб, на очень больших файлах жутко тормозит (больше часа сжатие), декомпрессия тоже тормоз, Винрар на обычном сжатии проиграл арку 5мб но скорость у него супер, и сжатие, и распаковка (в 3 раза быстрее арка)
но скрипты то у меня под FreeARC и конечно хотелось бы чтобы он стал лучше\сильнее), и еще использую как защиту от любопытных, переименовываю арки в bin-файлы, чтобы не смотрели что внутри, с раром не прокатит - все равно в любых архиваторах открывается, а вот фриарк не у всех стоит)
а в чем секрет best assymetric?)

Лучше бы сначала добавить возможность сжимать jpeg и mp3 из коробки без глючного precomp.

Что за аудиоданные ? Wav, mp3 ?

Цитата:

народ, а хоть один комментарий насчёт этих предложений будет?

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

Цитата:

Что за аудиоданные ? Wav, mp3 ?

ну это аудио очень специфичного формата (думаю что это набор wav-семплов с метками) для одной проги-синтезатора (а сам файл библиотека для проги) которая работает с этими данными, качество типа wav, сжимается обычно легко (33-35% compression ratio), файлы обычно большие, бывают по несколько гигов но compression ratio все тот же)
можете посоветовать архиватор который хорошо жмет аудио? (для сравнения)

Bulat_Ziganshin

Цитата:

народ, а хоть один комментарий насчёт этих предложений будет

Вот Вам еще комментарий.
Меня в общем внешний вид устраивает. Наверное, может быть лучше, но как-то не очень напрягает.
Кроме пары пустяков:
- По дереву вверх привычнее были бы точки ...
- Когда смотрю свойства архива и вкладку "солид-блоки", то длинные методы не помещаются и толком длинную строку не посмотреть.

cross125
Скачайте, например, файл SqueezeChart2013web
с сайта http://www.squeezechart.com/
На странице Аудио есть сравнение архиваторов для сжатия аудио.

Bulat_Ziganshin

Цитата:

мне лично кажется, что нынешний интерфейс хоть и не идеален, но
минимально пригоден для работы...

Да-да, Булат, пилите пока non-GUI, а мы пока здесь все додумаем


Цитата:

и забыл спросить - какое контекстное меню вы ждёте, вытянутое из Explorer или с командами из самого архиватора (extract и т.п.)?

Комбинированное: сверху команды архиватора, снизу проводника - такое решение применяется во многих файл-менеджерах.

Сделал своё сравнение архиваторов - http://forum.ru-board.com/topic.cgi?forum=5&topic=8076&start=800#5 , -m8* превосходны, хочу их из коробки.

Цитата:

народ, а хоть один комментарий насчёт этих предложений будет

Единственное чего не хватает так это значков рядом с именами файлов. А так всё устраивает в GUI.

muzf
Очень наглядные таблички и графики. Жаль tor и xtor отсутствуют.

Bulat_Ziganshin

С новым unarc.dll (из последней альфы) при распаковке архивов выдает ошибку о неверном пароле, но пароль верный и с более старой версией все распаковывается.

Цитата:

-m8* превосходны, хочу их из коробки.

а что мешает самому в arc.ini вставить?

ndch
он бы ещё с compress сравнил... даёшь nanozip, zcm и rar5!

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

поскольку в планах не нашёл, а шкурный интерес имеется,
хотелось бы узнать, когда (если) планируется 64-бит версия
под Лин? или как запустить ФА через мультиарк...

muzf
Самое главное - отсутствуют требования к памяти компрессии, и особенно декомпрессии (всего в 1 пункте, не в счет).

Vladimyr

Цитата:

как запустить ФА через мультиарк...

Папку Addons смотрели? Вам нужен freearc.addon

Bulat_Ziganshin
Цитата:

а что мешает самому в arc.ini вставить?

Ключевые слова - "из коробки". Чтобы было доступно всем и каждому сразу.
Цель тестирования у меня была не выявление самых сильных компрессоров, а самых быстрый, пригодных для повседневного применения и бэкапа (поэтому тот же -m9 и m5p были только для примера). Например, для бэкапа я не буду использовать то что сжимает медленнее 50Mb/s. Цели тестировать непопулярные решения тоже не было, хотя Nanozip вроде неплох, надо будет проверить. Умеет ли Nanozip режим --sync как в Freearc, удобный для бэкапа ? Насколько я вижу нет, поэтому для целей постоянного бэкапа он не подходит. Rar5 - не вижу ссылки в гугле.

Цитата:

обычно графики рисуют так чтобы лучшие точки были справа-свеху

здесь они снизу-слева, вполне логично.

Цитата:

Самое главное - отсутствуют требования к памяти компрессии, и особенно декомпрессии (всего в 1 пункте, не в счет).

Не было такой цели, сравнение решил провести именно потому, что не видел результатов сжатия на мощной машине (до этого видел только на i5 двухядерном). Макимальный алгоритм требует 2гб, но на 16Gb это всё неважно. Ну и как тестировать потребление памяти в пике - я к сожалению не знаю.

ruduk, я имел в виду этот мультиарк:
https://wiki.ubuntu.com/MultiarchSpec

Bulat_Ziganshin
где почитать про требования к памяти -m8* методов (при компрессии и декомпрессии)

Vladimyr
сразу надо было правильно называть - Мультиарч:
http://wookware.org/talks/multiarch-ELC2012.pdf
Страница 4 и далее - "Multiarch is a general solution for installing libraries of more than one architecture on a system" - Мультиарч это общее решение для инсталлирования библиотек из более чем одной архитектуры в систему".
По-моему, пока что проще использовать самую последнюю версию FA через Wine, чем разбираться что и куда прописать самому для Мультиарча.

Как лучше тестировать Nanozip, standalone или в качестве external compression для Freearc ? В чём разница ?
На этих данных standalone Nanozip x64 показал себя не очень, на nz_optimum1 итоговый размер 516мб получился за 149секунд, напомню у Freearc -m85 за 22 секунды получилось 489мб, в 7 раз быстрее.

И ещё, заметил что Freearc всегда для external compression создаёт временный файл в %temp% ? Я так понимаю это надо только при использовании последовательно нескольких внешних обработчиков. Возможно ли для случаев, когда используется только один внешний архиватор (например один precomp) не создавать дубликат текущего файла в %temp% ?

Цитата:

когда (если) планируется 64-бит версия под Лин?

под win64 планируется в след. году, там объём работы довольно большой. под linux тоже должна появиться как побочный эффект этой работы


Цитата:

- Когда смотрю свойства архива и вкладку "солид-блоки", то длинные методы не помещаются и толком длинную строку не посмотреть.

а растянуть вбок диалог? или вообще использовать arc lt


Цитата:

С новым unarc.dll (из последней альфы) при распаковке архивов выдает ошибку о неверном пароле, но пароль верный и с более старой версией все распаковывается.

не воспроизводится. попробуй сам с UnarcDllExample.exe. может, ты не обновил dll-ки?

Цитата:

Ключевые слова - "из коробки". Чтобы было доступно всем и каждому сразу.

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


Цитата:

Цели тестировать непопулярные решения тоже не было, хотя Nanozip вроде неплох, надо будет проверить.

nz в целом сравним с fa, в чём-то лучше один, в чём-то другой


Цитата:

Ну и как тестировать потребление памяти в пике - я к сожалению не знаю.

consmeter из http://freearc.org/download/research/utils.zip


Цитата:

где почитать про требования к памяти -m8* методов

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

C:\>arc a a -m1 -di
FreeArc 0.67 (December 12 2012) using additional options: --logfile=c:\temp\freearc.log --display=hnwftsr
Creating archive: a.arc using rep:96mb:256:c256+4x4:tor:3:2mb:h64kb, $compressed => rep:96mb:256:c256
Memory for compression 177mb, decompression 96mb, cache 16mb
Compressed 57 files, 1,045,998 => 320,317 bytes. Ratio 30.6%
Compression time: cpu 0.03 secs, real 0.03 secs. Speed 32,685 kB/s
All OK


Цитата:

Как лучше тестировать Nanozip, standalone или в качестве external compression для Freearc ? В чём разница ?

standalone конечно. сам же дальше пишешь


Цитата:

На этих данных standalone Nanozip x64 показал себя не очень, на nz_optimum1 итоговый размер 516мб получился за 149секунд, напомню у Freearc -m85 за 22 секунды получилось 489мб, в 7 раз быстрее.

готовить не умеешь. юзай -cf -m12g


Цитата:

И ещё, заметил что Freearc всегда для external compression создаёт временный файл в %temp% ? Я так понимаю это надо только при использовании последовательно нескольких внешних обработчиков. Возможно ли для случаев, когда используется только один внешний архиватор (например один precomp) не создавать дубликат текущего файла в %temp% ?

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

Bulat_Ziganshin

Цитата:

Цитата: С новым unarc.dll (из последней альфы) при распаковке архивов выдает ошибку о неверном пароле, но пароль верный и с более старой версией все распаковывается.

не воспроизводится. попробуй сам с UnarcDllExample.exe. может, ты не обновил dll-ки?

Bulat_Ziganshin

С UnarcDllExample.exe все ок, но как написал Snoopak96, я распаковываю IsDone и там пароль не подхватывается почему-то. Можно это исправить как-то?

Цитата:

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

Winrar же не задолбали те, у кого в v3 не открываются архивы v4.

Добавлено:
Добавил в сравнение Nanozip, но он меня не впечатлил - http://forum.ru-board.com/topic.cgi?forum=5&topic=8076&start=800#5 . Да, он чуть лучше чем простые режимы FreeArc, но хуже чем -m8*. Да, жмёт на 1/10% сильнее всех, но распаковывает также долго, в реальной жизни это бесполезно.

Цитата:

я распаковываю IsDone

а почему сразу не сказал? я зря время тратил, проверял. думаю что isdone надо просто перекомпилировать с использованием новых исходников freearc

Bulat_Ziganshin


Цитата:

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

Так получается с методом -mx, который включен в состав FA?

Добавлено:
muzf
Мне тест понравился.
На всякий случай скажу, что я все время экспериментирую и корректирую методы.
На сегодняшний день они выглядят так:
800 = rep:1gb:512:c512+xlz4
80 = rep:1gb:256:c256+xlz4
801 = rep:1gb:176:c128:d1m:s128+xlz4
802 = rep:1gb:128:c64:d1m:s64+xlz4

81f = rep:1gb:512:c512+xtor:3:4m:h4k ; Самый быстрый rep+tor:3
810 = rep:1gb:176:c128:d4m:s128+xtor:3:4m:h16k
81 = rep:1gb:112:c64:d4m:s64+xtor:3:4m:h32k

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:96:c16:d4m:s48:h25+4x4:tor:6:4mb:h8mb

85 = rep:1g:48:c16:d4m:s32+xlzma:4mb:h512k:fast:128:mc8

86 = rep:1g:48:c16:d4m:s24+xlzma:4m:h1m:normal:24:mc8

87 = rep:1gb:h24+4x4:i0:lzma:4mb:h32m:normal:bt4:128 ; 1396 МБ

88 = rep:1g+4x4:t2:i0:lzma:64mb:h64m:normal:bt4:128

89 = rep:1g+4x4:t1:i0:lzma:128mb:h128m:normal:bt4:128

Про метод -81f скажу, что его не планировал для использования. Просто в моих тестах такой получалась самая быстрая связка rep+tor:3. Его я держу чисто для сравнения с другими методами rep+tor:3 по времени.
Методы 83 и 82 планирую перевести на tor:6.

Bulat_Ziganshin

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