Сжатие звука

Аудио MPEG, аудио не MPEG
и не аудио MPEG

(C) 1998 Олег Барабаш, г.Пенза

После прочтения вы огорчитесь, но не очень. 12 пунктов.

0. Есть группа людей, занимающихся сжатием аудио и видео. Они называют себя Moving Picture Expert group (группа экспертов по сжатию видео и аудио). Они разработали ряд стандартов, которых придерживаются почти все производители. Эти стандарты так и называются MPEG — по английской аббревиатуре.

1. Все начинается со стандарта MPEG. Это стандарт сжатия аудио и видео потоков, а так же потоков их взаимной синхронизации и, так называемых "вспомогательных" потоков (ancillary). Под потоком понимается битовый файл.

2. Всего в настоящее время существует пять видов (номеров) стандартов MPEG:

MPEG1 — сжатие аудио и видео с общей скоростью до 150 Кбайт/сек (аудио 38,44.1, 48 килогерц);

MPEG2 — сжатие аудио и видео с общей скоростью до 300 Кбайт/сек (аудио 38,44.1, 48 килогерц), сжатие аудио ИДЕНТИЧНО MPEG1;

MPEG2.5 — сжатие аудио с пониженным разрешением (аудио 16,22.05,24 килогерц);

MPEG3 — многоканальный MPEG1+MPEG2, этот стандарт практически умер;

MPEG4 — новомодный за рубежом стандарт. Его особенность: может держать до 8-и каналов аудио (то есть AC-3 — цифровое расширение системы Surround. Как моно сменилось стерео, как стерео пыталось смениться квадро, как стерео сменилось surround, так же и surround пытается смениться AC-3. Думаю, AC-3 будет стандартом аудио-систем, хотя есть одно НО. Я имею в виду наушники, плеера и др. Так и так, в дороге придется довольствоваться адаптером AC-3 в стерео, поэтому AC-3 может пригодиться только для домашних аудио центров и домашнего кинотеатра. К сожалению, оценка качества звука может производиться только в наушниках. Поэтому проверить качество AC-3 достаточно сложно. Я, например, без "ушей" в автобусах не езжу. Поэтому AC-3 не очень одобряю, но при возможности от него не откажусь...).

Интересно заметить, что стандарт MPEG2.5 (еще известный как MPEG2 LSF — LOW SAMPLE FREQUENCY (низкая частота сканирования аудио) введен фирмой IIS Fraunhofer (институт информационных технологий имени Фраунхофера из Германии), о котором мы еще поговорим. Этот стандарт является расширением "чистого" аудио MPEG2 (то есть MPEG1!) для частоты сканирования аудио в два раза меньшей, чем обычно.

Выводы:

• неправомочно называть любой аудио (или видео) поток выражением MPEG3, поскольку этого стандарта не существует;
• неправомочно различать форматы аудио по стандартам MPEG1 и MPEG2, так как это одно и то же! Здесь имеется в виду "чистый" стандарт MPEG2;
• обычно MPEG2.5 просто называют MPEG2, что вносит дополнительную путаницу. MPEG2.5 правильнее нужно называть MPEG2 LSF;
• качество компакт дисков может быть достигнуто только при использовании MPEG1 (и "чистого" MPEG2);
• для MPEG2.5 (к сожалению его почти все программы-кодировщики MP3 называют MPEG2!) можно добиться только качества 22.05 Кгц (ровно в два раза хуже CD!);
• при упоминании выражения MPEG2 нужно понять, о чем идет речь. Маленький пример: фильм на DVD. Ясно, что используется стандарт MPEG2 (по крайней мере, для видео). Что касается аудио, здесь надо получить спектр аудио сигнала. Если частоты резко срезаются на 22 Кгц, тогда аудио сделано в стандарте MPEG1. Если срез аудио происходит на 11кГц — перед нами MPEG2.5 (он же MPEG2 LSF).

3. Каждый стандарт содержит несколько частей. В основном это такие части:

• формат сжатого потока видео;
• формат сжатого потока аудио;
• формат потока синхронизации;
• формат вспомогательного потока;
• * неоптимальная программная реализация алгоритмов кодирования и декодирования всех предыдущих потоков (обычно на ANSI си).

Звездочкой отмечен пункт, доступность (или значимость) которого для нас с вами практически на нуле. Например, мне удалось нарыть некоторые исходники, но по сравнению с ними все самые тормозные кодеры WAV->MP3 намного быстрее.

4. Нас интересует часть MPEG, относящаяся к аудио. Фактически здесь определено несколько слоев качества (Layer - слой). Они так же нумеруются:

Layer 1
Layer 2
Layer 3
Layer 4 (пока нет).

В стандарте под номер слоя отведено 2 бита, поэтому и слоев может быть только 4. Опишу слои по порядку:

4.1. Layer 1

Самая первая разработка. Позволяет сжимать аудио в 3..12 раз. Качество CD сохраняется при степени сжатия не более 4-х раз. Именно этот слой стал родоначальником всех следующих, причем именно он лежит в основе системы сжатия мини-дисков SONY. В общем, это дерьмо. Любой файл, сжатый с помощью такого слоя теоретически должен иметь расширение MP1. Суть алгоритма сжатия:

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

Суть алгоритма декодирования:

берется заголовок и определяется размер блока коэффициентов;
читаются усеченные коэффициенты;
коэффициенты восстанавливаются;
производится обратное косинусное преобразование (синтезация);
полученный сигнал (восстановленное аудио) записывается в выходной поток.

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

4.2. Layer 2

В связи с низким качеством первого слоя математики приступили к его оптимизации. После уточнения множества специальных таблиц, введения тройного гребенчатого фильтра в модель первого слоя родился Layer 2. Во-первых, он строит гребенчатую цепочку аудиоданных в трех циклах, за счет чего общее качество увеличивается субъективно для быстрых скачков аудио-сигнала. Это позволяет сгруппировать коэффициенты для косинусного преобразования в три похожие подгруппы, значит в лучшем случае степень сжатия увеличится в трое по сравнению со слоем 1. Но на самом деле вышло несколько хуже. Старая акустическая модель нашего уха для слоя 1 уже не срабатывала так хорошо для Layer 2, поэтому пришлось усложнять и улучшать эту модель и вносить в нее процедуры быстрого преобразования Фурье, что значительно замедляет просчет психоакустической модели при кодировании. Все процедуры при сжатии также усложняются в 3 раза, а значит увеличивается и время сжатия. По сравнению с Layer 1 процедура сжатия Layer 2 работает медленнее в 12 раз. Что интересно, алгоритм восстановления потока практически не усложнился, хотя в него приходится внести тройные циклы для 3-х подгрупп коэффициентов обратного косинусного преобразования. Многие ученые-математики начинают задумываться над ускорением алгоритма ДКП (дискретного косинусного преобразования). Но вот незадача: работы ведутся только по ускорению ОБРАТНОГО ДИСКРЕТНОГО КОСИНУСНОГО ПРЕОБРАЗОВАНИЯ (именно оно используется при восстановлении аудиоинформации, а значит нужно для воспроизведения разжимаемого аудио в реальном времени; именно оно используется при восстановлении видеоинформации в сжатом потоке VideoCD). На этом поприще выделилась фирма Xing Technology, она смогла увеличить производительность своих программных распаковщиков потока Video CD до возможности нормального воспроизведения на Pentium младших моделей (к сожалению необходим 2D видео-акселератор для масштабирования видео картинки 352 X 240 на весь экран). Запомним фирму Xing и ее произведение Xing MPEG (хотя, если честно алгоритм ОДКП этой фирмы до сих пор самый грубый и паршивый). А вот ПРЯМОЕ ДИСКРЕТНОЕ КОСИНУСНОЕ ПРЕОБРАЗОВАНИЕ не оптимизируется никак! То есть при сжатии аудио тратится масса времени. Мало того, Intel выпускает технологию MMX (о ней еще будет сказано далее) и дает примеры ускорения расчета... ОБРАТНОГО ДКП. Про прямое ДКП опять молчок. Так что обладатели процессора с технологией MMX ничего не выигрывают при сжатии аудио!

Алгоритмы сжатия и декодирования аналогичны алгоритмам слоя 1 с поправкой на утроенный цикл получения коэффициентов и усложненный психоакустический алгоритм. Субъективно алгоритм Layer 2 дает качество, неотличимое от CD при степени сжатия 4..6 раз. Файлы, упакованные этим слоем имеют расширение MP2.

4.3. Layer 3

Никому не известная в 1992 (да, наверное и до 1998 года) фирма IIS Fraunhofer (институт имени Фраунхофера) совершает научный прорыв: если мы получили коэффициенты прямого дискретного косинусного преобразования, то почему бы не использовать эту же процедуру еще разок на этих же коэффициентах? Они попробовали сначала в лоб — произвели преобразования второй раз вдоль коэффициентов. Результат — ноль. Тогда какой-то немецкий непризнанный гений решил посмотреть на проблему в лежачем положении: он разделил коэффициенты на три связки (то есть первая связка — 1-й,4-й,7-й и т.д. коэффициент; вторая связка 2-й, 5-й, 8-й и т.д коэффициент; третья связка 3-й, 6-й, 9-й коэффициент и т.д.), проделал еще одно дискретное косинусное преобразование по отдельности на этих связках, подкорректировал алгоритм декодирования — и открытие состоялось: при той же степени сжатия качество выросло в 4 раза! Начались эксперименты, в ходе которых было выявлено следующее:

гораздо лучше не делить все на три подгруппы как в Layer 2, и потом делить их еще на три связки; а сразу изменить алгоритм Layer 2 и брать вместо 3-х подгрупп 32-е подгруппы и уже потом делать поперечное преобразование на 36-и (а не 3-х!) связках. То есть: Layer 1 1*1152; Layer 2 3*384; Layer 3 32*36 (это размерности матрицы коэффициентов для ДКП).
полученные коэффициенты можно усекать до 4-х бит! (в Layer 2 и Layer 1 только до 16-ти).

В совокупности Layer 3 получился качественным и медленным. Мало того, необходимо было опять переделать и усложнить психоакустические модели и добавить некоторые элементы архивации по фиксированной таблице Хаффмана (это тот алгоритм, что используется в архиваторе ARJ, только в ARJ эта таблица динамическая и постоянно изменяется, что требует два прохода по данным; При фиксированной таблице сжатие происходит за один проход).

Все выше перечисленные изменения вылились вот во что:

новое расширение MP3;
степень сжатия с качеством CD в 6..8 раз (не кричите и не ругайтесь, любители 10-ти и 12-ти кратной степени сжатия, прочитайте до конца!);
скорость сжатия уменьшилась в 24 раза по сравнению с Layer 2;
скорость распаковки уменьшилась в 8 раз.

Что, страшно?

Фирма IIS Fraunhofer делает АППАРАТНУЮ реализацию кодера и декодера слоя 3 в реальном времени. Эта аппаратура идет на УРА в Германии и на олимпийских играх в Альбервилле Германское теле- и радио- вещание экономит кучу денег на передаче сжатого в 12-раз аудиопотока по спутниковым каналам.

На этом вроде бы все и должно было остановиться, но фирма Intel думает по-другому. Pentium-133 и выше МОЖЕТ сжать поток Layer 3 с конечной скоростью (в 30 раз медленнее однократной скорости CD-ROM — 5 КБайт в секунду). Фирма Fraunhofer берется за клавиатуру и начинает оптимизировать код упаковщика и распаковщика. Рождается известный большинству из вас L3ENC и L3DEC (сделаны на основе GNU C++), они продаются за значительно меньшую цену по сравнению с аппаратными реализациями. Рынок был найден. Постепенно в недрах Японии и института IIS Fraunhofer рождаются быстрые алгоритмы ДКП и ОДКП для 36-и точек (именно они нужны в алгоритме Layer 3). Появляется первый проигрыватель в реальном времени под Windows 3.1 — Winplay 3 (до сих пор эталон качества воспроизведения). Но деньги любят счет:

Winplay 3 без регистрации играет только 30 секунд;
L3ENC без регистрации позволяет сжимать только в 12 раз.
MP3ENC (Mpeg Encoder 3.0 demo от Фраунхофера) сжимает только 30 секунд аудио, продается только через кредитную карточку.

В Америке студент Джефф Цей (Jeff Tsay?) в это время работает над реалтаймовым проигрывателем *.MP1 и *.MP2 файлов (MAPLAY) под Win95, причем распространяет свое детище бесплатно. В дальнейшем он включает в код поддержку *.MP3 (проигрывание в реальном времени).

Институт Fraunhofera передает аппаратную часть в фирму Dialog 4 в той же Германии. Мы балдеем от сжатия ADPCM (Ima Dvi, Microsoft) в 4-е раза, хотя качество этих алгоритмов (они являются сейчас частью сжатия аудио в Windows 95) в сотни раз хуже разнесчастного Layer 1. Мы балдеем от мини-дисков Sony, хотя по сравнению с MP3 это прошлый век...

За рубежом появляются интерактивные альбомы "всех песен группы...": качество 16-бит 22кГц или 8-бит 16 Кгц, а то и "МОНО"! Эти опусы — смерть ушам! Но мы еще этого не знаем и покупаем эти сборники...

В гонку вступает MMX. Intel выпускает MMX процессор (это довесок на регистры математического сопроцессора, который якобы в 8 раз ускоряет расчеты. НО! MMX - целочисленная среда, значит для ускорения в 8 раз нужны БАЙТОВЫЕ алгоритмы (регистр MMX 64 бита! Байт — 8 бит, значит будет восемь целых чисел, отсюда и ускорение в 8 раз) это числа от 0 до 256. Смех да и только. Даже если довести целые переменные до 32 бит (два целочисленных числа — скорость обработки в 2 раза больше) двоичное косинусное преобразование нельзя будет реализовать в принципе! В качестве шутки фирмой Intel предлагается целочисленная реализация ОБРАТНОГО косинусного преобразования на MMX "для разработчиков систем AUDIO и VIDEO сжатия". Эту плюшку подхватывает фирма Xing, после чего при просмотре фильмов их программой при установленном флажке Use MMX (Применять MMX) на белом фоне появляются невесть откуда взявшиеся черные лепешки-квадраты (имеется в виду Xing MPEG player 3.20). Разработчики из Xing! Двоичное косинусное преобразование очень критично к качеству и точности чисел! Только вещественные, и никак не целые числа позволят более-менее точно произвести ДКП и ОДКП! Это было сразу понято и реализовано в Xing MPEG player 3.31. Задачи MMX сведены только к ускорению чтения и записи видео потоков с CD!

Дальше — больше. Бог с ним, с ММХ. Там ведь еще один прикол и еще одна шутка Intel: MMX при подаче первой команды ОТКЛЮЧАЕТ обработку вещественных чисел (то есть математический сопроцессор), поскольку экономии ради использует ИМЕННО РЕГИСТРЫ МАТЕМАТИЧЕСКОГО СОПРОЦЕССОРА! Ведь два человека на одной лавке не усидят, поэтому до подачи команды EMMS математический сопроцессор в ауте. Плюс переключение из Float coprocessor в MMX и обратно — за 6-ть тактов, плюс состояние вещественных регистров запоминается в резервной памяти, в которой при определенных условиях (системные прерывания и исключения) нарушается состояние регистра флагов сопроцессора! Короче до запуска команд MMX нужно где-то самому сохранить все регистры сопроцессора, а после команды EMMS еще и восстановить их!

Напомню, что алгоритм обратного ДКП для кодировщика — как мертвому припарки, поэтому даже если предположить использование MMX, скорость сжатия не увеличится, а качество сильно ухудшится.

Третьи фирмы делают деньги на некоторых "старых" алгоритмах, опубликованных IIS Fraunhofer. Рождается WinAMP. Видел я этот WinAMP. Проверка простая:

сделать MP3;
загрузить в WinAMP или MAPLAY;
сохранить распакованный поток в WAV-файл;
сравнить полученные результаты с деятельностью L3DEC из пакета запаковки/распаковки от самого IIS Fraunhofer.

Результат:

MAPLAY: на 64 кБайта разница в 1-м 2-х байтах (плюс/минус 1);
WINAMP: на 512 байт разница во многих байтах (плюс/минус 3);
XING: лучше не сравнивать... Это мрак.

Что касается WINAMP, то они сделали HQ-режим, 32-битный и 64-битный (интересно, как?) режимы, но времени сравнивать их с L3DEC не было. Поэтому если там все в порядке, тогда я сниму перед WinAMP шляпу. А пока — единственный вариант правильной распаковки MP3 в WAV:

l3dec in.mp3 out.wav
-wav

А пока WINAMP со всеми его скинами и плугинами для меня лично ноль. MAPLAY от Jeff Tsay идет с исходниками, поэтому я подработал его на предмет уровней громкости и общего оформления, на предмет открытия множества файлов, реалтайм приоритета и расслабился. Возможности MAPLAY:

играет все, что играется (WAV, MID, MOV, DAT, MP1, MP2, MP3 и др);
абсолютно бесплатный;
качественный плеер MP3;
имеет исходники для Borland C++ 5.01 и кучи других систем (напр., MAC,OS,UNIX и пр.).

Теперь дело об упаковщиках. Фраунхоферовцы выпускают L3 producer pro для Win95, причем это уже 32-х битный модуль, имеющий в своем составе ACM-фильтр (то есть теперь MPEG Layer 3 видят все стандартные упаковщики/распаковщики и плеера Win95), работающий в 3 раза медленнее односкоростного CD-ROM.

Кое-что я видел еще (простите за флейм, сдержаться не мог!):

RJPAENC — робяты, че это такое? MMX, 30% увеличение производительности и другое? Посмотрим... Берем экзешник и в отладчик. Где тута MMX? Нету чего то... А че тут вызывается какой-то еще экзешник? Мама родная! Так он бросил в WIN\SYSTEM файлец TOMPG.EXE и запускает его с параметрами... Вот тебе и упаковщик! Это же бездарнейший интерфейс к программе TOMPG.EXE (можно упомянуть хотя бы отсутствие возможности выбора нескольких файлов и несохранение всех опций после первого же зажатия). Ладно, лезем в TOMPG.EXE. Ух ты, чудеса - внутри Copyright Xing Tech. Опять Xing? Точно — он. Скорость работы — взрывная. В десять раз быстрее L3ENC из пакета Фраунхоферовцев. А с качеством? Проверим. Делаем одинаковые потоки любимейшей музыки с кучей верхних частот на L3ENC и TOMPG. Да, кстати не забыли ли мы в L3ENC ключик -hq? Нет, этот ключ не задавать - себя не уважать!

Сравниваем:

L3ENC — все как надо, звук на 5.
— TOMPG — мааамааа! пленку зажевало! Звук с потрескиванием, завалы после каждой 2-х секундной передышки, вау-дефекты и тсц-дефекты, жевка верхов и плыв низов... Почувствуйте разницу...

(Между прочим слушаю это в наушниках Philips, а не через колонки).

Може MMX чудит? Берем дебагер, ищем коды команд MMX... Батюшки! Робяты! И здесь обманули — нету ни в RJPAENC, ни в TOMPG ни одной, ни единой команды MMX! А как же с увеличением производительности на 33%? Теперь понятно. Это мыло и прикол. Никаких MMX, никаких ускорений... Нафига ускоренный запорожец без колес? Испоганеный алгоритм прямого ДКП — вот и все ускорение.

Вот что я скажу. После многократного тестирования разных поделок/подделок по L3 кодированию можно сделать один вывод:

лучший выбор l3enc my.wav my.mp3 -hq -crc -br 160000 (это в специальной "заказной" версии l3enc!) Даже L3producer гораздо хуже.

4.4. Layer 4

Пока только в туманном будущем. Хотя, может в недрах у немцев уже начинают шариться файлы MP4. Мне пока известно, что MP4 нигде нет. Сами товарищи из Fraunhofera пишут МЫ ЕСТЬ НЕ ПОНИМАЙТ ЧЕ ТАКОЙ MP4 (дураками прикидываются), мол почитай батенька про MPEG1,2,3,4 и пойми, что MPEG4 это не Layer 4. Сами то они понимают, о чем я? А вы? (Напомню, что под номер слоя отводится 2 бита — значит это может быть Layer 1, Layer2, Layer 3 и Layer 4 (слушай, а может это не Layer 4, а Layer 0? — спросит кто-то... Может это и нулевой слой, может до 20 века были файлы MP0, мне эта информация не доступна...). Короче нет пока и в помине никакого Layer4...

5. Подытожим так:

В каждом стандарте MPEG есть аудио потоки, каждый аудиопоток делится на 3 слоя (пока). Значит будут уместны такие выражения:

MPEG1 Layer 3 (третий слой MPEG1 — файл *.MP3);
MPEG2.5 Layer 3 (третий слой с пониженной частотой сканирования MPEG2.5 - файл *.mp3);
MPEG2 LSF Layer 2 (второй слой для частот 16,22.05,24 — файл *.mp2);
MPEG4 Layer 2 (второй слой MPEG4 — файл *.MP2).

На самом деле пока разработаны следующие сочетания:
MPEG1 Layer 1,2,3 (*.MP1,*.MP2,*.MP3)
MPEG2.5 Layer 2,3 (*.MP2,*.MP3) (или MPEG2 LSF Layer 2,3)
MPEG3 no layer
MPEG4 Layer 1 (*.MP1)

Как узнать, какой MPEG, если расширения файлов одинаковы? В заголовке блока любого упакованного аудио-файла эта информация всегда есть (кодируется двумя битами). Например, программа MAPLAY (о ней я не раз уже говорил) в пункте меню Audio Properties всегда показывает точный номер стандарта. Иногда стандарты нумеруются нестандартно (простите за игру слов):

MPEG I (MPEG1);
MPEG II (MPEG2);
MPEG III (MPEG3);
и т.д.

6. Теперь о САМОМ ПЛОХОМ.

Качество зависит еще от трех параметров.

А). Я уже упоминал психоакустическую модель. В настоящий момент известно две такие модели:

Musicam (полное дерьмо, обычно его использует Xing);
At&t (самая качественная пока модель, ее применяет L3ENC).

Б). Режим сжатия:

моно (mono);
стерео (stereo);
полустерео (joint stereo);
двойное моно (dual mono или dual channel).

Режим mono мы отбросим.

Stereo режим самый похабный из всех. Именно в этом режиме будет наблюдаться "жевание" верхов, будет слышно "ВАУ" на низах (это хорошо слышно только в наушниках!).

Joint stereo заключается в том, что коэффициенты средних частот усредняются (получается МОНО на средних частотах) и записывается только в каком ухе преобладающий сигнал (в левом, или в правом). Из-за этого остается больше места для верхних частот, поэтому объективно этот режим слушается качественнее STEREO (хотя бывают и исключения). В этом режиме обычно пропадает "ВАУ" и скрежет на верхах. Но появляется либо излишняя резкость верхов, либо их аккуратное сглаживание, из-за чего теряются эхо-эффекты и слабо слышимые звуки.

Наконец, режим DUAL CHANNEL, это самый качественный из всех алгоритмов. Работает вдвое медленнее всех предыдущих и дает потрясающее качество: нет ВАУ и тсц-эффектов, нет размытия ни верхов, ни низов, нет пропадания слабо слышимых звуков и др. На мой слух (в наушниках) при использовании режима DUAL CHANNEL нет НИКАКИХ отличий от исходного сигнала при степени сжатия в 8 раз. Потому я и утверждаю, что порог сжатия по Layer 3 — 8 раз. При сжатии в 10 и 12 раз в наушниках отчетливо заметно пропадание слабых звуков и вуалирование верхних частот даже в режиме DUAL CHANNEL (остальные режимы вообще мрак). Узнать тип режима можно все в той же программе MAPLAY (пункт Audio Properties).

Сделать поток DUAL CHANNEL позволяют очень редкие упаковщики. Для примера можете использовать пресловутый TOMPG.EXE (см в нем ключ -M). Хотя в нем при любом режиме качество отвратительное, сравнив между собой все четыре режима (-M0, -M1, -M2 и -M3 соответствуют mono, stereo, joint stereo и dual channel) вы поймете отличие dual channel от других режимов.

Все программы от Фраунхоферовцев не поддерживают DUAL CHANNEL, поэтому вам придется поискать нормальный упаковщик с этим режимом (только не TOMPG с его первой акустической моделью!) Можно запинать фирму Xing, чтобы они сделали вторую психоакустическую модель и убрали позорное съедание музыки. В. Третий, немаловажный параметр — высшее качество (режим hq). Определяется ключом программы L3ENC -hq. Сущность изменения алгоритма при подаче этого ключа мне непонятна, подозреваю, что увеличивается число итераций при усечении коэффициентов ДКП, что неизбежно должно давать лучший результат. Определить наличие hq невозможно.

Исходить можно только из следующих посылок:

работа при использовании ключа -hq в программе l3enc замедляется почти в 3 раза;
упакованные потоки с -hq и без него различаются как небо и земля, хотя заголовки данных в них идентичны (то есть все одинаково — тип, режим, слой, номер алгоритма MPEG и степень сжатия);
при прослушивании потоков с -hq и без него заметно колоссальное улучшение динамических характеристик звука — более глубокое и насыщенное звучание и хорошая передача верхов в режиме с hq.

Вот так. Поэтому пользуя ENCODER вы должны быть уверены, в том что он работает именно по алгоритму -hq. Так L3 producer pro из того же Фраунхоферского института НЕ ИСПОЛЬЗУЕТ -hq. Именно поэтому он работает быстрее (и звук получается хуже).

7. Как сжимать?

Я применяю следующую схему:

алгоритм MPEG1 (обычно выбирается автоматически для потока 44.1кГц);
слой 3 (Layer 3);
психоакустическая модель 2 (AT&T);
режим DUAL CHANNEL;
повышенное качество (ключ -hq);
степень сжатия 8 (160кбит/с или 160000 бит/c).

В этом случае на машине Pentium 250 MMX поток жмется с замедлением в 13.1 раза (в тринадцать раз, кто не понял!). То есть одно-часовой компакт будет зажиматься 13 часов. Но зато качество моих MP3 в сотни раз превышает качество любых слышанных мной Layer 3 — поделок. Не поддавайтесь на провокации! Не может пока упаковщик работать быстрее 13-кратного замедления при создании Layer 3 высшего качества. Если я встречу такой, я об этом сообщу обязательно. А пока:

степень сжатия больше 8 (меньше 160000 kbps) — плохо, потеря верхов; слой меньше 3 — плохо, потеря качества;
stereo, joint stereo — плохо, потеря существенной информации и искажения в аудио-потоке;
режим не hq (high quality — высшее качество) — плохо, маленький динамический диапазон;
психоакустическая модель не 2 (AT&T) — страшные искажения и хрюканье звука;
применение MMX, огрубляющих алгоритмов и эвристических алгоритмов искажения и изменение характера звучания.

Какие могут быть улучшения? Вот какие:

сначала у меня был Pentium-100 — замедление в 24 раза;
потом Pentium-133 — замедление в 21 раз;
Pentium-166 MMX — замедление в 17 раз;
Pentium-250 MMX — замедление в 13 раз...

Цепь рассуждений ясна?

Тачку нужно разгонять, проц. — Pentium II 333 даст только 5-кратное замедление (а то и меньше!), а Intel уже анонсирует Mercedes 900. Вывод такой: не гонитесь за скоростными упаковщиками — оденьте наушники и послушайте, что же у вас там со звуком творят. Ищите нормальный и медленный упаковщик с -hq и DUAL CHANNEL и не портьте музыку сомнительными MP3 заковыдерами.

Я не собираюсь дискутировать по этому поводу, я даю информацию, которая поможет тому, у кого есть голова. Уже сейчас я могу получить CD с 8-ю часами (точнее 74*8.61 = примерно 10ч 37мин) музыки с качеством НАСТОЯЩЕГО CD, а не те диски, которые навалом лежат на CD-рынке с интересными заголовками "все песни группы такой-то — полный MPEG3". Да, ребята, ваши диски действительно полный MPEG3, который так и не был разработан. Когда же наконец до всех дойдет, что есть Layer 3 аудио, а нет MPEG3 аудио?

8. Степени сжатия тоже требуют некоторого объяснения.

Приведу таблицу для потока 44.1 Кгц 16 бит Layer 3: Скорость сжатого потока (бит в секунду) — степень сжатия (раз)

32000 — 43.066
40000 — 34.453
48000 — 28.711
56000 — 24.609
64000 — 21.533
80000 — 17.227
96000 — 14.355
112000 — 12.305
128000 — 10.767
160000 — 8.613
192000 — 7.178
224000 — 6.152
256000 — 5.383
320000 — 4.307

Некоторые программы меряют степень сжатия в КИЛОБИТАХ В СЕКУНДУ (kbps/sec или просто kbps). Поясню на примере программы L3ENC, здесь для сжатия задается ключ -br (BIT RATE — битовая скорость):

br 160000 (сжать в 8.6 раз)
br 320000 (сжать в 4.3 раза)
br 96000 (сжать в 14.4 раза).

В программах с kbps будет так (например, l3producer pro):

160 kbps/s (сжать в 8.6 раз)
112 kbps/s (сжать в 12.3 раза)
и т.д.

Многие программы поддерживают не все указанные степени сжатия. Это проблемы разработчиков. По стандарту MPEG1,MPEG2 все указанные степени сжатия являются верными (и никакие другие, кроме перечисленных). В MPEG2.5 существует куча дополнительных степеней сжатия, но все они являются производными от указанной таблицы (т.е. число делится на кратный коэффициент 2, 4, 8 и т.д.).

9. В поток можно вставить вспомогательные данные (ancillary data), которые могут быть как текстом песен, так и авторским копирайтом.

Эти данные введены в первую очередь для защиты авторских прав: кто-то гоняет чужой MP3, говорит, что это его произведение, приходит автор и вытаскивает на свет божий файлец со своим сто раз повторенным именем прямо из MP3 (эта информация "размазывается" равномерно по всему файлу от начала и до конца), и "вора" уводят в темноту с руками за спину — за нарушение авторства. Хотя в принципе, почему бы не сделать так MP3->WAV и потом назад WAV->MP3? Кстати, боже вас упаси делать MP3->WAV через WinAmp! Только L3DEC и только самой последней версии (пока 2.74). То же самое касается и WAV->MP3. Найдите хороший и качественный (на ваш слух в наушниках) кодировщик и работайте только с ним.

10. В настоящий момент появился еще один кодировщик от Фраунхоферовцев.

Это Mpeg Encoder 3.0 demo (название EXE-файла MP3ENC.EXE). К сожалению он ограничен по времени (ограничение снято мной), не показывает справочной информации (тоже исправлено мной) и не поддерживает ключ -dual (который описывается в документации на него). Что нового в этой программе:

ключ -hq сменен ключом -qual [0..9].

Здесь такой расклад:

qual 0..3 — одинаковые и дают самое низкое качество (грубый алгоритм прямого ДКП);
qual 4..6 — одинаковые и дают среднее качество (точный алгоритм ПДКП);
qual 7..8 — одинаковые и дают высшее качество за счет динамической таблицы Хаффмана, увеличенного количества итераций усечения коэффициентов ДКП и увеличенной точности акустической модели (взято из документации).

Теперь распаковщик не делается — рекомендуется использовать l3dec от версии 2.74.
Что сказать? По скорости -qual 9 такой же медленный, как и -hq в старых версиях. По качеству явно хуже (где же у него dual channel?). Для нормального сравнения нужно сначала заполучить коммерческую версию с работающим ключом -dual.

11. Появилась новая версия программы MPEG encoder v0.07 от SoloH (http://www.isafeelin.org/soloh/mpegEnc.html).

Здесь есть большинство вещей, о которых я уже говорил:
две акустические модели;
режимы mono, stereo, joint-stereo и dual mono.
Недостатки:

медленный;
режим stereo и dual-mono начинают совпадать через несколько блоков, что говорит о хитрости или явном умысле автора или о его стремлении одурачить своих пользователей. Пример: сделайте два одинаковых файла mp3 из одного и того же wav, причем первый с режимом stereo, второй dual-mono. Сравните файлы MP3. Первые блоки различаются как небо и земля (так и должно быть!), но где-то с 10-го блока (а может и раньше — лень считать!) файлы начинают совпадать как близнецы (отличие только в одном байте заголовка блока — там где стоит режим: dual-mono или stereo). Это НЕХОРОШО и НЕЧЕСТНО, разработчик из SOLOH! Обманываешь потенциальных пользователей и просишь у них почтовые открытки к тому же (см. Файл readme.txt из этого пакета);
где у него ключ -hq?

Я не рекомендую использовать этот энкодер. Есть вариант — попросить автора сделать -hq и честный режим dual-mono. Я не хочу тратить на это время, может быть это сделаете Вы?

12. Пока все.

Статью подготовил Gene J.B.
E-mail: msw@iname.ru

Вернуться в раздел