» FreeArc (часть 4)

с большими файлами проблем нет, на каждый файл тратится порядка 1 кб озу при упаковке и распаковке (это помимо памяти для собственно сжатия), кроме того не поддерживаются имена файлов на диске длиннее 256 симолов

Огромное СПАСИБО за Bаш архиватор,пользуюсь довольно продолжительное время,
недавно возник вопрос - возможно ли добавить маску для файлов добавляемых в архив без сжатия (аналогично РАРовскому) ?
к примеру имеется папка с игрой ,в которой половина мультимедийных файлов скажем *.bik расширения.
можно ли добавить в профиль это расширение что бы файлы этого типа добавлялись в архив без сжатия?

Посмотрим.
А что, rep стал хуже сжимать?
Это не нужно!
По-моему он и так быстрый, ему бы сильнее сжимать.

Баг №2
только у меня воспроизводится ?

Bulat_Ziganshin

А можно заархивировать, например, 200 000 файлов по 3 Кб формата html?

Shuld
лучше уж среп дорабатывать и прикручивать в алгоритм, чем тратить время на рэп!

Bulat_Ziganshin
Зачем вы его дорабатываете? Какой смысл в этом, если есть лучшая альтернатива?

да, конечно

Цитата:

1. Запароленный архив:
Открываем разные архивы при помощи FA и на предложение ввести пароль жмём Cancel:
arc - Operation terminated by user!
7z - Prelude.undefined
rar - Prelude.undefined
Последние 2 мне показались не совсем понятными.

с обработкой cancel/^break пока полный бардак


Цитата:

2. Извлечение из архива:
http://freearc.org/download/0.666/FreeArc-portable-0.666-win32.zip
Right Click --> FreeArc --> Open with FreeArc --> заходим в папку share\themes --> выбираем AnachronAna --> Extract --> D:\test1 --> OK  

Цитата:
FILES SUCCESFULLY EXTRACTED FROM D:\FreeArc-portable-0.666-win32.zip

В рузультате папки D:\test1 нет.
1. arc - папка есть
2. zip - папки нет
3. 7z - папки нет

то же самое в http://encode.ru/threads/43-FreeArc?p=28958&viewfull=1#post28958

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

я за -ap брался прошлой весной и завяз. попробую взяться снова..


Цитата:

3. Извлечение файлов из архива двойной вложенности:
На примере gz я уже писал.
То же у меня сейчас повторилось на arc-arc arc-rar, т.е. скорее всего не зависит от формата архива.

с gz понятно было - из a.tar-1.gz извлекался a.tar-1, и дальше стандартное открытие не работало. с arc-arc, полагаю, то же самое?

Добавлено:

Цитата:

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

включить их в группу compressed в arc.groups И добавить в комстроку опцию -m$compressed=storing или скажем -m$compressed=rep:256m

Shuld
окончательное сжатие (с учётом tor/lzma) изменилось несильно, и то в основном в быстрых режимах. а скорости rep, как я уже говорил, было недостаточно для -m1 на многоядерных машинах. в моих результатах это хорошо видно - у меня rep+xtor:3 стал вдвое быстрее

как существенно улучшить результаты rep - я не знаю

vasulpr
у srep есть свои недостатки, в первую очередь неспособность обрабатывать данные чисто последовательно. поэтому я его не прикручиваю к fa. впрочем, методика ускорения там одинакова - я её сейчас опробовал на rep, затем прикручу к srep тоже

SREP 3.91 beta released:English release notes
Russian release notes
Download

Bulat_Ziganshin
Покрутил новый реп.
Везде есть небольшое ускорение.

1. На быстрых методах (tor) ускорение сопровождается небольшим ухудшением сжатия, настолько небольшим, что вполне оправдано!
2. На методах lzma я как правило наблюдаю улучшение сжатия(?!) Приятный сюрприз.
Но непонятный.

Как я понял по умолчанию сделали h26->h24?
У меня на работе есть одна папка, которая при h24 сжимается намного хуже, завтра посмотрю.

:c, размер чанка - мне непонятно, где посмотреть?

Добавлено:
ps я имел ввиду, что Вы уменьшили размер хэша по умолчанию?

Цитата:

с gz понятно было - из a.tar-1.gz извлекался a.tar-1, и дальше стандартное открытие не работало. с arc-arc, полагаю, то же самое?

Уже не наюблюдается этой проблемы.
arc-zip, arc-acr - всё ок.
С баг 1 дело видать непростое.
Баг 2 доставляет неудобства.

готов предоставить свой ПК для теста FreeArc 0.70 или какая планируется бета-версия...

[more=подробнее тут]
готов предоставить свой ПК для теста FreeArc 0.70 или какая планируется бета-версия...

Win 7 Ultimate 64bit Rus,
AMD Phenom X4 945 3,0@3,37 GHz (overclock +20%),
ASUS M5A78LM L-X,
DDR3 1600 8Gb (2х4GB)
Nvidia GeForce 440GT 1024/128/DDR5,
Realtek HD Audio 5.1,
500+1000GB HDD's

аська 77054620 или vitalikvolod@gmail.com[/more]

Bulat_Ziganshin
а в именах папок wildcards не поддерживаются что ли?

есть у меня несколько папок abc1, abc2, abc3, ...
а в них файлы вида file.2013-01-01, file.2013-01-02, и т.д.

хотел я сделать архив с файлами за январь со всех папок:

> arc a files_2013-01.arc abc*\file.2013-01*
WARNING: can't read directory "abc*"
WARNING: no files, erasing empty archive

> arc a files_2013-01.arc -n*2013-01* abc*
WARNING: no files, erasing empty archive

> arc a all_files.arc abc*
WARNING: no files, erasing empty archive

я что-то делаю не так?
FreeArc 0.666

Странно, но то ли я делаю что-то неправильно, то ли действительно srep вообще не работает.

Создаю архивы при помощи комманды из ТоталКоммандера
<...>arc.exe ? a "_%O.arc" %S -m9x -i2 -lc- -ld- -di -mc:rep/srep:mem256mb -ag
(где %O и %S - переменные ТК, имя файла и список выделеных файлов, соответственно).

Так вот, что интересно, наличие "-mc:rep/srep:mem256mb" или отсутствие ровным счётом не даёт ничего (проверил уже на разных папках (софт, игры, документы) разных размеров), а в результате я получаю два одинаковых архива (пакую: 1-й - с параметром, 2-й - без).

Srep.exe, srep32i.exe, srep64i.exe (все 3.0.1) лежат возле Arc.exe (альфа 20.05.2012, прошлая - такая же).

Shuld
:c по умолчанию = :l-1, округлённое вниз до ближайшей степени 2. т.е. :l512 -> :c256, :l511 -> :c256, :l513 -> :c512. весь файл разбивается на куски длины :c, и индексируются и ищутся совпадения именно среди них

2. дело в том, что новый REP находит меньше совпадений длины, близкой к 512 байтам (т.е. :l). но поскольку такие совпадения находятся "на грани" и частенько дают даже проигрыш, на результате rep+lzma эти проблемы REP почти не сказываются. а в связке rep+tor важнее скорость

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



Цитата:

Как я понял по умолчанию сделали h26->h24?

да. сейчас по умолчанию размер хеш-таблицы равен учетверённому размеру таблицы, достаточной для сохранения всех хешей чанков. чанк по умолчанию - 256 байт, соответственно при 1 гб словаре у нас 4 миллиона чанков, а хеш-таблица заводится на 16 миллионов (2^24) записей, т.е. 64 мб. при меньшем размере чанка размер хеш-таблицы по умолчанию увеличивается, но не превышает четверти размера буфера. вручную конечно можно поставить больше

а тебе заранее могу сказать, что выигрыша от h26 не будет, поскольку хеш-таблица индексируется хешем, имеющим максимальное значение из 256 (:c) подряд расположенных хешей. поэтому среднестатистически все хеши попадают в диапазон размером 2^32/256==2^24 варианта и больший размер хеш-таблицы при rep:1g:c256 просто почти бесполезен

Булат, в версии SREP 3.9.1. с параметром m1, m2, m1f, m2f, m1o, m2o вылетает ошибка (http://i5.pixs.ru/storage/1/6/1/faPNG_8447939_8377161.png). WinXPx86
на версии 3.9 полёт нормальный.
С остальным m3-5(o/f) всё нормально

Цитата:

Баг 2 доставляет неудобства.

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


Цитата:

-m9x

не использует rep, поэтому замещать нечего. советую использовать -di и -di+$ для получения информации об алгоритмах. в данном случае можешь попробовать -mc$default+srep:256m, но учти что srep будет использовать 256 мб и lzma столько же

С консольной версией пока проблем не заметил.
А FreeArc.exe у меня не работает. Выбираю папку, вызываю контекстное меню, запускаю , задаю -m4 и вылетает.
(Я просто скопировал FreeArc.exe в папку програмфайл вместо декабрьского)

Цитата:

а в именах папок wildcards не поддерживаются что ли?

нет

Edison007007
а у меня успешно работает. попробуй

srep32s.exe -m1 srep64i.exe

Bulat_Ziganshin
т.е, это
Цитата:

-mc$default+srep:256m

нужно ВМЕСТО "-m9x", я правильно понял?

Shuld
это потому что facompress.dll несовместим. скопируй его тоже

Bulat_Ziganshin
точно, если взять экзeшник (любой 32i, 32s, 32m) из папки "exe", то всё нормально.
Но со srep.exe такая ошибка

insorg
нет. может тебе прочесть наконец доку + описание -mc?

Bulat_Ziganshin
Здравствуйте, решил прикрутить кодирование wav в ogg как внешний компрессор в arc.ini

[no]
[External compressor:OGG]
packcmd = OGE -q{option} .\$$arcdatafile$$.wav .\*
unpackcmd = OGD $$arcdatafile$$.ogg
datafile = $$arcdatafile$$.wav
packedfile = $$arcdatafile$$.ogg
solid = 0
[/no]

Потом в батнике пишу
[no]
arc.exe a -ep1 -dses --dirs -s; -lc- -di -i2 -r -mOGG:Q10 123456.arc sound\*
[/no]

Проходит кодирование, но почему то очень низкая степень сжатия у ogg, если делать это батником то сжимает намного сильнее.

Ну и в конечном архиве оказываются не *.ogg файлы а wav из папки sound.
Что я не правильно делаю? Подскажите пожалуйста.

Edison007007
процессор какой? ты там descript.ion читал?

Цитата:

нет. может тебе прочесть наконец доку + описание -mc?

да, вот же, уж четвёртый день даже не закрываю, изучаю-экспериментю.
так-то вроде более-менее разобрался что к чему, но этот самый srep меня немного тормозит, хотя желание его попользовать велико (и, если верить, что он ест памяти всего 7-15% относительно размера словаря, то оно мне оч необходимо).


Цитата:

-mc$default+srep:256m

результат - прерывание упаковки с выводом:
Errorlevel=2
17.3%
ERROR: general (de)compression error in srep:256m
скриншот - http://savepic.su/1978392.png (оперативки - 12 гигов, из них свободно почти 10)

А, грубо говоря, если я хочу задать условия, схожие с "-m9x -i2 -lc- -ld-" (т.е., "дать асинхрон" и выжать полный максимум из максимально возможного сжатия), на что следует заменить выделеное цветом?
И осуществима ли здесь асинхронка вообще?

Цитата:

Проходит кодирование, но почему то очень низкая степень сжатия у ogg, если делать это батником то сжимает намного сильнее.

попробуй для начала один файл сжать, посмотри на команду которую freearc генерит


Цитата:

Ну и в конечном архиве оказываются не *.ogg  файлы а wav из папки sound.

а тебя не удивляет что при lzma компрессии в архиве оказываются исходные exe, а не какие-нибудь lzma? это принцип работы внешних методов

кстати при сжатии с потерями ещё и crc при распаковке не будет сходиться

and finally, SREP breaks 1GB/s barrier for the LZ77-based deduplication:

C:\>srep64g.exe -b64m -mmap -nomd5 -v -s- -l64k-a64/32 z:\4g nul
100%: 4,531,060,447 -> 3,760,453,399: 82.99%.
Cpu 834 mb/s (5.179 sec), real 1028 mb/s (4.202 sec) = 123%

Bulat_Ziganshin

Зачем в новой альфе приписывать арку стандартные параметры для прекомпа? Пиши -mprecomp, а оно его в 042 переименовывает и само добавляет парамы. Теперь при распаковке через анарк длл пишет что метод не поддерживается.