Ru-Board.club
← Вернуться в раздел «Программы»

» Архиваторы. Сравнение сжатия

Автор: Panzer
Дата сообщения: 05.05.2005 13:42
Widok
http://enotus.at.tut.by/Articles/ArchiversReview/index.html
- более продвинутый вариант приведенной тобой статьи. Вот здесь видно, что человек понимает, что делает (хотя, конечно, есть вопросы), а то последнее время что ни статья про архиваторы, так детство пополам с рекламой.
Автор: arsvrn
Дата сообщения: 05.05.2005 15:10
Panzer

Цитата:
более продвинутый вариант приведенной тобой статьи

Если под этим имеется ввиду статья из поста от 29.04.05 сравнение 10 архиваторов, то разницы между ними никакой нет...

Автор: Panzer
Дата сообщения: 05.05.2005 15:36
arsvrn

Цитата:
Если под этим имеется ввиду статья из поста от 29.04.05 сравнение 10 архиваторов, то разницы между ними никакой нет...

Действительно. Не заметил, что по ссылке от Widokстатья разбита на несколько частей
Автор: TCPIP
Дата сообщения: 05.05.2005 18:32
arsvrn
14:13 05-05-2005
Цитата:
немецкие, голландские, китайские" наверное не нужны

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

Цитата:
то его надо жать wav-архиваторами

Думаю, что так.
Автор: TCPIP
Дата сообщения: 08.05.2005 00:55
Отвечаю на вопрос в теме по WinUHA
evle
07:18 06-05-2005
Цитата:
Попробовал 5 и 8, пика не наблюдаю, на пару КБ больше, но мы немного от темы отклоняемся, 7-Zip я привел потому, что он текст сжал лучше, чем UHA. Сегодня на других данных погоняю.

Сорри. Пик эффективности. Дальше скорость роста степени сжатия не так велика.
Но, тем не менее, главная идея в том, что если установка размера слова в PPMZ на максимум даст провал только по скорости (то есть можно просто поставить 255 символов и забыть), то установка поряка PPMD-модели в 32 не гарантирует лучшего сжатия. Порядок 5 может дать лучшие результаты. С этим кстати отлично справляется WinRAR --- он автоматически подбирает порядок.
Автор: Panzer
Дата сообщения: 12.05.2005 13:49
TCPIP

Цитата:
Сорри. Пик эффективности. Дальше скорость роста степени сжатия не так велика.
Но, тем не менее, главная идея в том, что если установка размера слова в PPMZ на максимум даст провал только по скорости (то есть можно просто поставить 255 символов и забыть), то установка поряка PPMD-модели в 32 не гарантирует лучшего сжатия.

Мои впечатления:
1. Скорость сжатия при изменении порядка PPMD-модели в 7zip меняется незначительно.
2. Степень сжатия плавает непонятным для меня образом. Первые 1-4 значения однозначно плохие, дальше загадка. Разница, скажем, между 8 и 32 может быть более 15% как в ту, так и в другую сторону. Чисто эмпирически, мне показалось, что для файлов > 30 Mb лучшие результаты дает макс. порядок.
В своих тестах я прогонял 7zip на всех порядках PPMD.
Автор: TCPIP
Дата сообщения: 12.05.2005 22:28
Panzer
14:49 12-05-2005
Цитата:
Скорость сжатия

Не скорость сжатия, а

Цитата:
скорость роста степени сжатия

Слаб я в контекстном моделировании... но in-da-wild видел текстовый файл, который с моделью порядка 8 сжался лучше, чем с моделью 32. Ну а скачок 2-8 обычно весьма большой.

Автор: enotus1
Дата сообщения: 13.05.2005 21:50

Цитата:
Widok
http://enotus.at.tut.by/Articles/ArchiversReview/index.html
- более продвинутый вариант приведенной тобой статьи. Вот здесь видно, что человек понимает, что делает (хотя, конечно, есть вопросы), а то последнее время что ни статья про архиваторы, так детство пополам с рекламой.


Цитата:
Действительно. Не заметил, что по ссылке от Widokстатья разбита на несколько частей

Testirovanie odno. Na enotus.at.tut.by original, na techlabs.ru - publikacia (mestami neudachnaya i s oshibkamy).

Interesny voprosy i kritika, t.k. schitau chto poluchilos neploho.
Автор: Panzer
Дата сообщения: 14.05.2005 12:19
enotus1

Цитата:
Interesny voprosy i kritika, t.k. schitau chto poluchilos neploho.

Самое общее замечание - не хватает конкретики. Размера архивов в байтах и времени работы в секундах. Хотя бы в примечаниях для особо интересующихся
Автор: TCPIP
Дата сообщения: 14.05.2005 23:57
enotus1
22:50 13-05-2005
Цитата:
Interesny voprosy i kritika, t.k. schitau chto poluchilos neploho.

Действительно хорошо. Но вопросы есть.

Цитата:
Чем больше порядок модели, тем выше степень сжатия

Насколько я понимаю, вообще говоря. То есть может быть и наоборот.


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

Ух-ты. Например?

Ну и мелкие рекомендации, несущественные придирки:
Хорошо бы пояснить в начале статьи, что кодирование есть преобразование данных, что лучший архиватор, архиватор осуществляющий тождественное отображение.

Цитата:
При сжатии очередного элемента данных эта модель выдаёт своё предсказание или вероятность

Вероятность чего? --- спросит неподготовленный читатель.


Цитата:
Не сжимаются почти все уже сжатые данные, например, архивы (ZIP, CAB), сжатые документы (PDF), сжатая графика и видео (JPG, GIF, AVI, MPG),

Почему? Тот же Zip поджимает заголовок RAR'а, jpg неплохо сжимаются Stuffit 9, ну а PDF вообще отлично жмется тем же LZMA или ALZ, если не сжат изначально. Впрочем, дальше вы поясняете о чем речь, но все же лучше смягчить, потому как вообще говоря непонято, почему выполнением еще одного преобразования не преобразовать полученные данные таким образом, что они не сожмутся еще. Именно поэтому хорошо бы вставить строчку почему невозможен вечный архиватор.


Цитата:
Например, существует более десятка программ-архиваторов, которые могут создавать архивы в формате ZIP. В свою очередь, данные в формате ZIP могут быть сжаты различными методами: Deflate, Deflate64, BZip2.

Еще JAR можно упомянуть.


Цитата:
Других архиваторов и архивов лично я не встречал.

Под виндосом. Но попадаются bz2 и jar (просто можно было бы кстати упомянуть, зачем нужна поддержка этих вещей)


Цитата:
Например, при проведении тестирования была найдена ошибка в архиваторе WinRK (PWCM)

Кстати, PWCM это какое-нибудь контекстное моделирование с частичным взвешиванием? Что-то не нашел на сайте Тейлора расшифровку...


Цитата:
данных архиватор 7-zip (LZMA) покажет худшие результаты, чем RAR, который имеет специальные методы для таких типов данных.

Не совсем корректно, на мой взгляд сравнивать 7-Zip с выбранным LZMA, когда известно, что RAR автоматом выберет PPM. Поэтому хорошо было бы упомянуть, что в 7-zip нужно просто самостоятельно заботиться о выборе порядка модели и используемой памяти, тогда как WinRAR все сделает сам.


Цитата:
Такой малоизвестный архиватор DGCA

Здорово. Спасибо. Не знал об этой живности.


Цитата:
Так как не все протестированные архиваторы поддерживают возможность сжатия папок, для них набор данных предварительно преобразовывался в архив ZIP с нулевой степенью сжатия.

Имеется в виду рекурсивный проход?


Цитата:
Если же использовать архив ZIP с нулевой степенью сжатия, тогда на тестовых наборах exe и med степень сжатия получалась значительно хуже. Это объясняется тем, что архиватор Slim использует специальные методы для некоторых форматов файлов. Архив ZIP хоть и содержит несжатые файлы, для Slim представляется только как архив ZIP. Таким образом, для архиватора Slim тестовый набор txt и bak предварительно преобразовывался в архив ZIP с нулевой степенью сжатия.

Не понял? Возникает вопрос: зачем он преобразовывался в несжатый zip, если вы сами говорите, что в этом нет смысла?
Кстати, почему на IBM'овский tape archiver?


Цитата:
Не поддерживается непрерывный режим. Архиватор не эффективен при сжатии большого числа маленьких файлов

Про Zip хорошо бы сказать, что у Deflate размер словаря фиксирован 32 килобайтами и умпомянуть по этому поводу Deflate64.


Цитата:
Однако при максимальном сжатии может использоваться и используется симметричный метод для сжатия текста (PPM).

Это точно? То есть он выберет PPM даже если будет сжимать бинарные файлы?

При разговоре о проепроцессинге можно вспомнить о том, что внесение избыточности иногда позволяет достичь лучшего сжатия (могу врать конечно, наверное это можно доказать...).

Резюмируя: оч хорошо. Понравилось. Спасибо.
Автор: Viewgg
Дата сообщения: 15.05.2005 21:46
enotus1
Отличная работа! Внушает уважение. Подборка архиваторов отличная, результаты очень жизненная. Правлю шапку.
Что касается времени, то конкретика смысла не имеет, а вот подробности по сжатию написать неплохо бы... Впрочем, это не главное, в целом - 5 баллов.

Добавлено:
TCPIP

Цитата:
Кстати, PWCM это какое-нибудь контекстное моделирование с частичным взвешиванием? Что-то не нашел на сайте Тейлора расшифровку...

Точную расшифровку не знаю, а вообще - контекстное моделирование, основанное на алгоритме PAQ (это точно где-то читал) -> см. сайт PAQ
Автор: TCPIP
Дата сообщения: 15.05.2005 23:36
Viewgg
22:46 15-05-2005
Цитата:
сайт PAQ

Это махониевский что-ли. Так там нет этого, если я не проглядел.
Автор: Viewgg
Дата сообщения: 16.05.2005 17:31
TCPIP
Можно у самого Малькольма на msoftware.co.nz спросить. Это выход, только, кажется, нужна регистрация.
Внимательно прочёл статью (опять), действительно, ситуация со Slim неочевидная. Кстати, читать размер файлов не в байтах, а в Мб - очень удобно! Также неясно, почему в 7-zip "игнорировали" PPMD. Но всё равно хорошо.
Автор: enotus1
Дата сообщения: 23.05.2005 05:57

Цитата:
Самое общее замечание - не хватает конкретики. Размера архивов в байтах и времени работы в секундах. Хотя бы в примечаниях для особо интересующихся

Да, точных данных нет. Однако без доступности исходных файлов ценность конкретики нулевая. Согласны?

Добавлено:

Цитата:
Цитата:
Чем больше порядок модели, тем выше степень сжатия

Насколько я понимаю, вообще говоря. То есть может быть и наоборот.

Хм. Действительно.... может и упостил....может посчитал мелочью...

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

Ух-ты. Например?

Хехе достаточно распространено, чисто по памяти WinIMP... боюсь соврать... нужно уточнять?


Цитата:
Хорошо бы пояснить в начале статьи, что кодирование есть преобразование данных,

В конетесте статьи это не является принципиальным.


Цитата:
учший архиватор, архиватор осуществляющий тождественное отображение.

Не обязательно.


Цитата:
Цитата:
При сжатии очередного элемента данных эта модель выдаёт своё предсказание или вероятность

Вероятность чего? --- спросит неподготовленный читатель.




Цитата:
Цитата:
Не сжимаются почти все уже сжатые данные, например, архивы (ZIP, CAB), сжатые документы (PDF), сжатая графика и видео (JPG, GIF, AVI, MPG),

Почему? Тот же Zip поджимает заголовок RAR'а,

Про хаголовки написано.


Цитата:
jpg неплохо сжимаются Stuffit 9

Про это читай маленькую статью http://enotus.at.tut.by/Articles/JPGCompression/index.html


Цитата:
PDF вообще отлично жмется тем же LZMA или ALZ, если не сжат изначально.

Про это упоминается далее: "Кстати, многие файлы могут содержать как сжимаемую информацию, так и не сжимаемую. В том числе файлы в формате DOC и PDF." Вполне достаточно.


Цитата:
Именно поэтому хорошо бы вставить строчку почему невозможен вечный архиватор.

Согласен.


Цитата:
Цитата:
Например, существует более десятка программ-архиваторов, которые могут создавать архивы в формате ZIP. В свою очередь, данные в формате ZIP могут быть сжаты различными методами: Deflate, Deflate64, BZip2.

Еще JAR можно упомянуть.

В данном контексте это не нужно.


Цитата:
Цитата:
Других архиваторов и архивов лично я не встречал.

Под виндосом. Но попадаются bz2 и jar (просто можно было бы кстати упомянуть, зачем нужна поддержка этих вещей)

Лично не встречал (не припомнил во время написания опуса).


Цитата:
Цитата:
Например, при проведении тестирования была найдена ошибка в архиваторе WinRK (PWCM)

Кстати, PWCM это какое-нибудь контекстное моделирование с частичным взвешиванием? Что-то не нашел на сайте Тейлора расшифровку...

Эта ... Partialy weghted context modelling ... что-то такое...


Цитата:
Цитата:
данных архиватор 7-zip (LZMA) покажет худшие результаты, чем RAR, который имеет специальные методы для таких типов данных.

Не совсем корректно, на мой взгляд сравнивать 7-Zip с выбранным LZMA, когда известно, что RAR автоматом выберет PPM. Поэтому хорошо было бы упомянуть, что в 7-zip нужно просто самостоятельно заботиться о выборе порядка модели и используемой памяти, тогда как WinRAR все сделает сам.

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


Цитата:
Цитата:
Так как не все протестированные архиваторы поддерживают возможность сжатия папок, для них набор данных предварительно преобразовывался в архив ZIP с нулевой степенью сжатия.

Имеется в виду рекурсивный проход?

Есть там нюансы, не обязательно рекурсивный...


Цитата:

Цитата:
Если же использовать архив ZIP с нулевой степенью сжатия, тогда на тестовых наборах exe и med степень сжатия получалась значительно хуже. Это объясняется тем, что архиватор Slim использует специальные методы для некоторых форматов файлов. Архив ZIP хоть и содержит несжатые файлы, для Slim представляется только как архив ZIP. Таким образом, для архиватора Slim тестовый набор txt и bak предварительно преобразовывался в архив ZIP с нулевой степенью сжатия.

Не понял? Возникает вопрос: зачем он преобразовывался в несжатый zip, если вы сами говорите, что в этом нет смысла?

Потому что в среднем получилось значительно хуже с ZIP.


Цитата:
Цитата:
Не поддерживается непрерывный режим. Архиватор не эффективен при сжатии большого числа маленьких файлов

Про Zip хорошо бы сказать, что у Deflate размер словаря фиксирован 32 килобайтами и умпомянуть по этому поводу Deflate64.

... было определение "АРХИВАТОРА", ну а deflate я выбрал по указанным соображениям..


Цитата:

Цитата:
Однако при максимальном сжатии может использоваться и используется симметричный метод для сжатия текста (PPM).

Это точно? То есть он выберет PPM даже если будет сжимать бинарные файлы?

Не это для текста или чегото похожего. Кстати на maximumcoimpression использукется вроде только RAR c PPM.


Цитата:
При разговоре о проепроцессинге можно вспомнить о том, что внесение избыточности иногда позволяет достичь лучшего сжатия (могу врать конечно, наверное это можно доказать...).

Это совершенно не принципиально. Если для удобного предстваления необходимо добавить лищнего - не вопрос.


Цитата:
Резюмируя: оч хорошо. Понравилось. Спасибо.

Кстати, посмотри что пишут про "плохие" статьи.... "ркщпектов" достаточно....

Добавлено:

Цитата:
а вот подробности по сжатию написать неплохо бы...

2 раза переписывал. Остановился на очень кратком описании. Для подробного имеется ссыцлка..


Цитата:
Также неясно, почему в 7-zip "игнорировали" PPMD.

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


Автор: F0rward
Дата сообщения: 26.12.2005 00:16
а кто что скажет о winrk 3.0.2 beta? Тестирую сейчас режим best assymetric - дал заметную разницу по сравнению с 7zip допустим архив дистрибутива nero ~28 с 7zip и ~25 с RK при этом скорость распаковки вполне терпимая
Автор: arsvrn
Дата сообщения: 26.12.2005 08:29
F0rward

Цитата:
а кто что скажет о winrk 3.0.2 beta?

Пока ничего не скажу. Надо попробовать.
Автор: vito333
Дата сообщения: 11.01.2006 17:30
а я попробовал slim - очень понравился скоростью и степенью сжатия. Плохо, что не приделаешь нормальный SFX. А так бы его активно использовал.
Надо наверное черкнуть автору, чтобы распаковку отдельно файлом небольшим оформил, а SFX сами приделаем.
Автор: arsvrn
Дата сообщения: 11.01.2006 20:44
vito333

Цитата:
я попробовал slim - очень понравился скоростью и степенью сжатия

Степень сжатия у него одна из лучших, если не лучшая (правда, быстрым я бы его не назвал). Сравнительные результаты по тестированию были раньше в этом топике. А вот автору писать по-моему бесполезно, уж очень давно Slim не обновлялся. Наверное, брошен
Автор: vito333
Дата сообщения: 12.01.2006 02:40
arsvrn
а, точно, посмотрел - староват.
Надо тогда на дурилку ориентироваться
Автор: Viewgg
Дата сообщения: 12.01.2006 09:10
vito333

Цитата:
Надо тогда на дурилку ориентироваться

Если интересует сжатие по методу ppmd, то да, а так можно и на paqar4 или наш любимый WinUDA.


Кто знает рабочую ссылку на от enotus? Киньте, пожалуйста, сюда или добавьте в шапку!
Автор: Yarylo
Дата сообщения: 17.01.2006 15:09
Panzer

Цитата:
Расскажи пожалуйста в теме про архиваторы что и как ты сжимал.

Я сжимал словари для подбора паролей: 5 словарей - 10 806 384 байт с сумме.
7zip 4.32: PPMd 32mb Solid - 1 752 756 байт
Uharc 0.6: PPM 32mb - 1 282 449 байт

Цитата:
иногда в 1,5-2раза
- да, действительно я перехвалил Uharc
Автор: Panzer
Дата сообщения: 17.01.2006 15:29
Yarylo

Цитата:
Я сжимал словари для подбора паролей: 5 словарей - 10 806 384 байт с сумме.
7zip 4.32: PPMd 32mb Solid - 1 752 756 байт

А если взять побольше памяти для 7zip? можешь ты выложить в Инет какой-нибудь из этих файлов?
Автор: Yarylo
Дата сообщения: 17.01.2006 16:04
Panzer
выложил
Автор: vito333
Дата сообщения: 18.01.2006 04:32
ещё такой момент - по-моему для ppmd в 7zip не дашь сколько угодно памяти, ощущение такое, что только определённые установки, иначе метод тихо меняется на не-ppmd(и соответственно вы тихо получаете другой уровень компрессии текста, не самый оптимальный). По крайней мере я сделал у себя на компе такой вывод.
Автор: Yarylo
Дата сообщения: 18.01.2006 08:19
vito333
Да, у меня то-же самое. Если обьем словаря больше 32мб - компресия происходит не по методу PPMd. Это видно и по времени сжатия и по обьему конечного архива.
Автор: vito333
Дата сообщения: 18.01.2006 16:57
а потом люди клянутся, что 7zip жмёт слабо
Автор: arsvrn
Дата сообщения: 18.01.2006 18:23
А ставить объем словаря больше, чем суммарный объем архивируемых данных, не имеет никакого смысла. Все равно лучше не будет
Автор: TCPIP
Дата сообщения: 18.01.2006 19:35
arsvrn
19:23 18-01-2006
Цитата:
А ставить объем словаря больше, чем суммарный объем архивируемых данных, не имеет никакого смысла. Все равно лучше не будет

Так он автоматом должен понижать размер словаря (как это делает WinRAR). Не вручную же каждый раз выбирать подходящий размер!
Кстати, тупо проверить, перескакивает ли он на другой метод, по-моему достаточно просто: создать PPM-архив с тем самым предполагаемым перескоком и сравнить его LZMA-архивом. Преобразование-то взаимнооднозначное, каждый раз должно одно и то же получаться.
Автор: Enotus
Дата сообщения: 18.01.2006 20:15
Viewgg

Цитата:
Кто знает рабочую ссылку на от enotus? Киньте, пожалуйста, сюда или добавьте в шапку!

Ссылка рабочая, возможно были временные проблемы у бесплатного хостера.
Автор: Panzer
Дата сообщения: 19.01.2006 16:38
Yarylo

Цитата:
Я сжимал словари для подбора паролей: 5 словарей - 10 806 384 байт с сумме.
7zip 4.32: PPMd 32mb Solid - 1 752 756 байт
Uharc 0.6: PPM 32mb - 1 282 449 байт


Да действительно, на таком "вырожденном" тексте (по одному слову в строке, нет повторяющихся слов) 7zip значительно проигрывает Uharc. Я получил те же цифры, что у тебя, но для 7zip по методу LZMA. Для PPMd результат еще хуже.
Для "нормальных" текстов ситауция другая - у меня как правило на английских текстах результаты очень близкие, чаще впереди Uharc, а на русских текстах лучше 7zip, иногда существенно.

Цитата:
Если обьем словаря больше 32мб - компресия происходит не по методу PPMd.

Звучит странно. Возможно, в gui 7zip есть какая-то опция, к-рая отвечает за такое переключение. Я пользуюсь консольным 7za.exe , и с ним в этом смысле все в порядке - какой метод укажешь, таким и сжимает.

Страницы: 12345678910111213141516171819202122232425262728293031

Предыдущая тема: canopus pro coder


Форум Ru-Board.club — поднят 15-09-2016 числа. Цель - сохранить наследие старого Ru-Board, истории становления российского интернета. Сделано для людей.