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

Добавил тест упаковки log файла logos.log 100Мб
http://forum.ru-board.com/topic.cgi?forum=5&topic=8076&start=459&limit=1&m=1#1

Panzer
15:58 11-02-2006
Цитата:

Либо глюк WinUHA, либо глюк системы

Нет, ну теоретически можно дополнительные преобразования использовать, если CPU поддерживает какие-то расширенные команды. Только вот, чтобы P4 не поддерживал то, что поддерживает AthlonXP?

TCPIP

Цитата:

Только вот, чтобы P4 не поддерживал то, что поддерживает AthlonXP?

Ну, например, 3DNow!
А вообще-то, по-моему, не может быть, чтобы архиватор паковал по разному в зависимости от типа процессора. Обычно (если прога вообще это умеет) определяется проц и просто выполнение идет по разным подпрограммам. При этом, естественно, алгоритм один и тот же (скорость может сильно отличаться). Вот от объема памяти зависимость может быть. Если мало - может быть автоматически сокращен словарь и т.д.
egor23
Кстати, компы у нас очень похожи
твой: Sempron64 2500+ (2.1Ггц), 512Мб опер.памяти PC3200(468МГц)
мой: Sempron64 3000+ (2Ггц, stepping E6), 512Мб опер.памяти PC3200.
А результаты сильно разные

arsvrn
09:54 12-02-2006
Цитата:

При этом, естественно, алгоритм один и тот же

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

Цитата:

Ну, например, 3DNow!

А разве там есть какие-то команды, которые могут пригодиться для сжатия?

Цитата:

Если мало - может быть автоматически сокращен словарь и т.д.

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

На сайте http://www.maximumcompression.com недавно наконец-то добавили новый WinRK. Угадайте, на каких он местах. Но суть не в этом. Малькольм Тейлор сильно хвалил свой новый ассиметричный алгоритм ROLZ2, так вот я предлагаю выяснить, какой ассиметричный архиватор теперь лучший. Претендентов, на мой взгляд, 2: WinRK и 7-zip. Имеет смысл тестировать на EXE, DLL, DOC и прочих подобных форматах, так как на мультимедиа 7-zip слаб, а у WinRK кодеки всякие, для текстов же есть PPM. И ещё: почему вы игнорируете WinRK вообще? Если уж тестировать PAQ, так и PWCM туда же, неплохо бы и семейство FPW (от 1 до 4, правда, на их форуме были жалобы на глючность FPW3). PPMZ/D показали себя не с лучшей стороны, о чём свидетельстуют тесты egor23, Малькольм их и выкинул, а вот PWCM/FPW вроде ничего, как они пишут... Ещё бы интересно сравнить сей продукт на мультимедиа с UHARC и Slim, на графике ещё и с WinACE (см. тесты от arsvrn)
И ещё. Там на 1-2-3 строчках фигурирует PasQda, какой-то очередной продукт. На DOC-файлах он там вообще лидер! Что можете сказать про это изобретение?
Насчёт сжатия текста пришла ещё одна идейка. Нельзя ли попробовать выжать ещё из Slim, сделав tar и включив принудительно при сжатии "тестовые трюки"?


Добавлено:
arsvrn

Цитата:

WinRK 3.02 (PWCM): 890321. Причем на Athlon64 3200+ (разогнанном до 4000+) время более 2-х часов. Повторить результат egor23 (WinRK 3.0build2beta (FPW1, model size 128Мб, 128, 64, 20, и три галки) 874кб) не удалось. Я пока с WinRK плохо знаком (да и желания то нет знакомиться ). Пытался поставить точно такой же режим, но FPW1 никак не ставится, только FPW3 и выбор заблокирован.

Это можно обсудить в теме WinRK, если создать её. Кажется, знаю, в чём дело.

arsvrn
Panzer
Чтоб проверить одинаковость сжатия лучше использовать одинаковые данные, а то tar походу разные получаются. Вот еще один подопытный logos.log 100Мб посмотрите есть отлличия?, также интересуюсь для него DURILCA(DURILCA.exe e -m256 -o64) - через 5мин вылетает в аут с ошибкой - это у меня токо так или ещё у кого?
http://rapidshare.de/files/13132799/logos384_32.7z.html

Viewgg
PAQ был добавлен, тк я его не знал, теперь знаю - тормазнутый, для большого объёма данных не стоит использовать, тк долго.
ROLZ2 будет добавлен, а вот PWCM нет, тк жутко тормазнутый, плюс у меня глючит вылетает минут через 10 с ошибкой.
А вот интересно на http://uclc.info/ в тестах идет WinRK (PPMD,PPMZ) 3.0 build 2 beta, выходит, что выбор PPMD,PPMZ убраны токо в оболочке, а физически имеются?

TCPIP

Цитата:

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

Попробую. Если ты имеешь в виду методы из области объектно-ориентированного программирования, то это то же, что и подпрограммы, то есть выполняется некая последовательность инструкций (да простят меня программеры ).
На процессорах с разными наборами команд одни и те же методы (подпрограммы и т.д.) могут выполняться по разному. Например, на некотором процессоре умножение вещественных чисел может выолняться одной машинной командой, но это не значит, что на 8-ми битном микропроцессоре нельзя сделать то же самое, пусть и за много машинных команд. Трансляторы языков высокого уровня сами компилируют любой оператор языка в набор команд соответствующего процессора. На ассемблере автор сам должен позаботится об этом. Лично я ни разу не встречал, чтобы программа давала разные результаты в зависимости от класса процессора, не считая случаев, когда это делается специально, например, в Winamp'e можно (было) выбрать режим ухудшенного декодирования для повышения скорости. Достаточно часто попадаются опции типа "не использовать MMX, SSE и т.д". Но при этом не получается ДРУГОЙ результат - просто скорость падает.

Цитата:

А разве там есть какие-то команды, которые могут пригодиться для сжатия?

Не знаю. А в MMX, SSE...SSE3 есть? Тем более, что AMD сейчас тоже все это поддерживает.

Viewgg

Цитата:

Это можно обсудить в теме WinRK, если создать её. Кажется, знаю, в чём дело.

В варезнике есть. В программах можно и создать.

arsvrn
23:57 12-02-2006
Цитата:

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

Да. Переспросил, чтобы быть уверенным, что мы говорим об одних и тех же вещах.

Цитата:

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

Вот, ключевое слово --- много комманд. Много циклов и прочее. Может, где-то неэффективно включать какой-нибудь BWT и этот метод не обрабатывается программой. Но это так, пустые догадки.

Цитата:

А в MMX, SSE...SSE3 есть?

Я и сам не знаю, но 7-Zip их вроде использует, MPEG-декодер из использует, стало быть, есть.

Вот ёлы-палы в WinRK 3.0 build 2 beta имется PPMD,PPMZ не доглядел, да вроде и пакует по-лучше и быстрее, придётся по новой делать тест.

egor23

Цитата:

WinRK (PPMD,PPMZ) 3.0 build 2 beta, выходит, что выбор PPMD,PPMZ убраны токо в оболочке, а физически имеются?

Вместе с выходом 3 версии появился новый формат, в котором этих методов нет, а есть в формате WinRK 2-x Archive. Их Малькольм вроде не менял, поменялся только PWCM и компания в связи с выходом новой версии PAQ. На арене суперсжатия Махони разрабатывает, Малькольм слизывает и доводит, так получаются лидеры. Насчёт тормознутости полностью согласен, понимаю и одобряю.

Цитата:

в WinRK 3.0 build 2 beta имется PPMD,PPMZ не доглядел, да вроде и пакует по-лучше и быстрее, придётся по новой делать тест.

Зачем новый тест? Алгоритмы-то вроде старые... Малькольм их даже из библиотеки выкинул: http://www.msoftware.co.nz/products_mcomp.php
Результат с сайта парадоксален, у Малькольма спросить, что ли... А с тестами этих алгоритмов пока лучше подождать, они не самые интересные, на мой взгляд.

Добавил WinRK 3.0 build 2 beta (ROLZ2, PPMd, PPMz); wildsoft 1.84Гб
http://forum.ru-board.com/topic.cgi?forum=5&topic=8076&start=459&limit=1&m=1#1
Комметарий:
1. text dictionary - по ходу с русским языком не сильно дружит.
2. Пародокс с Fast Analysis - получается что при быстром анализе файлов лучше пакуется, чем при подробном.
for PPMd,PPMz
1. Нет возможности менять PPM model order.
2. Largest optimised match (0..512) ни как не влияет на степень сжатия да и на время упаковки.


Добавлено:
Viewgg

Цитата:

Там на 1-2-3 строчках фигурирует PasQda, какой-то очередной продукт

На фоне этого продукта WinRK (PWCM), в общем случае, детская шалость, обратите внимание на затраченное время.
http://www.maximumcompression.com/data/summary_mf.php

Добавлено:
PAQ8C сегодня на тексте попробую
всё до мультимедиа ни как не доберусь

egor23

Цитата:

PAQ8C сегодня на тексте попробую

Архиватор мне очень понравился, но явно находится в процессе доводки. Новая подверсия появляется каждую неделю. Надо чуть-чуть подождать, пока устаканится.
Viewgg

Цитата:

И ещё: почему вы игнорируете WinRK вообще?

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

PAQ8C попробывал история таже что и с WinRK нужен хороший руский словарь.

Добавил PPMVC v1.0 (Jul 27 2003) - Fast PPMII+VC compressor;
doc файл(MSWord2003) document.doc 60,8Мб Энциклопедический словарь Ф.А.Брокгауз,И.А.Ефрон
http://forum.ru-board.com/topic.cgi?forum=5&topic=8076&start=459&limit=1&m=1#1

Добавлено:
да о tar, 7z делает tar которые отличаются от сделанных в TC и пакуются по лучше

egor23
Просьба - сделай в результатах теста для каждого объекта сводку только лучших результатов для каждого архиватора, отсортированную по размеру архивов.

egor23

Цитата:

На фоне этого продукта WinRK (PWCM), в общем случае, детская шалость, обратите внимание на затраченное время.

Надо отдать должное Малькольму, на форуме он писал, что старается для PWCM улучшить время, не теряя сжатия. Это у него получается. Вывод: из "тракторных" алгоритмов, судя по данным этих тестов, PWCM лучший, потому я и спросил, почему тестируем PAQ, но не тестируем PWCM. Остаётся надежда на FPW1, может быть, он будет развиваться. Кстати, как он, по Вашим впечатлениям?
Большое спасибо за хорошие, серьёзные тесты!

Добавлено:
Итак, на этих данных WinRK 3 действительно лучший ассиметричный архиватор, остались только EXE/DLL и мультимедиа. Не думаю, что имеет смысл тестить PPM-архиваторы (кроме Slim и UHARC, у которых есть кодеры) и 7-zip на мультимедиа , а вот WinRAR/ACE/RK стоит.

Добавлено:
Да, совсем забыл насчёт оформления. Лидера в каждом тесте лучше, на мой взгляд, выделять просто цветом/подчёркиванием, а потом кратенько подвести итог. И ещё: неплохо бы добавить полученные ранее результаты для FPW1 (кстати, Малькольм пишет, что из всего семейства FPW этот лидер по сжатию.)

Ну вот добрался до мультимедиа:
Добавлено:
ресурсный файл RES.RDT 115Мб (120 630 264) из игры Shipwreckers!
ресурсные файлы HL2:
source engine.gcf 137,4Мб (144 123 964)
source models.gcf 449,2Мб (471 109 428)
source materials.gcf 1,01Гб (1 091 374 272)
half-life 2 content.gcf 841,3Мб (882 236 412)
source sounds.gcf 975,5Мб (1 022 943 264)
half-life 2_russian.gcf 784,5Мб (822 616 016)

7-zip показывает нормальные результаты, токо вот *.wav плохо переваривает, это есть большой минус

CD-audio (wav 501Мб), wav файл 56,4Мб
for *.wav: Monkey's Audio 4.01 beta 1, WAVPACK 4.31
http://forum.ru-board.com/topic.cgi?forum=5&topic=8076&start=459&limit=1&m=1#1

Panzer
Красоту позже наведу.

egor23
Многие результаты вполне предсказуемы. На аудио повторяется результат arsvrn, среди неспецифических архиваторов Slim опять лучший, в остальном рулят LZ-алгоритмы, причём часто с кодерами для мультимедиа. UHARC, WinRAR и WinRK на высоте, причём WinRAR всех быстрее. Спасибо!

Добавлено:
for *.wav:
Lossless Audio Compressor Version 0.4b
OptimFROG Lossless Audio Compressor (Win32), v4.510 [2005.07.17]
FLAC - Command-line FLAC encoder/decoder version 1.1.2
http://forum.ru-board.com/topic.cgi?forum=5&topic=8076&start=459&limit=1&m=1#1

Lossless Audio, OptimFROG, FLAC - теряют тэги.

egor23
06:03 18-02-2006
Цитата:

Lossless Audio, OptimFROG, FLAC - теряют тэги.

Как теряют? Есть у них теги, правда у каждого своя реализация. А вообще, это уже лучше сюда.
Исследование LA имеет лишь теоретический смысл. На практике он используется очень редко, ввиду отсутствия большинства стандартных функций, таких как поддержка многоканальности, высокого разрешения, replaygain, коррекции ошибок. Кроме того, наперед можно сказать, что на 16-битном стерео LA почти всегда будет первым по коэффициенту сжатия и последним по скорости сжатия. OptimFrog развивается о-о-о-очень вяло. По сути, едва начав набирать хоть какую-то известность, кодек прекратил свое интенсивное развитие и сейчас почти не используется. По сути используются лишь FLAC (как стандарт), APE (когда нужно хорошее сжатие по приемлемым временным затратам и с поддержкой высокого разрешения; иногда он ошибочно используется и на многоканальном аудио, хотя не поддерживает его) и, гораздо реже WavPack, хотя на мой взгляд, если уж и использовать, то WavPack, у которого есть все, что есть у FLAC, плюс гибридность.
Исследование аудио это интересно, но нужно знать параметры сигналов. Хотя бы жанр музыки, если уж не уходить в исследования нелинейности и нестационарности.

---

Поясните пожалуйста, какой смысл в поиске оптимального порядка модели PPM? Каков критерий оптимальности? По мне так, он всегда будет разный, вы не с можете найти оптимальный без предварительного анализа текста. Кроме того, насколько я понимаю, каждый архиватор ведет моделирование по-своему (например WinRAR и 7-Zip). Я не прав?

TCPIP
1. lossless audio codec's расматриваются в качестве упаковщиков для хранения "специфических" данных.

Цитата:

Как теряют?

2. Т.е. упаковали - распаковали: тэгов нет в wav файле, может еще какие параметры нужно было указать незнаю.
Стиль музуки - группа указана, если верить freedb, то это Rock.
3. Другие нюансы с audio данными не рассматривались, т.к. не сталкивался с ними.

Цитата:

Поясните пожалуйста, какой смысл в поиске оптимального порядка модели PPM?

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

Цитата:

каждый архиватор ведет моделирование по-своему

разные алгоритмы (варианты алгоритма) - разное моделирование

egor23
08:46 18-02-2006
Цитата:

1. lossless audio codec's расматриваются в качестве упаковщиков для хранения "специфических" данных.

Цитата:

тэгов нет в wav файле, может еще какие параметры нужно было указать незнаю.

Вот именно, в WAV файле --- в нем нет контейнера для тегов (хотя есть нестандартный WAV c APE2 контейнером). Нужно упаковывать в обход WAV с помощью программ транскодирования. Вроде бы, dBPowerAMP это умеет или какой-нибудь GX::Transcoder. Вообще их куча, а какой удобнее шут знает.

Цитата:

Стиль музуки - группа указана, если верить freedb, то это Rock.

Так вот и я об этом. Одна группа, один стиль сравнивается сама с собой. Конечно, предложенный мною вариант сортировки по стилю смешон (стиль-стилем, а сигнал-сигналом...), но можно хоть как-то хоть какие-то, возможно, выводы сделать, сравнив Trash Metall, Нard Rock и, например, Symphonic Rock.

Цитата:

разные алгоритмы (варианты алгоритма) - разное моделирование

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

TCPIP

Цитата:

Вот именно, в WAV файле --- в нем нет контейнера для тегов (хотя есть нестандартный WAV c APE2 контейнером)

Так дело втом что кусок с тэгами не обрезают Monkey's Audio и WAVPACK.

Цитата:

Так вот и я об этом. Одна группа, один стиль

У меня не так много CD-audio но думаю добавлю другие стили.

Цитата:

То есть вы хотите для каждого из них подобрать оптимальные настройки

В данном случае практика (за незнанием теории) показала, что оптимум получить можно токо практическим метотом: упаковал - посмотрел что получилось.

Да вот, о косяках, провести подробно изыскания опять не хватило времени, ну что есть:
logos.log 100,1Мб (105 054 208)
logos.rar - 4 152 903 Winrar(макс, solid, 4Мбсловарь) (AthlonXP 2500+ Barton@3200+)
logos.rar - 4 152 916 Winrar(макс, solid, 4Мбсловарь) (Sempron64 2500+ 2.1ГГц)
logos.7z - 2 385 411 7z(макс,PPMd,384Мбсловарь,32слово) (AthlonXP 2500+ Barton@3200+)
logos.7z - 2 385 411 7z(макс,PPMd,384Мбсловарь,32слово) (Sempron64 2500+ 2.1ГГц)
logos.uha - 3 071 481 WinUHA(PPM,32Мбсловарь,мультимедия отключена) (AthlonXP 2500+ Barton@3200+)
logos.uha - 3 071 481 WinUHA(PPM,32Мбсловарь,мультимедия отключена) (Sempron64 2500+ 2.1ГГц)

egor23

Цитата:

logos.rar - 4 152 903 Winrar(макс, solid, 4Мбсловарь) (AthlonXP 2500+ Barton@3200+)
logos.rar - 4 152 916 Winrar(макс, solid, 4Мбсловарь) (Sempron64 2500+ 2.1ГГц)

Я думаю, лучше в теме по winrar поднять этот вопрос.

egor23
Кстати, а что дает сравнение? Что представляют из себя эти 13 байт разницы? Я к тому, что, может, это какой-нибудь заголовок.

Добавлено:
три wav, CD-audio
HL2: counter-strike source shared.gcf 1,54Гб
В связи с практической целесообразности будут добавлены и другие крупные ресурсы из HL2

Panzer
Т.к. не хватило времени утверждать ничего не буду, но думаю не в Winrar'е дело, притом до этого в UhaRC (ALZ-3) различия были. В 7z и WinUHA использовался PPM-метод. Не ужели ни у кого нет машины на AthlonXP? для проверки подопный ввиде logos.log имеется. Ну и на машине класа A64 заодно проверить.

TCPIP
Отличия во всём файле.

egor23
01:35 23-02-2006
Цитата:

Отличия во всём файле.

Ясно. Тогда интересно провести анализ блоков --- так происходит на всех блоках или на каких-то определенных? Жаль, не знаю, как это проверить...

http://www.ixbt.com/soft/archivers.shtml . Не успел толком посмотреть, глянул только в конец. winzip 2-й в "рейтинге полезности". ню-ню.

Panzer

Цитата:

Не успел толком посмотреть, глянул только в конец. winzip 2-й в "рейтинге полезности". ню-ню.

Так 1, 2 и т.д. - не места, занятые архиваторами, а нумерация пунктов в разделе "Подведем итоги."