Литература
Архив выпусков
Тестирование проводилось на tstenc.exe v021a (енкодер), tstdec.exe v020b (декодер).
Информации об алгоритме TAC мне удалось раздобыть совсем немного. Да и та, что удалось раздобыть, крайне скудна. Но, все же, попытаемся разобраться что есть TAC и что он дает. Алгоритм TAC (Transparent Audio Compression) разработан (разрабатывается) K+K Research. По информации, TAC во многом отличается от MPEG-2 AAC и MPEG-1 Layer III. Во-первых, TAC не использует TNS (Temporal Noise Shaping), а также технику Prediction (предсказание). В то же время, TAC использует технику поиска и устранения замаскированных частот и проводит психоакустический анализ сжимаемого сигнала, в чем он схож почти со всеми современными алгоритмами . Кроме того, TAC использует технику ABM (Adaptive Bitrate Management - адаптивное управление битрейтом). Отмечается, что ABM - это метод анализа и предсказания наиболее подходящего битрейта для кодирования. Что это за техника конкретно мне не неизвестно, как неизвестно и то, является ли этот формат потоковым (streaming), то есть поддерживается ли декодирование потока "на лету". В отношении ABM хочется отметить, что судя по названию и сути ABM очень похож на VBR (Variable Bitrate), используемый во многих алгоритмах (например, MPEG-1 Layer III, Vorbis Ogg). Если бит-поток TAC является фреймовой структурой, то, возможно, ABM - это тот же VBR; если TAC имеет не фреймовую структуру, то тогда непонятно как происходит изменение битрейта с течением времени (хотя, что-то мне подсказывает, что TAC все-таки фреймовый). Так или иначе, в тестируемом енкодере битрейт явным образом указать невозможно, можно указать лишь приблизительную степень компрессии (1:3, 1:5 ... 1:15). Кроме того, даже при указании определенной степени компрессии, размер полученных файлов сильно варьируется, что говорит о влиянии содержимого сжимаемых аудио данных на степень их сжатия и подтверждает использование ABM. Еще один немаловажный момент: в зависимости от указанной степени компрессии алгоритм сам выбирает какую модель кодирования стерео панорамы использовать.
А теперь само тестирование. Целью тестирования являлось не детальное изучение качества, а лишь приблизительная оценка возможностей алгоритма TAC. Для тестирования был взят файл определенной длины (5-6 секунд, 44.1 Кгц, 16 бит, .WAV). Музыку я подобрал таким образом, чтобы увидеть и "басы", и "верхи". Затем было произведено кодирование этого файла с помощью TAC-encoder. Для того, чтобы было с чем сравнить, параллельно этот же фрагмент был сжат енкодером Lame при 128 Kbps. Однако результирующие файлы отличались размерами, поэтому пришлось подбирать битрейт для кодирования Lame'ом так, чтобы размеры файлов совпали. Путем подбора наиболее подходящим битрейтом оказался 144 Kbps. Размеры файлов при этом отличались на 6 килобайт (540 Kb - MP3, 546 Kb - TAC). Затем было произведено обратное декодирование фрагментов и сравнение их статических результирующих АЧХ. АЧХ в диапазоне до 10 КГц оказались почти идентичными, так что обратим внимание на верхний диапазон частот, начиная с 10 KГц (неравномерность графика связана с использованием для тестирования относительно короткого фрагмента, а также с выбором высокого разрешения FFT):
Обратите внимание на резкий спад на границе 20 КГц. Судя по характеру спада, составляющие выше 20000 Гц преднамеренно отфильтровываются. Кроме того, можно заметить, что реакция TAC на всплески амплитуды менее слабая, чем у MP3. В динамике же я заметил еще одну неприятную и довольно заметно слышимую особенность. Реакция в диапазоне высоких частот ограничивается только ответом на сильные, мощные всплески. Менее же слабые всплески вообще игнорируются кодером. Это хорошо заметно при внимательном прослушивании звучания тарелок: появление и исчезновение высоких частот (своего рода скачкИ) хорошо различимы на слух; в то же время в MP3 такого эффекта не наблюдается. Как раз на этом фрагменте отображена АЧХ где на высоких было только стучание тарелок, остальные звуковые события развивались на средних частотах.
А вот другой музыкальный фрагмент (АЧХ изображена в таком же, как и предыдущая, масштабе): здесь имеются уже насыщенные верхние частоты на всей протяженности сигнала.
Как видно, тут уже и MP3 не выглядит безгрешным. Однако, если график MP3 покрывает WAV почти полностью, то TAC ведет себя странновато: то ниже нужного, то выше. График TAC вообще слабо похож на график MP3 или оригинального WAV. Спад на тех же 20 КГц. Замечу снова, что данный фрагмент имеет совсем иное частотное насыщение, нежели предыдущий.
Сравнение качества компрессии на более высоких битрейтах я проводить не стал, так как закодировав совершенно аналогичный фрагмент на чуть более высоком битрейте я получил результат, заметно лучший на слух, чем предыдущие.
Итак, что же можно сказать в общем. .В общем, не смотря на некоторые неурядицы с АЧХ, звучание TAC мне, как ни странно, понравилось. Компрессор явно творит со звуком что-то "не то" (по всей вероятности, в следствие использования отличной от MP3 психоакустической модели), однако на восприятии сигнала это сказывается не сильно, за исключением момента со скачками высоких частот, что действительно немного раздражает. В целом, у меня создается ощущение, что алгоритм TAC проявит себя намного лучше при кодировании на более высоких битрейтах, и некоторые негативные результаты произведенного тестирования можно списать на то, что оно проводилось на потоках с максимально допустимым в TAC сжатием. Это косвенно подтверждается тем, что в документации к TAC прямо заявлено: "если вы хотите сжимать аудио на экстремальных битрейтах ниже 120-130 - TAC не для вас". Кстати, такое заявление не может не радовать. Оно указывает на стремление разработчиков не "удалбывать" звук в 64, 96 и 128 Kbps, а потом кричать на каждом углу, что 128 Kbps это "CD-качество", а следовать разумной стратегии стремления к качеству звучания. Подтверждение этому мы уже обнаружили - срез частот делается не на 16 Kbps, как было когда-то с MP3, а на 20 КГц. Другой вопрос, на сколько качественно осуществляется кодирование верхних частот, однако срез именно на 20 КГц говорит о наличии некоторого уважения к пользователям, чьи уши часто не медвежьи и способны отличить 16 Кгц от 20.
Стоп. В последний момент мне пришла в голову одна идея, о которой я сейчас сообщу. Ко мне как-то обратился человек с вопросом: "А есть ли какой-нибудь енкодер (алгоритм), который способен кодировать "тишину" в 0 Кб?". Такой способ кодирования был бы очень применим при кодировании голоса диктора (переводчика), например, к фильмам. Да, такие алгоритмы существуют. Это специальные вокодеры - алгоритмы, предназначенные специально для сжатия голоса человека. Методы сжатия и анализа звука, применяемые в вокодерах, не позволяют им сжимать ничего, кроме голоса. То есть качество кодирования таким алгоритмом, например, музыки, будет просто абсурдным. А что же делать, когда есть и голос и звук? И вот тут я решил попробовать TAC. Не даром, ведь, там применяется технология ABM. Итак, я сгенерировал файл с абсолютной тишиной, размером 4,5 минуты, 53 Mb. TAC сжал этот файл (на минимально допустимом битрейте) в 168 Кb! Для сравнения, Lame Encoder (MP3) сжал его в 1,194 Mb. По поводу Lame это и понятно, ведь я использовал переменный битрейт (VBR), а в MPEG-1 Layer III он не может быть ниже 32 Kbps. Тогда я провел еще один эксперимент: сгенерировал файл размером 44 Mb, где больше половины была тишина, перемежающаяся с музыкой. Результат таков: TAC - 520 Kb, MP3 - 1,640 Mb. Вывод. Похоже, что TAC при кодировании тишину действительно заменяет почти на 0 килобайт, но кодирование остальной информации он проводит на достаточно высоких битрейтах, приближающихся к указанному при запуске енкодера. Lame же производит кодирование во всем диапазоне битрейтов между указанными для VBR. Так как минимально допустимый битрейт 32 Kbps, то тишина кодируется именно с этим битрейтом, остальные же данные кодируются на битрейтах в промежутке. Таким образом, если в кодируемых данных присутствует абсолютная тишина, однако кодирование данных необходимо провести с максимально высоким качеством, TAC может оказаться гораздо более полезным, чем MP3.
Есть только одно огорчение: полноценного доступного плаг-ина для воспроизведения TAC-потоков в каком-нибудь распространенном проигрывателе не существует. В основном по этой причине я не проводил более тщательного и детального анализа.
Если у вас есть замечания, предложения или дополнения, присылайте их на e-mail.