» FreeArc (часть 4)

Добрый день
Sergey_Advisor
Посмотрите DVDisaster или RSC32.

Bulat_Ziganshin
Когда-то в сети встречал opensource проекты Multipar и phpar2. Возможно ли использовать их в Вашем проекте?

Цитата:

странно, а у другого репакера вот наоборот юзеры через один писали об ошибке crc.

367 скачавших на данный момент - и ни одного нарекания - это о чём-то говорит ? Согласен, что один репак - это не показатель, но что имеем, то и имеем. Бум нарабатывать статистику дальше )))

Цитата:

1. Word'а нет совсем. В основном Html -странички, pdf.

И что? HTML - тоже текст.

Aerogiz


Цитата:

Встроенный во FreeArc SREP работает хуже чем отдельный?

В FreeARC нет встроенного SREP. Там есть REP. Поэтому когда ты пишешь -msrep и в arc.ini отсутствует секция srep, то srep просто игнорируется и ты получаешь просто
exe+delta+lzma:512mb:normal:bt4:273:lc8


Цитата:

Уже много сжимал различные данные сначала цепочкой SREP 2.95 (с параметром -m3 -l512)

-m3 -l512 используются по умолчанию, так что можешь их не указывать и сэкономить время.


Цитата:

а затем FreeArc 0.666 (с параметром delta+exe+lzma:512mb:normal:bt4:273:lc8)

У тебя неправильная строка. Ты хочешь использовать match finder BT4 со словарем в 512 mb, что невозможно. При BT4 и словаре больше 64 mb используется примерно 10.5 x d памяти, где d - это размер словаря. А так как FreeARC является 32-битным приложением, то выделить 5375 мегов памяти не выйдет по определению. Поэтому FreeARC просто понизит размер словаря и ты получишь
delta+exe+lzma:177mb:normal:bt4:273:lc8, а ведь можно задрать и побольше.

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

Насчёт srep 3.01:


Цитата:

i've tried it on LostPlanets2 archive lp2.pcf: 22,069,494,174 bytes

-m1:
srep64: 7,284,431,814 bytes in 151 seconds
srep32 3.0: 7,284,431,814 bytes in 285 seconds
srep32 3.01: 7,284,443,650 bytes in 159 seconds


-m3:
srep64: 7,009,388,668 bytes in 273 seconds
srep32 3.0: 7,009,388,668 bytes in 428 seconds
srep32 3.01: hasn't finished in 2 hours

probably, it's because reduced 32-bit hash produced too much collisions so srep keeps trying false match candidates. I should collect more stats to understand the situation (why who can help me by doing this work?)

the stats are required to understand whether the same problem possible in -m1 mode. If -m1 is guaranteed to work fast, i can incorporate into srep32 both matchfinders so that new one automatically used in -m1 mode. It's especially important since freearc 0.80 is expected to include 32-bit srep -m1 engine, so faster hashing will substantially inprove its speed

Добавлено:
MultiPar: "Please contact with me if you want to read source code of those applications. I want to know who is interested in my works. I am looking for a sponsor to aid development."

phpar2: исходники есть

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

Nikolai2004
учитывая, что формат устарел, сейчас самое время этим заняться

FreeArc-LZMA-x64.exe с последней альфы у меня почему то не хочет выделять при упаковке более ~3,6 гб памяти. Похоже на то, что игнорируются значения словаря начиная от примерно 356 мб (если говорить о bt4).

Nikolai2004 с Фа MS документы можно пожать в 2 и 3 раза....
Зачем опять изобретать велосипед?

Highpass спс за очень подробный ответ

V2driver

Цитата:

Зачем опять изобретать велосипед?

Вот именно. Особенно если учесть, что у офиса 2010 файлы по сути уже являются zip-архивами.

Цитата:

Цитата: не лучше было бы сделать этот процесс следующим образом:  
1) прекомпом обрабатывается каждый нужный файл отдельно  
2) далее идет упаковки lzma

это технически реализуемо, но требует работы, а есть куда более важные вещи

ну не знаю, по-моему рано вы .doc формат хороните. он такой же бессмертный как и .zip.

я вот в повседневной работе редко вижу чтобы кто-нибудь пользовался office 2007/2010 (из-за особенностей интерфейса). а если даже и пользуются, то в новый формат .docx ничего не сохраняют (по соображениям совместимости)

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


Цитата:

пару репаков всего лишь (FA 0.67 + SREP 2.96 + ISDone 0.6), но тем не менее...

интересна статистика - сравнивал srep с rep на них? распаковка идёт без временных файлов? какая скорость процесса распаковки в общем достигается?

кстати, натолкнулся при перепаковке LostPlanet2 на интересный приём. там после SREP данные уже почти не ужимаются, процентов на 10 с lzma:max:256m всего. из-за этого распаковка в lzma идёт довольно медленно - если обычно на моей тачке можно получить 40-50 мб/с, то там порядка 20, что гораздо медленней скорости чтения/записи дисков. пробовал tornado - он быстро распаковывает, но теряет в сжатии. зато если заменить lzma на xlzma:max, то получается самое то - распаковка становится в 2-4 раза быстрее за счёт многопоточности, а степень сжатия почти не падает

Добавлено:

Цитата:

у другого репакера вот наоборот юзеры через один писали об ошибке cr

skymmer на английском форуме тоже сообщил что в stdin-to-stdout mode данные считываются не до конца. как минимум в этом проблема. плюс ещё неясности по порче памяти

Добавлено:
добавил в шапку Форум Krinkels Inc

Nikolai2004

Цитата:

то в новый формат .docx ничего не сохраняют (по соображениям совместимости)

Время все исправит. Еще несколько лет и будут пользоваться, я многим в офисе поставил office 2007
Конечно 100% пользования .docx наверное ни когда не будет, ну или еще 30 лет надо для этого т.к. есть люди которые еще в некоторых офисах используют Win98 (ХР будет жив еще дольше, да и в офисах предполагается лиценз. программы, что отбивает у многих стимул покупать постоянно новые версии, как говориться - "Если все работает, то зачем что то менять")

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


Цитата:

FreeArc-LZMA-x64.exe с последней альфы у меня почему то не хочет выделять при упаковке более ~3,6 гб памяти. Похоже на то, что игнорируются значения словаря начиная от примерно 356 мб (если говорить о bt4).

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

Добавлено:
Custom right-click menu entries proposal: Open, edit, compress, decompress, rename, copy, move, delete, join, split, properties

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

С какими лучшше параметрами сжать srep файл содержащий .upk файлы?
Игра MassEffect, подскажите пожалуйста

Bulat_Ziganshin

Цитата:

skymmer
So. -m1 processing

ды с -m1 (-msrep:m1f:s250m) упаковка проходит корректно
но с распаковкой проблемы и у FreeArc и у Arc

Цитата:

ОШИБКА: ошибка записи (диск полон?) в алгоритме (рас)паковки srep:m1f:s250m

[more="Bulat_Ziganshin"]
здрасте
как то вы познакомили меня с утилиткой echooo.exe - не идет зараза на вин 7 64-бит =((
может сможете посоветовать альтернативу?[/more]

Цитата:

при распаковке можно воспользоваться isprecomp/srep:f, так что временных файлов не будет вовсе

а при упаковке? я паковал 4ГБ прекомп довел их до 11. соответственно получается чтобы упаковать 4Гб нужно 15Гб для временных файлов, при этом ещо и скорость упаковки / распаковки уменьшается, потому что создается лишний темп файл. я уже не говорю о том что будет если щей среп подключить. поэтому я бы на вашем месте не пренебрегал бы такой возможностью экономии ресурсов

Доброго всем времени суток.
Извините, если не в тему, но более подходящей не подвернулось.

Никто не пытался сделать компонент на базе FreeArc?
Ну вроде, компонента ZIPTV и пр., чтобы можно было использовать в архиватор своих прогах, без всяких довесок.
Спасибо.

Bulat_Ziganshin

Цитата:

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

Параметры: lzma:512mb:bt4
Проблема одинакова при упаковке и из GUI и через arc.exe. В диспетчере задач винды и Process Exlorer 3741484 кб.
Предыдущий компрессор (тогда еще назывался lzma-freearc-x64.exe от 1 сентября 2010) работает без нареканий.
При прямом сжатии через FreeArc-LZMA-x64.exe аналогичная ситуация с 3,6 гб.

AKN74
Это типа, чтобы без dll было?) И на делфи? Тогда либо надо переписывать весь код на паскале, либо имплантировать дллку внутрь ехе'шника и загружать вручную как делает UPX к примеру, либо использовать программу, типа dllmerge, которая все это делает автоматом.

4 репака - полёт нормальный
упаковка - arc a -r -di+$ --display -mt2 -s -w. -m=srep:mem75%%-150mb:f:a1:l128:c128+lzma:128mb:max:1024:bt4 -dpE:\WORK\SOLYANKA ns2011.arc

2 Bulat_Ziganshin:

Не знаю поднимался ли вопрос, но я в него уткнулся - EXE-архив НЕ распаковывается под NT4 (Service Pack6 ENG)

Понятно, что эта операционка уже почти раритет, но как всегда, в самый неожиданный момент...

Наглядный тест архиваторов на январь 2011 года

Участники тестирования: WinRAR 3.93, 7z 9.20 и FreeArc 0.67а (17 ноября 2010).

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

А на графике с осями "размер архива"х"время сжатия" - все сразу видно.
График для варианта "байт"х"мин:сек"

Каждый маркер обозначает один результат теста. Результаты разных архиваторов обозначены разными цветами. Слева вверху – быстрые режимы, справа внизу – максимальные режимы. У архиватора WinRAR маркеры «обычный», «хороший», «максимальный» неожиданно слились в один, т.е. между ними в данном тесте практически нет разницы!

График для варианта "размер архива в %"х"скорость сжатия (в логарифмическом масштабе)".

Такой вариант графика более универсален. Даже если на другом конце Земли кто-то будет сжимать с процессором типа i3-530, то легко заранее прикинуть требуемое время или выбрать режим.

Из графиков хорошо видно, что при одинаковой степени сжатия затраты времени у FreeArc в 2…5 раз меньше конкурентов! Особенно хорошее соотношение «степень сжатия/ время» у режима –mex8.
А методы -mex5...-mex7 выглядят неоптимально.
Методы –m9, -mx, ультра – одно и то же, для данной конфигурации компьютера.
Также видно, что «однопоточные» методы по времени значительно проигрывают «многопоточным». В дальнейшем их тестировать не вижу смысла.

PS Как лучше выкладывать рисунки: Превью или Картинка в тексте в полный размер?
Планирую сделать еще тест на других данных и добавить в них nanozip0.08.

Вопросы:
1. У FreeArc в встраиваемой Win-версии можно в командной строке задавать все те же параметры, что в консольной версии?
2. У меня в FreeArc (в встраиваемой Win-версии) накопились лишние профили сжатия. Не могу их убрать. А также упорядочить оставшиеся.
3. При архивировании больших папок в форматах 7z и zip - ошибка.

7z WinRar FA

Доброго всем времени суток.

Profrager.

Цитата:

Это типа, чтобы без dll было?)

Да.
Имхо не рулез таскать чужие dll и не иметь возможности что-либо исправить, если чего не комильфо.
Хотя, если без вариантов, то хоть единственную dll.

Цитата:

И на делфи?

Ну к чему такие крайности?
Разве в C нет возможности подключить сырцы с классом CFreeArcStream (название для примера)?
А в случае с dll, язык написания и вовсе без разницы.

ЗЫ. Знаю что не стол заказов - хотя бы помечтать.

cdman67

Цитата:

-m=srep:mem75%%-150mb:f:a1:l128:c128+lzma:128mb:max:1024:bt4

А что это за параметр 1024 ты задаешь? Уж не fb ли ?

AKN74

Цитата:

Имхо не рулез таскать чужие dll и не иметь возможности что-либо исправить, если чего не комильфо.

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

Цитата:

Хотя, если без вариантов, то хоть единственную dll.

некоторые варианты избавления от длл я тебе уже предложил.

Цитата:

Цитата: И на делфи?

Ну к чему такие крайности?