» FreeArc: бесплатный open-source архиватор

Цитата:

Bulat_Ziganshin
Всеравно GUI не работает с этим arc.ini

у меня никаких проблем. установил 06.23, затем накатил сверху эти три файла. может, какая-то проблема связанная с моей ОС? кстати, консольный arc.exe рабботает?

кто ещё может подтвердить/опровергнуть проблемы с распаковкой новым freearc?


Цитата:

lpaq9j пытаюсь

настрой отдельно drt и lpaq. так сможешь?

опубликовал новую версию arc1.arc, поддерживающую CLS ( http://encode.ru/forum/showthread.php?p=3252#post3252 ). представляет интерес только для тех, кто хочет сам подцепить новые методы сжатия к FreeArc не затрагивая его исходников

Bulat_Ziganshin

Цитата:

кстати, консольный arc.exe

Все оказалось до смеха просто Из-за --logfile. У меня этого каталога не было, и ничего гуи не говорил, а вот консольная версия это сразу указала. По-моему раньше это не было ошибкой.
Ещё поигрался со случайным символом в первых двух строчках
Например:
dd ;Default ...
;--logfile ...
или
;Default ...
sdfd --logfile ...

раньше вторая строчка была закомментирована. спасибо, счас исправлю

Начиная с прошлого обновления (справедливо и для последнего) у меня перестало работать GUI. Окно появляется, можно походить по опциям, но никаких действий на "упаковать", "распаковать" не происходит. К сожалению, не осталось позапрошлого обновления, на котором всё ещё работало, так что пробую откатываться на FreeArc-0.50-win32-alpha-2008-06-23 и всё в порядке

Gideon Vi
в конфиге перед --logfile поставте ;

Цитата:

в конфиге перед --logfile поставте ;

Спасибо, работает.

now i've restored original ini from shipped FreeArc with improvements to parameter handling. now you can use things like paq:4, lpaq:8, ccm:6, 7z:1:d32m, uharc:z:d32768, dul:m256:o16

ok, i have the following ideas for further extending externals support:

numopt = o
numopts = --fastest --fast --normal --good --best
memopt = m
memopt:mb = m
packcmd:stdio = ...
packcmd:stdin = ...
packcmd:stdout = ...

i hope these doesn't need further explanations

Bulat_Ziganshin
тут можно и не надеется
за что stdio будет отвечать? в C это библиотека, и получается легкий сумбур в понимании.

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

Bulat_Ziganshin

1) Скажите, плз, когда примерно FreeArc можно будет использовать для еженедельного бэкапа данных - с точки зрения стабильности и надёжности (скорость работы, как я понимаю, и так неплохая)?

2) Каково сейчас примерное предельное количество файлов с длинными именами, которое он сможет ужать в один архив при ОЗУ в 2 Гб?

pat357 с форума encode опубликовал свой arc.ini, включающий поддержку огромного числа внешних упаковщиков, и сами эти упаковщики в одном пакете: http://www.haskell.org/bz/freearc-powerpack.arc


Цитата:

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

я бы подождал несколько лет


Цитата:

2) Каково сейчас примерное предельное количество файлов с длинными именами, которое он сможет ужать в один архив при ОЗУ в 2 Гб?

в доке ж написано - примерно 500 байт на файл

Bulat_Ziganshin
Насколько использование мульти-конфига зависит от конфигурации системы?

кто-нибудь знает технологию NOSSO
которую использует в Adobe Reader 9, чем только я не пытался сжать установочные файлы, которые нашёл в следующей папке

C:\Program Files\Adobe\Reader 9.0\Setup Files

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

lorents

Цитата:

кто-нибудь знает технологию NOSSO

здесь и ниже рассматривали
http://forum.ru-board.com/topic.cgi?forum=5&topic=24319&start=1440#7

Цитата:

Насколько использование мульти-конфига зависит от конфигурации системы?

переведи )

Bulat_Ziganshin
Попробую
я так понял, что он расчитан на машины с 1 или >1 гигабайтом памяти. Или я ошибаюсь?

Там нанозип вышел 0.05 ))

Цитата:

я так понял, что он расчитан на машины с 1 или >1 гигабайтом памяти. Или я ошибаюсь?

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

Процитирую Булата:

Цитата:

updated http://www.haskell.org/bz/arc1.arc :

- updated CLS to current version
- added -m=tor:9:c1 .. -m=tor:11:c3 modes
- added -m1xx..-m4xx modes providing super-fast decompression using tornado (note: they need 1gb free memory to decompress!)
- added paq8* compressors support (using just one block parameterized with {compressor} - look at it, pat357)

updated http://www.haskell.org/bz/arc1.arc :

1. updated CLS to current version
2. added -m=tor:9:c1 .. -m=tor:11:c3 modes
3. added -m1xx..-m4xx modes providing super-fast decompression using tornado (note: they need 1gb free memory to decompress!)
4. added paq8* compressors support (using just one block parameterized with {compressor} - look at it, pat357)

кстати, в http://www.maximumcompression.com/data/summary_mf2.php#data nanozip занял своё законное 4-е место. причём, редим -cO выглядит попривлекательней, чем freearc mx/ccm/rzm и только из-за метрики, учитывающей лишь время сжатия, не попал на первое место

Bulat_Ziganshin

Цитата:

кстати, в http://www.maximumcompression.com/data/summary_mf2.php#data nanozip занял своё законное 4-е место. причём, редим -cO выглядит попривлекательней, чем freearc mx/ccm/rzm и только из-за метрики, учитывающей лишь время сжатия, не попал на первое место

В наше время быстрых каналов и дешевых носителей данных огромных объемов именно время сжатия/разжатия играет основную роль

Смотрим. По эффективности у nanozip нет приемущества. Если сравнивать режимы, сопоставимые по времени компрессии/декомпрессии, то оба архиватора дают примерно одинаковый результат:

                size        ratio        comp time        decomp time

003    FreeARC 0.50a    79642328    74.83    188            65
004    NanoZip 0.04a    80802431    74.46    185            56

Если же брать режим -cO, то там:

012    NanoZip 0.04a    75989377    75.98    557            103

...то есть трехкратный проигрышь по времени сжатия и почти двукратный - при декомпрессии. Т.е. на все архивные операции в сумме уходит 4мин 13с у FreeArc (none) и NanoZip (none) против 11 минут у NanoZip в режиме -cO. При этом выигрышь в размере архива - 3.6 мегабайта (на моем канале - лишние 5 секунд при скачивании). Разница между 4 мин. 18с. и 11 минутами очевидна.

Если же объем сжимаемых будет раз в 5-10 больше, то NanoZip -cO становится в принципе малопригодным из-за недостатка скорости - никто в здравом уме не будет тратить лишние полчаса на компрессию, чтобы получить выигрышь в размере, который можно прокачать за пол-минуты.

Кстати. При наличии во FreeArc мультимедиа-фильтров (в частности на графические форматы) разрыв между FA и nanozip был бы еще больше.

Цитата:

Кстати. При наличии во FreeArc мультимедиа-фильтров (в частности на графические форматы) разрыв между FA и nanozip был бы еще больше.

А они у FA есть, а для аудио - полноценный кодек. конечно, фильтры хуже, чем кодеки.
детектирования мультимедиа в середине файла, afaik, тоже нет( это ещё и проблема формата архива).
Nanozip в быстрых режимах показывает себя плохо. В самом быстром у него вообще lzp, от которого отказались в Fa 0.40, т.к. tornado лучше. вообще по ощущениям, на моем древнем Celeron 850 - FA при срвнимом сжатии на 20-50% быстрее NZ. для меня всё, что выше -m4 FA - бесполезно из-за скорости.

Registered User

Цитата:

А они у FA есть, а для аудио - полноценный кодек. конечно, фильтры хуже, чем кодеки

Я имел ввиду фильтры для несжатой графики (.bmp и т.д), которых в текущей версии FA, насколько я знаю, вообще нет.

Цитата:

Я имел ввиду фильтры для несжатой графики (.bmp и т.д), которых в текущей версии FA, насколько я знаю, вообще нет.

Код: C:\Documents and Settings\###>arc --print-config

[...]
;Bitmap graphic files are best compressed with GRZip algorithm
bmp = mm + grzip:m1:l:a ;best compression
bmpfast = mm + grzip:m4:l:a ;faster compression
bmpfastest = mm:d1 + tor:2 ;fastest one
1$bmp = bmpfastest
2$bmp = bmpfastest
3$bmp = bmpfast
#$bmp = bmp
1x$bmp = bmpfastest
2x$bmp = bmpfastest
#x$bmp = mm+#xb
#p$bmp = bmp
#r$bmp = #$bmp

[...]
C:\Documents and Settings\###>

Ну и когда примерно новая версия выйдет???? кто знает

Цитата:

Ну и когда примерно новая версия выйдет???? кто знает

Bulat_Ziganshin
знает Скоро!

Так я и не понял можно по кускам сжимать ну типа в размер..... читал ситал так и не понял

softweri1

Цитата:

Так я и не понял можно по кускам сжимать ну типа в размер....

Если ты про многотомные архивы (чтоб нарезать архив по кускам заданного размера) то нет, пока не может.