Аудио MPEG, аудио не MPEG и не аудио MPEG(версия 2) |
(C) 1998 Олег Барабаш, г. Пенза
Здравствуйте, любители музыки (MP3) !
Прошу не править этот документ, за исключением орфографических ошибок. Используйте документ целиком, а не по частям. Для цитирования документа используйте настоящее название и имя автора. Передайте своим друзьям. Расскажите им о том, что здесь написано.
После прочтения вы огорчитесь, но не очень. 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!) для частоты сканирования аудио в два раза меньшей, чем обычно.
Выводы:
Таблица "правильных" стандартов:
| Стандарт | Видео | Аудио | Синхронизация |
|---|---|---|---|
| MPEG1 | MPEG1 | MPEG1 | MPEG1 (150 Кб/сек) 352 X 240 38,44.1,48 |
| MPEG2 | MPEG2 | MPEG1 | MPEG2 (300 Кб/сек) 720 X 520 38,44.1,48 |
| MPEG2.5 | нет | MPEG2.5 | нет MPEG2 LSF 16,22.05,24 |
| MPEG3 | нет | нет | нет |
| MPEG4 | MPEG4 | ????? | MPEG4 (1200 Кб/сек???) |
3. Каждый стандарт содержит несколько частей. В основном это такие части:
Звездочкой отмечен пункт, доступность (или значимость) которого для нас с вами практически на нуле. Например, мне удалось нарыть некоторые исходники, но по сравнению с ними все самые тормозные кодеры WAV->MP3 намного быстрее.
4. Нас интересует часть MPEG, относящаяся к аудио. Фактически здесь определено несколько слоев качества (Layer - слой). Они так же нумеруются:
В стандарте под номер слоя отведено 2 бита, поэтому и слоев может быть только 4. Опишу слои по порядку:
Самая первая разработка. Позволяет сжимать аудио в 3..12 раз. Качество CD сохраняется при степени сжатия не более 4-х раз. Именно этот слой стал родоначальником всех следующих, причем именно он лежит в основе системы сжатия мини-дисков SONY. В общем, это дерьмо. Любой файл, сжатый с помощью такого слоя теоретически должен иметь расширение MP1. Суть алгоритма сжатия:
Суть алгоритма декодирования:
Алгоритм сжатия - медленный (в основном за счет просчета акустической модели и итеративного усечения коэффициентов). Алгоритм декодирования - быстрый (может быть реализован в реальном времени).
В связи с низким качеством первого слоя математики приступили к его оптимизации. После уточнения множества специальных таблиц, введения тройного гребенчатого фильтра в модель первого слоя родился 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.
Никому не известная в 1992 (да, наверное и до 1998 года) фирма IIS Fraunhofer (институт имени Фраунхофера) совершает научный прорыв: если мы получили коэффициенты прямого дискретного косинусного преобразования, то почему бы не использовать эту же процедуру еще разок на этих же коэффициентах? Они попробовали сначала в лоб - произвели преобразования второй раз вдоль коэффициентов. Результат - ноль. Тогда какой-то немецкий непризнанный гений решил посмотреть на проблему в лежачем положении: он разделил коэффициенты на три связки (то есть первая связка - 1-й,4-й,7-й и т.д. коэффициент; вторая связка 2-й, 5-й, 8-й и т.д коэффициент; третья связка 3-й, 6-й, 9-й коэффициент и т.д.), проделал еще одно дискретное косинусное преобразование по отдельности на этих связках, подкорректировал алгоритм декодирования - и открытие состоялось: при той же степени сжатия качество выросло в 4 раза! Начались эксперименты, в ходе которых было выявлено следующее:
В совокупности Layer 3 получился качественным и медленным. Мало того, необходимо было опять переделать и усложнить психоакустические модели и добавить некоторые элементы архивации по фиксированной таблице Хаффмана (это тот алгоритм, что используется в архиваторе ARJ, только в ARJ эта таблица динамическая и постоянно изменяется, что требует два прохода по данным; При фиксированной таблице сжатие происходит за один проход).
Все выше перечисленные изменения вылились вот во что:
Что, страшно?
Фирма 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 (до сих пор эталон качества воспроизведения). Но деньги любят счет:
В Америке студент Джефф Цей (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. Проверка простая:
Результат:
Что касается WINAMP, то они сделали HQ-режим, 32-битный и 64-битный (интересно, как?) режимы, но времени сравнивать их с L3DEC не было. Поэтому если там все в порядке, тогда я сниму перед WinAMP шляпу. А пока - единственный вариант правильной распаковки MP3 в WAV:
l3dec in.mp3 out.wav -wav
А пока WINAMP со всеми его скинами и плугинами для меня лично ноль. MAPLAY от Jeff Tsay идет с исходниками, поэтому я подработал его на предмет уровней громкости и общего оформления, на предмет открытия множества файлов, реалтайм приоритета и расслабился. Возможности MAPLAY:
Теперь дело об упаковщиках. Фраунхоферовцы выпускают 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? Нет, этот ключ не задавать - себя не уважать! Сравниваем:
(Между прочим слушаю это в наушниках Philips, а не через колонки).
Може MMX чудит? Берем дебагер, ищем коды команд MMX... Батюшки! Робяты! И здесь обманули - нету ни в RJPAENC, ни в TOMPG ни одной, ни единой команды MMX! А как же с увеличением производительности на 33%? Теперь понятно. Это мыло и прикол. Никаких MMX, никаких ускорений... Нафига ускоренный запорожец без колес? Испоганеный алгоритм прямого ДКП - вот и все ускорение.
Вот что я скажу. После многократного тестирования разных поделок/подделок по L3 кодированию можно сделать один вывод:
лучший выбор l3enc my.wav my.mp3 -hq -crc -br 160000 (это в специальной "заказной" версии l3enc!)
Даже L3producer гораздо хуже.
Пока только в туманном будущем. Хотя, может в недрах у немцев уже начинают шариться файлы 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 слоя (пока). Значит будут уместны такие выражения:
На самом деле пока разработаны следующие сочетания:
Как узнать, какой MPEG, если расширения файлов одинаковы? В заголовке блока любого упакованного аудио-файла эта информация всегда есть (кодируется двумя битами). Например, программа MAPLAY (о ней я не раз уже говорил) в пункте меню Audio Properties всегда показывает точный номер стандарта. Иногда стандарты нумеруются нестандартно (простите за игру слов):
6. Теперь о САМОМ ПЛОХОМ. Качество зависит еще от трех параметров.
А). Я уже упоминал психоакустическую модель. В настоящий момент известно две такие модели:
Б). Режим сжатия:
Режим 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 невозможно. Исходить можно только из следующих посылок:
Вот так. Поэтому пользуя ENCODER вы должны быть уверены, в том что он работает именно по алгоритму -hq. Так L3 producer pro из того же Фраунхоферского института НЕ ИСПОЛЬЗУЕТ -hq. Именно поэтому он работает быстрее (и звук получается хуже).
7. Как сжимать? Я применяю следующую схему:
В этом случае на машине Pentium 250 MMX поток жмется с замедлением в 13.1 раза (в тринадцать раз, кто не понял!). То есть одно-часовой компакт будет зажиматься 13 часов. Но зато качество моих MP3 в сотни раз превышает качество любых слышанных мной Layer 3 - поделок. Не поддавайтесь на провокации! Не может пока упаковщик работать быстрее 13-кратного замедления при создании Layer 3 высшего качества. Если я встречу такой, я об этом сообщу обязательно. А пока:
Какие могут быть улучшения? Вот какие:
Цепь рассуждений ясна?
Тачку нужно разгонять, проц. - 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 - битовая скорость):
В программах с kbps будет так (например, l3producer pro):
Многие программы поддерживают не все указанные степени сжатия. Это проблемы разработчиков. По стандарту 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 (который описывается в документации на него). Что нового в этой программе:
Здесь такой расклад:
Теперь распаковщик не делается - рекомендуется использовать l3dec от версии 2.74.
Что сказать? По скорости -qual 9 такой же медленный, как и -hq в старых версиях. По качеству явно хуже (где же у него dual channel?). Для нормального сравнения нужно сначала заполучить коммерческую версию с работающим ключом -dual.
11. Появилась новая версия программы MPEG encoder v0.07 от SoloH (http://www.isafeelin.org/soloh/mpegEnc.html). Здесь есть большинство вещей, о которых я уже говорил:
Недостатки:
Я не рекомендую использовать этот энкодер. Есть вариант - попросить автора сделать -hq и честный режим dual-mono. Я не хочу тратить на это время, может быть это сделаете Вы?
12. Пока все. Если будет реакция. Брошу некоторые свои MP3 для всеобщего обозрения.