на главную страницуна главную страницуна главную страницу

Новости | 3D-Видео, тюнеры и LCD | iT-Среда | MacLife | Мобильные устройства | Ноутбуки | Носители информации | Платформа ПК | Приложения и утилиты | Принтеры и периферия | ProAudio | Проекторы и ТВ | Сети и серверы | Цифровой звук | Цифровое видео | Цифровое фото | Карта сайта | Поиск


Открытая методика тестирования скорости компрессии звуковых файлов в форматы MP3, OGG и WMA


Данная «большая разборка» с тестами на скорость компрессии «сырого» (WAV/PCM) аудио, в основном инициирована появлением статьи «Ящики Пандоры», Серия первая: MP3-кодек LAME, в которой мы детально исследовали аспекты работы одного из самых популярных MP3-кодеков — LAME. Достаточно конструктивный feedback на этот материал позволил нам окончательно определиться как с используемым в тестах программным обеспечением, так и с его опциями и прочими относящимися к делу тонкостями. В результате было решено во-первых расширить методику за счет введения в нее новых кодеков и форматов, а во-вторых — написать пусть и примитивный, но тем не менее вполне работоспособный скрипт (bat-файл), позволяющий полностью автоматизировать процесс тестирования (по принципу «запустил — пошел пить кофе»). Впрочем, хотелось бы заметить, что возможности «малого скриптинга» в Windows за счет умного использования bat-файлов многие недооценивают. В конечном итоге, после тщательного отбора, у нас «нарисовался» следующий набор кодеков и форматов, претендующих на более-менее массовую распространенность:

Форматы, кодеки, и сопутствующее ПО

  1. До сих пор один из самых популярных MP3-кодеков LAME 3.93. В тестах мы решили использовать сборку от SMPMAN. Как показали наши внутренние исследования, она является одной из самых быстрых, хоть и не столь хорошо известна Windows-пользователям, как другая, от MP3-Tech.org.
  2. Менее популярный, но зато очень быстрый и хорошо оптимизированный MP3-кодек GOGO 3.12 (он поддерживает наборы инструкций MMX, 3DNow!, E3DNow!, SSE, SSE2, и даже работу с несколькими CPU). К сожалению, автор распространяет свой продукт только в исходниках, поэтому использованную нами версию неизвестного (утерянного, скажем так) происхождения, мы выкладываем у себя.
  3. Достаточно динамично развивающийся и демонстрирующий неплохие результаты формат OGG Vorbis в лице OGG-кодера из недавно обновленного комплекта Vorbis Tools 1.0.1. Преимущества этого стандарта заключаются (по отзывам) в очень хорошем качестве звука на относительно низких битрейтах, кроме того стандарт изначально задумывался как полностью открытый и свободный.
  4. Забывать о присутствии в данном секторе форматов от компании Microsoft тоже не стоит, поэтому кроме всего прочего в методике присутствует кодирование в формат Windows Media Audio (в его последней, 9-й версии). Причем даже в двух режимах: обычный VBR (кстати, Windows Media Encoder 9 — единственная известная нам программа, осуществляющая двухпроходное (!) VBR-кодирование аудио) и также в очень интересном режиме Lossless Compression — сжатия аудиоинформации без потери качества.

Опции кодирования

Перебрав кучу различных очень любимых многими конкретными людьми пресетов LAME и поучаствовав в некоторых обсуждениях, мы пришли к довольно-таки очевидному выводу (ну… нужно же было проверить его очевидность): сколько людей — столько и мнений. Кому-то нравится altpreset, кому-то r3mix, кто-то подбирает для себя различные «хитрые опции» самостоятельно, а нам что делать? Поэтому было решено, что на всякого мудреца довольно простоты, и финальный набор параметров командной строки, выбранный нами для тестов, оказался именно максимально простым: <-m j -q 0 -V4 --silent>. То есть режим Joint Stereo при максимальном качестве CBR, среднем качестве VBR, ну и «не беспокойте нас вашими диагностическими сообщениями» (мало ли — может необходимость их выводить тоже на скорость как-то влияет…). Соответственно, кодек волен сам выбирать из диапазона битрейтов от 32 до 320 тот, который он сочтет оптимальным для данного момента. Гистограмма получаемого в результате использования этих параметров MP3 не представляет собой чего-то загадочного: как только кодеку дали выбирать битрейт полностью самостоятельно, он остановился точно посередине — большая часть файла оказывается закодированной с битрейтом 160 Kbps, можете убедиться сами:


С опциями для GOGO было намного проще: так как известно, что он базируется на коде LAME, вполне логичным было взять просто-напросто те же самые установки. За исключением мелких нюансов (маленькая буква «v» вместо большой и один а не два минуса перед «silent»), опции GOGO выглядят точно так же как и у LAME: <-m j -q 0 -v 4 -silent>. Результат, правда, как по скорости, так и по размеру, получается немного другой, ну да это тоже естественно — ведь код переписывался, а не просто копировался.

Кодек OGG Vorbis имеет одну интересную особенность — он при кодировании по умолчанию работает именно в VBR (точнее, это больше похоже на ABR) режиме. Причем авторы кодека настоятельно не рекомендуют оперировать параметром «битрейт» при работе со своим детищем, предлагая вместо этого явно указывать требуемое качество результата. Мы не стали им перечить, поэтому в полном соответствии с указаниями разработчиков битрейт кодеру OGG не указываем. Соответственно, набор опций получился и вовсе простой: <-q 5 --quiet> — кодировать со средним качеством и не выводить диагностических сообщений.

Windows Media Audio для нас самих является в некотором роде terra incognita, поэтому было решено особенно не «экстремальничать», и сосредоточиться на известном: битрейт, частота дискретизации, количество бит… Словом, чтобы получилось что-то похожее по параметрам на любимый и знакомый MP3 :). Опциями командной строки мы в данном случае не пользовались т.к. Windows Media Encoder имеет довольно удобный GUI-конфигуратор для создания профилей, которые можно потом просто «подсунуть» кодировщику в команде на осуществлении компрессии. Соответственно, вместо опций приводим скриншоты:





Установки для кодирования VBR






Установки для Lossless-кодирования

Пару слов о тестовом скрипте

Тестовый скрипт и сопутствующее ему вспомогательное ПО, которые в совокупности позволяют провести замеры времени кодирования с помощью всех вышеуказанных кодеков в полностью автоматическом режиме, доступны для скачивания и использования всем желающим. «Дистрибутив» (несколько, конечно, громкое слово для одного bat-файла и нескольких исполняемых, «рассованных» по каталогам) представляет собой исполняемый (EXE) файл в формате саморазворачивающегося архива 7-zip. После запуска, он может быть распакован в любой каталог по выбору, в котором, соответственно, появится подкаталог с именем «audio». В корне будет находится файл !audio.bat, запустив который без аргументов командной строки, можно получить справку относительно этих самых аргументов. Запуск с неизвестной скрипту опцией командной строки приводит к тому же эффекту.

Теперь о том, чего в составе «дистрибутива» нет. Во-первых, в нем нет тестового WAV-файла. Причина тому проста — вряд ли кто-то был бы обрадован необходимостью выкачивать вместе с методикой используемый нами 146-мегабайтный WAV. Кроме того, если количество желающих загрузить файл такого объема оказалось бы чрезмерно большим, это создало бы громадную нагрузку на сервер. Впрочем, если кто-то из читателей вдруг пожелает разместить данный файл на своем сервере и открыть его для публичного доступа — это вполне обсуждаемый вариант, свяжитесь с нами по почте. Ну а пока тонким ценителям исходников мы можем предложить сделать WAV, полностью аналогичный нашему, самостоятельно: «сграбив» с [откуда-то взятого] аудио-CD композицию «O`malley`s bar», из альбома «Murder Ballads», исполнители — Nick Cave & The Bad Seeds. В нашем случае при частоте дискретизации 44100 Гц и 16-битном сэмплинге, длина файла составила 146 МБ (153275180 байт), время звучания — 14 минут 28 секунд.

Те кто не является тонким ценителем могут просто положить в корневой каталог теста (т.е. туда же, где находится файл !audio.bat) абсолютно любой WAV-файл в формате PCM с именем TEST.WAV. Разумеется, в этом случае полученные результаты вряд ли будут совпадать со статьями iXBT (даже при идентичной аппаратной конфигурации), однако если вы планируете проводить сравнительные исследования различных систем — то, по идее, результаты сравнения должны совпадать с нашими выводами. Впрочем, есть мнение, что содержимое исходника влияет в том числе и на скорость… что ж, если кто-то это докажет эту гипотезу — тем более интересно будет ознакомиться с результатами.

Кроме того, в дистрибутиве отсутствует необходимый для прохождения тестов на скорость кодирования Windows Media Audio (только для них!) Windows Media Encoder 9. Мы посчитали, что желающие провести еще и эти тесты, вполне могут скачать его самостоятельно — благо, это абсолютно бесплатная утилита и она доступна для загрузки с сайта Microsoft. Экспериментировать с опциями установки Windows Media Encoder вы можете на свой страх и риск, скажем только сразу, что мы их не изменяли, оставляя все предложенные по умолчанию, поэтому в противном случае работоспособность скрипта не гарантирована.

Все остальные кодеки включены в состав дистрибутива в варианте, минимально необходимом для проведения тестирования.

Для тонких эстетов...

…Которые решат заинтересоваться исходниками скрипта и присутствующими в нем командами, приводим краткие разъяснения по поводу назначения некоторых использованных нами утилит и смысла некоторых действий скрипта, которые могут показаться не совсем очевидными.

Contig — это свободно распространяемый бесплатный дефрагментатор, позволяющий выборочно дефрагментировать отдельные файлы и/или каталоги, запускаемый из командной строки. Это утилита от Марка Руссиновича, которой уже очень много лет, но она, тем не менее, успешно работает даже в Windows XP. Contig использует стандартные функции Defragmentation API систем на базе ядра NT, в связи с чем совершенно бесполезен под Windows 9x (предупреждаем сразу). Для чего необходима дефрагментация перед проведением тестов, надеемся, объяснять не нужно.

Sync — еще одна утилита от Марка Руссиновича, являющаяся аналогом известной unix-утилиты с аналогичным именем. Sync «сбрасывает» дисковый кэш. Сброс дискового кэша выполняется перед тем, как скрипт осуществляет «принудительное кэширование» полезной информации (см. ниже про copy ... nul).

Timer — утилита от Игоря Павлова, позволяющая измерять время выполнения любой программы (способ ее использования в общем-то вполне понятен из текста bat-файла). Это одна из лучших программ подобного рода, которые нам известны, она выдает не только время исполнения самой программы, но и массу другой полезной информации.

Команда copy /y test.wav space.tmp с последующей дефрагментацией и удалением файла space.tmp служит для того чтобы освободить некий «кусок» дефрагментированного пространства для файлов, создаваемых в процессе работы скрипта. Можно, конечно, заметить, что уж слишком большой кусок освобождается, ну да «много не мало»…

Команда copy test.wav nul преследует элементарную цель — прокэшировать файл test.wav перед исполнением собственно теста на скорость сжатия, чтобы он побыстрее читался программой кодирования. Это сделано специально, чтобы уменьшить влияние дисковой подсистемы на результаты тестов. Файл копируется «в пустоту», поскольку нас интересует не собственно копирование, а то, чтобы он был прочитан перед выполнением теста.

Как многие наверняка заметят, сами закодированные файлы в процессе прохождения теста не создаются — ибо вывод программ-кодировщиков перенаправляется на устройство nul (опять-таки, «в пустоту»). Это также сделано с целью уменьшить влияние дисковой подсистемы на результаты тестов. Если вам интересно посмотреть на результаты кодирования просто замените в соответствующей строке скрипта nul на реальное имя файла.

Сообщение Timer (в логах выполнения) наподобие Process Time = 66.296 = 00:01:06.296 = 128% т.е. о том, что время, занятое процессом, превышает общее время исполнения программы, не является «глюком», а всего лишь свидетельствует о том, что у вас многопроцессорная система, и приложение в процессе выполнения создало несколько потоков. В данном случае указано суммарное время исполнения всех потоков, что при их числе более одного, естественно, превышает 100%. Такая ситуация характерна для GOGO и Windows Media Encoder на системах с двумя процессорами или с Pentium 4 + Hyper-Threading т.к. эти приложения умеют использовать более одного процессора.

О поддержке

Разумеется, мы выкладываем этот тестовый пакет не просто для того, чтобы похвастаться (да и чем тут, собственно, хвастаться…), и заинтересованы в том, чтобы его функциональность проверило как можно большее количество людей. Поэтому все сообщения о «глюках», ошибках, невозможности запуска, и т.д. и т.п. только приветствуются. Равно как и предложения по поводу изменения опций, состава ПО, версий, и прочего. Направляйте их электронной почтой. Однако не ждите, что ошибки будут исправляться тут же, в течение часов или даже суток. Все-таки, основное предназначение данного пакета — это проведение тестов на скорость компрессии аудиоинформации в рамках нашей тестовой лаборатории, поэтому более всего нас интересует то, чтобы он правильно работал у нас.

Это не значит, что мы отказываемся от поддержки, просто ее интенсивность будет зависеть от загруженности сотрудников основной работой. И, в любом случае (нелишним будет напомнить) — вы используете данный скрипт на свой страх и риск, и мы не отвечаем за то, что он «натворит» на вашей машине (хотя и честно стараемся, чтобы ничего крамольного не происходило). Новости относительно изменений, дополнений, и прочего, вы всегда можете найти на специально отведенной для этого страничке.

О использовании тестового пакета другими масс-медиа и прочими коммерческими организациями

Конечно же, можно. Однако если вы все-таки решили, что проще скачать готовое, чем писать и разрабатывать что-то самостоятельно — то, наверное, будет вполне логично упомянуть разработчика продукта, который вы используете сайт iXBT.com. Во-первых, тем самым вы выразите элементарную признательность тем, кто все это сделал (каким бы простым и немудрящим не казался их труд), ну а во-вторых вашему читателю (клиенту) от этого будет только лучше: он получит возможность сравнивать массу результатов, полученных в рамках открытой методики, причем не только вами (и нами), но даже просто обычными пользователями на их собственных компьютерах. А для этого ему нужно как минимум знать, что использовалась именно данная методика.

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

Станислав Гарматюк (nawhi@ixbt.com)

Опубликовано — 5 декабря 2003 г.
 
Комментарии? Поправки? Дополнения? nawhi@ixbt.com



Новости | 3D-Видео, тюнеры и LCD | iT-Среда | MacLife | Мобильные устройства | Ноутбуки | Носители информации | Платформа ПК | Приложения и утилиты | Принтеры и периферия | ProAudio | Проекторы и ТВ | Сети и серверы | Цифровой звук | Цифровое видео | Цифровое фото | Карта сайта | Поиск

Copyright © by iXBT.com, 1997—2012. Produced by iXBT.com