» FreeArc (часть 4)

Всем привет! вообщем хотелось бы сжать как можно лучьше файлы из игры fallout new vegas
так вот, как можно добиться максимального сжатия, очень надо поджать практически 2 гига.

Цитата:

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

tor и xtor используются в методах -m8* в freearc, подключается через экспериментальный ini, Shuld выше описал.

Bulat_Ziganshin,
Как в буфер теперь передавать пароль для unarc.dll в делфи? я так понимаю из-за этого сейчас пароли не принимает:

Цитата:

bool callback;

char DLLUI::AskPassword (char *pwd, int pwdbuf_size)
{
return callback? event ("password?", pwdbuf_size, 0, pwd)
: 'n';
}

Цитата:

4x4:tor

xtor

Цитата:

4x4:t2:i0:lzma

xlzma

Добавлено:

Цитата:

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

а такие были?


Цитата:

Жаль tor и xtor отсутствуют

для практического применения ударная комбинация - rep+xtor, всё остальное имеет сугубо научный интерес

Snoopak96

в UnarcDllExample.cpp код такой:

Код: int __stdcall callback (char *what, Number int1, Number int2, char *str)
{
if (strequ (what, "password?"))
{printf("Enter password:"); gets(str);}

printf("callback(\"%s\", %d, %d, \"%s\")\n", what, int1, int2, str);
if (strequ (what, "password?"))
return 'y';
else if (strequ (what, "overwrite?"))
return 'y';
else
return 1;
}

Bulat_Ziganshin

Цитата:

для практического применения ударная комбинация - rep+xtor, всё остальное имеет сугубо научный интерес

На двухядерном xtor выглядит как то не очень по сравнению с tor. На четырёхядерном да, xtor просто отличный вариант.
Примеры приводить ?

Shuld

Цитата:

81f = rep:1gb:512:c512+xtor:3:4m:h4k ; Самый быстрый rep+tor:3

Кстати быстродействие очень сильно зависит от кеша проца.

Bulat_Ziganshin
Цитата:

а такие были?

Видимо имелся в виду случай с вводом нового формата в ВинРАР 3.0, для распаковки которого требовался ВинРАР 2.9 или новее.
То же самое справедливо и для 7з 9-й версии и ЛЗМА2...

Bulat_Ziganshin
спасибо)

Добавлено:
1noObman1
http://krinkels.org/downloads.php?do=file&id=110

Snoopak96

Спасибо огромное.

ndch
да, попробуй -m2/-m3 для сравнения

Добавлено:

Цитата:

Кстати быстродействие очень сильно зависит от кеша проца.

Shuld оптимизрует под свою машину и свой набор данных

Существует ли интерфейс для работы с FA из .NET?
Хочется воспользоваться этим архиватором из ASP.NET приложения, поэтому вариант запуска процесса на каждую операцию не подходит по соображениям производительности.
Спасибо.

Shuld
Цитата:

На всякий случай скажу, что я все время экспериментирую и корректирую методы.
На сегодняшний день они выглядят так: ...

Сравнение старого и нового -m8*

Код: 81 = rep:1gb:64:c64+xtor:3:4m:h32k
81new = rep:1gb:112:c64:d4m:s64+xtor:3:4m:h32k
84 = rep:1gb:64:c16:d4m:s32+xtor:4:4m:h8m:l8
84new = rep:1gb:96:c16:d4m:s48:h25+4x4:tor:6:4mb:h8mb
85 = rep:1g:64:c32+xlzma:4mb:h512k:fast:128:mc8
85new = rep:1g:48:c16:d4m:s32+xlzma:4mb:h512k:fast:128:mc8
86 = rep:1g:64:c32+xlzma:4m:h1m:normal:24:mc8
86new = rep:1g:48:c16:d4m:s24+xlzma:4m:h1m:normal:24:mc8
87 = rep:1gb:h24+4x4:t3:i0:lzma:8mb:h32mb:normal:bt4:128 ;1427МБ
87new = rep:1gb:h24+4x4:i0:lzma:4mb:h32m:normal:bt4:128 ; 1396 МБ

нет

muzf

Код: -m84new

[more] У меня вопрос про оптимальную паковку данных, состоящих из N-битовых значений.

Осуществляю проект по генерации 7-фигурных шахматных окончаний. То есть, если на доске не больше 7-фигур, то по таблице можно сразу получить ответ, кто выигрывает и за сколько ходов. Основные вычисления уже проведены. В итоге получилось около 100 ТБ данных, сжатых по алгоритму LZMA.

При генерации самым важным вопросом было наилучшее сжатие целочисленных данных (2-байтовых значений).

А вот для использования на первое место выходит скорость распаковки и возможность распаковки небольших блоков (8 КБ) из любого места большого файла. Так что запланирована перепаковка, и идет выбор лучшего архиватора, который обеспечит приличное сжатие при высокой скорости распаковки. Паковка делается один раз, и время паковки практического значения не имеет.

1. Для экономии памяти данные (которые представляют из себя значения о 0 до 2000) представляются в в N-битовом формате. N вычисляется, исходя их максимального имеющегося в файле значения. Первые эксперименты по архивации показывают, что хотя в несжатом виде объемы данных заметно снижаются, в сжатом виде файлы наоборот увеличиваются. То есть, получается, что методы паковки не заточены под битовые данные. Можно, конечно, сжимать как и раньше 16-битовые значения, а потом переводить их в N-битовый формат после чтения блока, но всё-таки это дополнительный проход, и интересно, можно ли улучшить сжатие именно N-битовых значений.
Тестировал вот на этом наборе 7-битовых значений.
https://dl.dropbox.com/u/72038782/res7.bin (~1 400 000 байт)
7-zip и FreeArc дают на выходе 773 300-773 400 байт
Если же кодировать те же самые значения в 8-битовом формате
https://dl.dropbox.com/u/72038782/res8.bin (~1 600 000 байт)
то на выходе получается ~480 000 байт. То есть разница очень приличная.

2. При переходе на блочную структуру файлов происходит значительное увеличение их размера (до 40%). Есть ли методы сжимать файл целиком, строить какой-то единый словарь для всего файла, но иметь возможность распаковать любой 8КБ блок независимо от остальных.

Скорость паковки значения не имеет. А вот распаковку хочется иметь достаточно быструю.

Буду благодарен за любые советы. [/more]

Цитата:

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

не хватало адресного пространства. это уж принципиальная проблема fa - всегда можно найти комп где меньше 1 гб непрерывного пространства и он превратит rep+xtor в rep+tempfile+xtor. как говорится, надо в генах править, благо что в unarc такая правка уже есть

Цитата:

Не так уж важно, какая версия метода, как важно есть он или нет.

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

Булат, чтобы привести Freearc к мировому господству, нужны следующие шаги:
1. Требуемая версия дла распаковки, указанная в заголовке архива. Чтобы как ты говоришь не было проблем с попыткой распаковать новый архив на старой версии.
2. Быстрые методы m8* из коробки
3. Мультимедиа-сжатие jpg/mp3 из коробки через packarc без precomp
4. Для пункта 3 без использования цепочек external compressors - чтобы не создавался временный файл (мы это обсуждали чуть выше с тобой).
5. Позиционирование freearc не только как универсального архиватора, но и самого сильного и быстрого средства для бэкапа, ввод возможности --sync в GUI чтобы даже простые люди могли задать бэкап раздела/папок по расписанию с возможностью исключения некоторых папок. StuffIt и WinZip сразу идут лесом.
6. Profit!

EGTB7
вам сюда

muzf
Вы могли бы попробовать вообще rep:2g+... (Я назвал бы эти методы -m9x)
И может получиться много интересного, от улучшения сжатия до нехватки памяти/ адресного пространства.

А работает ли во FreeArc блочное сжатие, то есть паковка/распаковка частей файла независимо от остальных. Если да, то какой минимальный размер блока. Я попробовал использовать опции
–md8kb, –md16kb, –md32kb, –md64kb. Размеры итоговых файлов действительно менялись, но иногда при использовании разных опций я получал одинаковые размеры, и, наоборот, с одной и той же опцией получал разные размеры архива.

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

Shuld
Опиши как он должны выглядить внутри ini , только дай им другое имя, -m9x вроде как занято.

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

[more] Булат, спасибо большое за ответы на мои наивные вопросы - пытаюсь чуть поглубже войти в методы архивации. Благодря FreeArc получил много полезной информации.

Конечно, стандартным архиватором части файла не собирался паковать. У меня 100 ТБ данных (десятки винчестеров в разных компьютерах!) Есть программа, которая читает отдельные байты из этого объема почти в случайном порядке. Сейчас данные разбиты на независимые блоки по 2МБ и сжаты методом LZMA, но такой размер блока оказался очень большим. Поэтому начинается переход на блоки 8KB. Хочется не так сильно потерять в плотности паковки, поэтому исследую, что лучшего с открытым кодом имеется в мире. Заодно смотрю и на скорость распаковки. Результаты пока такие: при переходе на 8 КБ деградация степени сжатия где-то 35% - но этот результат все-таки терпим. А вот распаковку хочется раза в 3 ускорить. Сейчас в приложении она на первом месте в профайлере.

Попробовал много различных архиваторов. Результаты в основном удручающие. LZMA - это LZMA.

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

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

Сегодня еще поиследую тему и буду принимать решение, в какой формат перегонять данные. [/more]

Benchmark
3-е и 4-е измерение?

что вы думаете о таком виде диалога прогресса (v1)?



а вот старый для сравнения (v0):

Bulat_Ziganshin
Не, ну зачем Хотя бы отдельную колоночку рядом.

Скажите пожалуйста как добиться более максимального сжатия той же игры пес 2013

Benchmark
Я предлагаю это указывать в GUI Freearc при выборе метода сжатия. Но в целом это не интересно, когда планка 4Gb стоит 500р.

Bulat_Ziganshin
Вполне прилично,по-моему.Глаза не разбегаются по диалогу и информация на виду.