Полное или частичное копирование текста допускается только с письменного разрешения автора.
1. Вступление
Идея о создании этого теста родилась у меня, когда я обнаружил, что существующие на тот момент аналогичные сравнения сильно устарели (последний тест датирован 2007 годом). Большинство из них проводилось на старых слабых процессорах, с использованием давно забытых версий кодеров.
Идея же моего теста заключается в том чтобы показать возможности последних версий кодировщиков на современном оборудовании. Значительный прирост скорости кодирования/декодирования в этом случае можно получить за счет использования таких наборов инструкций, как SSE2, SSE3, SSSE3, которые поддерживаются современными процессорами, и конечно же - за счет многоядерности (хотя фактически использование более одного логического процессора поддерживается сейчас только кодером TAK).
Стоит заметить, что в тесте рассматривается лишь три параметра: скорость кодирования, скорость декодирования и степень сжатия. Я умышленно не беру во внимание проблемы совместимости, так как это значительно затрудняет возможность сделать какое-либо конкретное заключение.
2. Подготовка к тесту
2.1 Оборудование
Использован ПК средней ценовой категории на современном чипсете с двухъядерным процессором Intel (32 нм). Конфигурация компьютера:
Все технологии энергосбережения и HyperThreading отключены в BIOS материнской платы. Перед тестом была произведена полная дефрагментация всех трех используемых разделов. Первый жесткий диск использовался для хранения ПО (foobar2000, кодировщики), второй - для хранения несжатого источника, третий - для записи выходных файлов.
2.2 Программное обеспечение
К сожалению, пока что тест проводится на 32-разрядной ОС. Возможно, в будущем будут опубликованы результаты и для 64-bit. Для теста была специально произведена установка портативного foobar2000 последней версии с необходимым плагинами и кодировщиками. После чего предварительно были созданы профили конвертера для каждого кодера.
Для процесса плеера (а также для конвертера в его настройках) был установлен приоритет реального времени.
2.3 Музыкальный материал
Для теста был выбран образ диска одного из современных композиторов электронной музыки. Запись имеет широкий частотный и относительно неплохой динамический диапазоны.
Изначально я планировал провести сравнение при максимальных настройках сжатия для каждого кодера. Но по некоторым причинам это представилось невозможным, да и смысл такого теста был бы весьма сомнителен. Например, чтобы закодировать 30-секундный отрезок стандартного звукового материала в кодеком OptimFROG с максимальными параметрами уходит 230 секунд (скорость кодирования около 0.13х). Таким образом я сформулировал следующие требования:
скорость кодирования не менее 1x
скорость декодирования не менее 2х
возможность использовать для сжатых файлов прокрутку (seeking).
Так как прирост сжатия по мере увеличения параметров уменьшается, степень сжатия с выбранными мною параметрами практически не отличается от максимальной.
Примечание: возможно, в будущем сюда также добавится тестирование на оптимальных параметрах.
Общие параметры конвертера:
Output bit depth:Auto Dither:never Output folder:F:\lossless comparison Fiilename pattern:%filename% Processing:none When finished:Do nothing
Кодеры
Примечание: для кодеров, не имеющих возможности кодировать на лету, входной файл был указан непосредственно в параметрах (вместо переменной %s). Это сделано с той целью, чтобы кодирование происходило непосредственно из файла-источника в конечный, без создания временного (что занимает значительное время и искажает результаты). Ниже параметры для упомянутых кодеров указаны с переменной %s.
Для кодера WMA пришлось производить кодирование через командную строку, так как описанным выше способом кодировать он отказался.
Параметры:-s --ignore-chunk-sizes -8 - -o %d
Установлена максимальная степень сжатия, включен тихий режим и игнорирование размера в заголовке WAV.
Параметры:-q -12 %s -o %d
Установлена максимальная степень сжатия, включен тихий режим.
Включен режим максимального сжатия, игнорирование размера в заголовке. Второй набор парамтеров содержит ключ включающий использование двух ядер процессора.
Параметры:-e %s -o %d
Данный кодер не требует дополнительных параметров кодирования.
Стандартный набор параметров для кодирования в WMA 9.2 lossless (16 бит, 44.1 кГц). Тихий режим.
Параметры:-q -i -hh -x6 - %d
Extra High сжатие, асимметричное кодирование 6й степени, игнорировать размер в заголовке, тихий режим.
3. Методика тестирования
3.1 Кодирование
После подготовки дело остается за малым. Первый этап тестирования выглядит следующим образом:
Закрыть в диспетчере задач все процессы кроме необходимых.
Запустить foobar2000 и установить для процесса foobar2000.exe максимальный приоритет.
Добавить в плейлист файл D:\lossless comparison\Image.wav
Выделив файл в плейлисте, нажать кнопку конвертации, загрузить первый профиль конвертера и запустить процесс кодирования.
По окончании конвертирования записать время и скорость кодирования (в виде N*realtime) из консоли плеера .
Выполнить то же самое с использованием каждого из 9-ти профилей конвертера. Полученные файлы добавить в плейлист.
Записать размер сжатого файла, степень сжатия (в %) и FBR (см. ниже) для каждого кодера.
После выполнения всех пунктов мы получим примерно следующее:
В плейлисте отображается имя файла, кодек, FBR (file-based bit rate=размер файла/продолжительность), степень сжатия в % и размер файла в процентах.
3.2 Верификация
Сжатый файл должен нести все необходимые данные для восстановления исходного потока. Для проверки достоверности я произвел сравнение всех полученных файлов с исходным с помощью плагина Binary Comparator. Для того чтобы провести такое сравнение надо выделить несжатый и тестируемый сжатый файлы в плейлисте, в контекстном меню выбрать Utilities->Bit-Compare Tracks.
Для всех форматов кроме LA результат был положительным (No differences in decoded data found).
В случае с LA плеер закрывался с ошибкой. По этой причине, декодирование файла Image.la пришлось производить с помощью консольного кодера/декодера la.exe и библиотеки la-core.dll (которые использовались для кодирования). Полученный таким образом несжатый поток оказался идентичным исходному. Из этого можно сделать заключение, что декодер LA в foobar2000 работает некорректно, но при кодировании кодер информации не теряет и её можно восстановить.
3.3 Декодирование
Скорость декодирования оценивалась с помощью плагина Decoding Speed test. Декодирование происходило с высоким приоритетом и полной буферизацией файла в ОЗУ, в 5-10 проходов. Окно плагина изображено ниже.
Для каждого кодера записывалось среднее время и скорость декодирования.
Примечание: для формата LA декодирование выполнялось через консоль (см. "Верификация").
4. Результаты
Результаты тестирования оформлены в таблицу и отсортированы по убыванию степени сжатия.
Кодек
Степень сжатия
FBR, кбит/с
Размер файла, МБ
Время сжатия, c
Скорость сжатия
Время декодирования, с
Скорость декодирования
LA
66,55%
939
535,51
573,58
8,34x
517,00
9,25x
OFR
66,74%
941
537.06
1533,58
3,12x
838,54
5,70x
APE
67,23%
948
540,94
318,60
15.01x
331,14
14,44x
TAK
67,80%
956
545,49
139,77
34,22x
16,46
290,60x
TAK
(2 ядра)
67,80%
956
545,49
94,73
50,49x
16,45
290,83x
WV
68,69%
969
552,72
2652,16
1,80x
39,01
122,60x
FLACCL
69,51%
980
559,29
14,43
331,39x
12,75
375,03x
TTA
69,60%
982
560,08
28,74
166,44x
32,24
148,37x
Flake
69,68%
983
560,63
444,15
10,77x
15,74
303,84x
FLAC
70,11%
989
564,12
99,79
47,92x
9,88
483,94x
ALAC
71,00%
1002
571,32
65,88
72,60x
123,17
38,83x
WMA
71,68%
1011
576,78
61,00
78,41x
35,57
134,48x
PCM
100%
1411
804,62
-
-
-
-
5. Заключение
1. Lossless Audio (LA) - этот весьма старый кодек (2004 г.) стал безусловным победителем по сжатию. При этом надо отметить вполне приемлемую (в сравнении с тем же OptimFROG или WavPack) скорость кодирования, а также достаточную скорость декодирования. Хоть файл LA и не декодировался с помощью плагина foo_benchmark, проигрывался он прекрасно, без запинок и задержек при прокрутке.
Остается только удивляться, почему автор забросил такой прекрасный кодек, даже не открыв при этом исходный код.
2. OptimFROG - не слишком отстает от LA. Но по скорости его едва ли можно назвать быстрым. Кроме того, неприятным моментом является высокая задержка при прокрутке файла - порой это сильно напрягает.
3. Monkey's Audio - популярный, но ресурсоёмкий кодек. Дает действительно высокое сжатие, но опять же имеет проблемы с прокруткой.
4. TAK - этот активно разрабатываемый кодек не перестает радовать. Если брать во внимание все три параметра (сжатие, кодирование, декодирование), TAK выглядит наиболее привлекательно. Высокая скорость работы объясняется активным использованием процессорных оптимизаций (в т.ч. SSSE3). А использование двух ядер дает почти двукратный прирост скорости кодирования! Таким образом, в случае с TAK преимущество от использования современных процессоров наиболее ощутимо.
5. WavPack - честно говоря, я не знаю, за счет чего этот кодек приобрел популярность. Кодирование со средней степенью сжатия дает результаты сравнимые с FLAC, а использование режимов высокого сжатия приводит к неоправданному понижению скорости. Хотя, главным плюсом этого кодека является его широкая поддержка и функциональность (в т.ч. поддержка многоканального аудио, гибридного режима), но напомню, что эту сторону вопроса мы в данном тесте не рассматриваем.
6. FLACCL - без сомнений, это очень высокопроизводительный кодер, который рекомендуется к использованию всем, у кого есть видеокарта с поддержкой CUDA. Кроме того, с его помощью можно, хоть и незначительно, но увеличить степень сжатия во FLAC.
7. True Audio (TTA) - тут надо отметить разве что очень высокую скорость кодирования и приемлемую степень сжатия (чуть выше чем у FLAC). При этом скорость декодирования нельзя назвать очень высокой.
8. Flake - преимущество от использования этого кодера с максимальным сжатием весьма сомнительно. Кроме того, такие высокие настройки сжатия могут привести к потере обратной совместимости с некоторыми аппаратными декодерами. Вероятно, этот кодек даст какое-то реальное преимущество по скорости (в сравнении с референсным flac.exe) только при уровне 8 и ниже.
9. FLAC - степень сжатия средняя, но вот скорость декодирования порадовала. Правда, главной причиной лидерства этого кодека среди общественности является открытый исходный код, и, как следствие, широчайшая аппаратная/софтовая поддержка.
10. Apple Lossless (ALAC) - один из тех кодеков, которые ничем не примечательны, но продолжают активно насаждаться разработчиками (в данном случае Apple). Низкая степень сжатия и скорость декодирования. Скорость сжатия - средняя. Подойдет разве что пользователям iPod - у них просто нет выбора.
11. WMA Lossless - случай аналогичный ALAC, но здесь мы имеем дело со корпорацией-гигантом Microsoft. Еще меньшая степень сжатия, средняя скорость сжатия. Скорость декодирования относительно высокая. Трудно представить случай, в котором возникла бы необходимость использовать именно этот lossless кодек.
Вывод: и так, по результатам теста, его победителем я объявляю молодой кодек TAK. Остается с нетерпением надеяться, что разработчик вскоре откроет исходный код.
Информация от спонсора
MEGOGO.NET: бесплатные мультики смотреть онлайн. Огромная коллекция самых лучших и новых мультфильмов.
Хорошая статья, но все же два замечания у меня есть.
1) Никто в здравом уме в WavPack hhx6 не кодирует. По личным тестам от этого есть прок только для определенных типов музыки (эмбиент, например). При hhx3 скорость упаковки приемлемая, а результат зачастую лучше флаки, в среднем плотнее на 4-7 метра при стандартной длине альбома. Из-за этого не согласен с заключением по поводу WavPack, к тому же не стоит забывать, что он свободный кодек, и проигрывается на всех популярных ОС (в отличии от TAK, который жуется только на винде и только несколькими плеерами).
2) Тест на одном альбоме не совсем объективен. У меня имеется альбом, который WV hhx1 кодирует на 10 метров сильнее флаки8, при hhx3 уже на 20 метров, и более чем на 25 при hhx6, достигая сжатия, сравнимого с обезбяной -c4000. Однако, есть альбом, который флакой ужимается так, что WV / TTA / ALAC проигрывают метров 20 и более. Так что хотелось бы видеть более объемный тест - примерно как тут (50 разных композиций, разных жанров, правда тест 2008 года).
По поводу победителя конечно претензий нет - TAK объективно сейчас лучший по показателю скорость/плотность, за ним будущее, если конечно Томас наконец-то додумается до очевидного и откроет исходники в ближайшие год/два. Иначе поезд уйдет - там кажется xiph планируют продвинутый современный гибридный lossy/lossless кодек пилить (кодовое название Ghost), ориентировочно на 2015 год.
У меня два вопроса: в тесте lossless кодека wavpack вы используете асиметричное кодирование 6 уровня потому что в исходном треке есть синтетические сигналы, если нет, то почему? И второй в тестах lossy кодеков mp3 320 kbps вы используете lame 3.98.4, хотя в тесках кодеров mp3 вы назвали лучшим на данном битрейте lame 3.93.1. Почему? Заранее спасибо.
Плагин для декодирования ALAC в foobar'е какой-то тормознутый. При декодировании через командную строку скорость получается в несколько раз больше (это при том, что идет запись в файл).
Любопытно было бы посмотреть подробные тесты TAK vs FLAC. Может даже на разном материале.
Поигрался с Tak немного. Вот только редко встречается в дикой природе :|
Нам остается только ждать и надеяться.
зы. Может добавить в Програмы Pleasurize Music Foundation TT Dynamic Range Meter v1.4a ?
И ещё, например, в Кодеры и утилиты:
Audio Identifier
MP3 Diags
Mr QuestionMan
MP3val
Да, я как-нибудь сделаю подробное сравнение - с графиками и всем полагающимся.
Насчет утилит.
AudioIdentifier - более чем заменяется фубаром (просмотр версии кодера и параметров, если они указаны) и EncSpot'ом (информация о MP3 и LAME Tag в нем более детальна и удобнее оформлена).
MP3Val - заменяется фубаром (fix vbr mp3 header, rebuild mp3 stream)
MP3Diags - буду благодарен, если дадите ссылку на исполняемый файл windows. Назначения пока не понял.