Архиваторы. Сравнение сжатия - [21] :: Программы

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 даже если будет сжимать бинарные файлы?

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

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

Цитата:

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

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

Добавлено:

Цитата:

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

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

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

Цитата:

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

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

Хехе достаточно распространено, чисто по памяти 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 (правда с оговорками).

Модерирует : gyra, Maz
Версия для печати • Подписаться • Добавить в закладки
Страницы: 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 48 49 50 51 52 53 54 55 56