Audiophile's Blog
Логин:Пароль:


Забыл пароль | Регистрация (убрать всю рекламу)
О сайте | Ликбез | Словарь | Audiophile's Testroom | Поддержать | Контакты
Разделы
Поиск по сайту
Популярное
Персональная настройка
Настройка звука онлайн (foobar2000, драйвера, Windows), создание персональных сборок foobar2000.

Контакты

Случайный опрос
Какая у вас звуковая карта?
Всего ответов: 2580
Полезный софт
Opera QIP 2010 Download Master µTorrent
Ace Utilities AIDA64 SpeedFan 7-Zip
ESET NOD32 FileZilla Media Player Classic Home Cinema Paint.NET
Sony Sound Forge VirtualDub Unlocker Punto Switcher
Похожие проекты
Сейчас на сайте
Онлайн всего: 12
Гостей: 12
Пользователей: 0
»

Многократное кодирование: исследование lossy кодеров


07 Декабря 2014, 21:39

Несколько лет назад на Habrahabr'е был опубликован весьма интересный по своей идее тест, заключавшийся в проверке качества кодеров путём многократного перекодирования трека одним и тем же кодером.

Само собой, эта методика тестирования качества не выдерживает никакой критики, и на основе результатов такого кодирования делать выводы непосредственно о качестве кодера нельзя (хотя бы потому, что он здесь применяется в условиях нестандартных, крайне далёких от реальных). Однако, как я уже сказал, сама идея интересна, чисто с исследовательской точки зрения.

Сегодня я хотел бы несколько доработать и расширить этот тест, а также всё-таки попытаться сделать на его основе какие-то выводы.

Прежде всего я решил исключить из теста влияние конечной разрядности, и для декодирования стал применять не LAME с выходом 16-bit PCM, а декодер mpg123 с 24-битным выходом. Также я отрегулировал громкость входного файла так, чтобы в процессе перекодировки она не превысила 100%, так как фактически LAME с плавающей точкой на входе работать не умеет (выполняется преобразование в фиксированную).

Другим отличием моей методики является то, что я сохраняю все промежуточные файлы кодирования, чтобы затем иметь возможность оценить динамику изменения параметров.

Методика

Итак, вот мой доработанный bat-файл кодирования:

@copy /Y %1 ~temp.wav
@for /L %%i in (1,1,%2) do @(
@echo -------------------------------------------------------------------------------
@echo -- Iteration %%i
@echo -------------------------------------------------------------------------------
lame %3 -q 2 --noreplaygain ~temp.wav -o ~temp%%i.mp3
mpg123 -e s24 --wav ~temp.wav ~temp%%i.mp3
)
@del ~temp.wav
pause

Строка запуска выглядит так:

mp3_xcode test.wav 100 "-b320"

То есть, мы запускаем кодирование тестового файла LAME с заданными параметрами (в примере указан VBR V2), затем декодируем его (с помощью декодера pg123) обратно в 24-bit PCM WAV, снова кодируем в LAME и т. д., заданное количество раз. Все полученные MP3 файлы сохраняются под своим номером.

Для теста я выбрал фрагмент композиции Mark Knopfler — Baloney Again (Sailing to Philadelphia, 2000) в формате 24 бит 48 кГц. Во избежание клиппинга я занизил уровень громкости на 3 дБ (0.707).

После кодирования я выполняю анализ таких параметров как пиковый уровень и средний битрейт (для VBR) каждого файла, а также выполняю слепую оценку качества отдельных образцов в ABC HR:

Затем все полученные данные анализируются в Excel.

Тестирование MP3

Я провёл эксперимент в трёх режимах — 128 kbps CBR q2, VBR V2, 320 kbps CBR q2, с использованием LAME 3.99.5. Количество итераций — 100. Значение параметра -q равное двум выбрано по той причине, что при нулевом скорость кодирования становится невероятно низкой, а слышимого прироста качества это не даёт (в прошлом доказано слепыми тестами).

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

Весьма любопытно: уровень MP3 128 kbps по мере перекодирования затухает строго по экспоненте (подтверждается аппроксимацией в Excel). Уровень VBR V2 меняется в обе стороны, пока к 15-й итерации не устанавливается на фиксированном значении (примерно на 0.5 дБ выше исходного). CBR 320 ведёт себя довольно странно, со скачком после 70-й итерации.

Здесь мы снова видим отсутствие особо значимых изменений после 15-й – 20-й итерации.

Ну и конечно, что нас наиболее интересует — субъективная оценка качества. Для CBR 320 качество затухает уже начиная с 3-го прохода, приблизительно по экспоненте, опускаясь до уровня 1 (очень неприятные искажения) примерно на 70-м проходе.

Для CBR 128 качество затухает также по экспоненте, но очень и очень быстро, причем с каждым проходом полезный сигнал подавляется всё больше и больше — что мы и видели на графике уровня — к восьмому проходу остаются практически одни артефакты.

Не менее интересно ведёт себя модель VBR. Мы видим затухание по экспоненте, достигающее уровня 2 (неприятные искажения) к 10-му проходу, после чего на протяжении последующих 90 проходов аудио контент фактически остаётся неизменным, как и пиковый уровень на графике выше.

Создаётся впечатление, будто к 10-му проходу психоакустическая модель VBR выбросила из сигнала всё, что могла, и более делать ей с сигналом нечего. Это во многом напоминает понятие собственной функции в математике (например, для оператора дифференцирования это экспонента), т. е. фактически после десятого прохода мы получаем собственную функцию оператора кодирования, на которую он совершенно не может повлиять.

К сожалению, о причинах такого поведения кодера без глубоких познаний в области функционирования алгоритмов судить сложно. Однако я обязательно вынесу этот вопрос на рассмотрение в одной из тем HydrogenAudio.

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

Кодирование Vorbis, AAC, Opus

Я слегка модифицировал bat-файлы для использования с кодерами и декодерами других форматов. Привожу строки, используемые мною для кодирования /декодирования:

qaac 2.44 (CoreAudioToolbox 7.9.9.3)
qaac -V90
qaac -D

Oggenc2 libvorbis 1.3.4 / Oggdec 1.10.1
oggenc2 -b 192
oggdec -b 5

Opus 1.1
opusenc -b 192
opusdec --float


Таким образом, все файлы кодировались-декодировались в формате с плавающей точкой.

Vorbis

У Vorbis наблюдается практически линейное затухание качества параллельно с ростом артефактов и шумовых составляющих. Артефакты становятся слышны уже на втором проходе, к 12-й итерации качество достигает наименьшего значения на шкале субъективной оценки, однако продолжает и далее стабильно ухудшаться. Рост уровня искажений также отражается и на графике пикового уровня — peak level возрастает по экспоненте.

По результатам можно сделать предположение, что Vorbis стабильно подмешивает к сигналу некоторый уровень шума.

Opus

У Opus ситуация лучше: до 8-го прохода звучание неотличимо от оригинала, далее постепенно начинают появляться призвуки, похожие на постукивание, с фазовым сдвигом между каналами. Качество уменьшается по логарифмическому закону и к 100-му проходу его субъективный уровень достигает 1.5 балла. Пока это наилучший результат.

Битрейт имеет тенденцию к линейному уменьшению, пиковый уровень ведёт себя довольно странно, с изменением в обе стороны до 35-го прохода и со скачком после 90-го прохода.

AAC

В сравнении с другими кодерами QAAC демонстрирует потрясающие результаты: его параметры по мере перекодирования практически не изменяются, а главное — качество неотличимо от оригинала даже после сотого прохода.

Выводы

Что ж, в данном случае мы можем оценить только тенденцию, и только на основе её оценки можно строить какие-то догадки. Прежде всего, в тесте наиболее сильно проявились те самые специфические шумы Vorbis, которые иногда проявляются на сложных киллер-семплах. Как я уже сказал, можно предположить, что кодер Vorbis при каждом кодировании, вне зависимости от контента, подмешивает к нему некий шум. Об этом говорит стабильное возрастание пикового уровня, битрейта и вообще мощности искажений: к сигналу подмешивается шум, его амплитуда и энтропия возрастает.

Касаемо MP3 можно заключить, что в режиме CBR, особенно на низком битрейте, он имеет тенденцию к подавлению полезного сигнала — постепенно отбрасывая его спектральные составляющие; в итоге остаются одни артефакты. В режиме 320 kbps кодер показал относительно неплохие результаты, а в режиме VBR мы увидели нечто вроде адаптивного кодирования: к сигналу явно ничто не подмешивалось, после того как психоакустическая модель несколько раз обработала файл, далее отбрасывать какие-либо составляющие она отказывается: качество, битрейт и пиковый уровень остаются стабильными.

Хороший результат показал Opus, качество которого, в отличие от других кодеров, уменьшается не по экспоненциальному, а по логарифмическому закону. Однако у Opus, похоже, проявились некоторые недостатки стерео-кодирования, впрочем это лишь догадки.

Ну и по-настоящему впечатляющие результаты показал QuickTime AAC: он явно работает в исключительно адаптивном режиме, не подмешивая (по крайней мере, без надобности) к сигналу никаких шумов, и вообще не внося в него даже по прохождении 100 проходов никаких существенных изменений.

Как бы там ни было, о чем-то результаты проведенного сегодня теста всё же говорят. Для более точных выводов следует обратиться к экспертам, имеющим дело непосредственно с написанием алгоритмов кодирования, что я и постараюсь сделать в ближайшее время.


Информация от спонсора

PROMATE: технологии твоего стиля. Здесь http://promate-rus.com/smartphone-fashion/i-phone-6.html Вы можете приобрести аксессуары для iPhone 6: металлические, кожаные и другие чехлы. К каждому чехлу — защита для экрана в подарок.

 
   
Просмотров: 5109 | Автор: | Добавил: Audiophile () | Рейтинг: 5.0/5, голосов: 9
Всего комментариев: 17
[17] andreiaga73   (06 Декабря 2015 21:31)
Провел тест lossyWAV 1.4.0 / FLAC 1.3.1 (перекодировал Flac в LossyFlac) вот такой bat-ничек: @echo off
if NOT "%1" == "" ( flac -d "%1" --stdout --silent|lossywav - --stdout -q 7.8 --stdinname "%1"|flac --ignore-chunk-sizes - -b 512 -8  -o "%~dpn1.lossy.flac" && metaflac.exe --export-tags-to=%1.xml "%1" && metaflac.exe --import-tags-from=%1.xml "%~dpn1.lossy.flac"
del "%1"
del "%1.xml"
exit/b
)ELSE (
for %%i in (*.flac) do call %0 %%i)
)

track gain +39.72 dB по приведенной в статье методике - ни один из lossy кодеков на самых высоких настройках не дал даже близкого результата. (OGG q 10 +31.14 dB).Звук абсолютно прозрачен. Размер файлов сопоставим. Вывод: чистые lossy кодеки отживают свое время (относится ко всем, а не только к mp3).

/в папке с bat-ником:flac.exe, lossyWAV.exe, metaflac.exe, libfftw3-3.dll./ имя *.flac файла не должно содержать пробелов, запятых, и скобок().
Деградирование аудио на 28 проходе нет track gain +38.05 dB.

[16] j7n   (23 Марта 2015 17:19)
Понижение громкости при кодировки с LAME намерено, чтобы снизить вероятность клиппинга после того как учесть не точность формата. (Что есть хорошо при нормальной работе.) Множитель уровня становится меншьше с битрейтом < 256 кбит/с. При 128 он равен 0.95. Компенсировать параметром --scale точно мне не удалось, так как 1/0.95 не ровное число. Полагаю изменение уровня по себе отрыцательно сказывается на качество, и увеличивает шансы что кодек будет отбрасывать уже другие части спектра, чем на предыдущем проходе.
AAC удивил. Так он почти нарушает законы физики. Но всё-таки не люблю Apple. Другие форматы удобнее, и без "спама" в тегах.

[15] DjMyas   (10 Февраля 2015 09:53)
Я всегда подозревал, что AAC очень хороший кодер. Я уж лучше куплю на Apple песню в формате AAC с переменным битрейтом 256, чем буду скачивать mp3 320 CBR, потому что неизвестно сколько раз до этого файл пережимался.

[14] Eol3000   (13 Декабря 2014 13:23)
Добрый день всем!
Спасибо за статью.
Тоже решил развить данную идею и провёл тест почти co всеми из имеющихся у меня lossy кодеков. В качестве семпла взял отрывок из Snap - The Power, довольно извстный трек 90 года. Не совсем понял идею раскодировать в 24 битный формат, поэтому ограничился обычным декодированием в wav. Вот результаты при 100 проходах:
mp3 - Кодер Fhg оказался ожидаемо хуже Lame при 320 kbps. При 128 у lame почему то упала громкость до минимума. После нормализации результат оказался не настолько плох, как у некоторых других кодеков, как впрочем и у fhg. V0 у lame выдал похожий на 320 результат.
vorbis - при q10 идентичные результаты у aotuv и референсного кодера. При q1 aotuv ожидаемо лучше.
aac - использовал кодер Nero. Не люблю продукцию Apple и избегаю её даже в таких мелочах.) При q1 также выдал результат, мало отличающийся от оригинала. При q0.3 lc появились свистящие призвуки.
ac3 (кодер ffmpeg) - оказался ещё более устойчивым к перекодированию, чем aac. Выдал при 320 и 128 весьма сносные результаты.
mp2 (кодер twolame) - вы таки будете смеяться, но при 320 особых артефактов нету. Результат даже лучший, чем у vorbis. Зато 128 слушать невозможно, сплошной свист.
mpc - в предустановке insane вообще не услышал никаких искажений. Повторил тест в 300 проходов - вроде что то появилось, но малозаметно. В предустановке thumb результат похож на mp2 при 128. Подтверждается их родство.
optimfrog dualstream - при q0 выдал очень интересный результат. Громкость заметно повысилась и при воспроизведении хаотично скачет из одного канала в другой, создавая стереоэффект. Ещё немного шума добавилось.
opus - удивил. При 256 появились артефакты в виде постукивания. Но при 80 этих артефактов нет!
speex - подтвердил своё предназначение.) при quality 10 музыка превратилась в нечто неузнаваемо булькающее, но вот вопль "I Got The Power!" слышен вполне отчётливо, хоть и искажённо.)
wavpack при b2 - ужасный результат, сплошной шум, хотя музыка всё же слышна.
Если кому интересно - тут лежат все семплы: https://yadi.sk/d/sc73Qrv7dLvwf

+1   Спам
[10] User   (11 Декабря 2014 04:43)
Надо MusePack добавить, раз тест проводится на средних-высоких битрейтах. Интересно посмотреть, что у него получится.

[8] Dave_Scream   (10 Декабря 2014 13:50)
Мне ещё интересно у ААС bit идентичный результат каждый проход получался?

0  
[9] Audiophile   (10 Декабря 2014 16:06)
Нет конечно. Если присмотреться, и битрейт слегка гуляет.

[4] alter4   (10 Декабря 2014 00:09)
Непонятно за что обижатся? В жизни таких условий никогда не будет, я протестировал opus дома, правда тестировал 1.1.1-beta версию, и результат не так уж плох на мой слух, судите сами выложил 1й и 70й проход. Завтра потестирую на более низких битрейтах AAC.

Код
@copy /Y %1 ~temp.wav
@for /L %%i in (1,1,%2) do @(
@echo -------------------------------------------------------------------------------
@echo -- Iteration %%i
@echo -------------------------------------------------------------------------------
opusenc --bitrate 192  ~temp.wav ~temp%%i.opus   
opusdec --float ~temp%%i.opus ~temp.wav
)
@del ~temp.wav
pause

забираем результаты отсюда

[3] Shuld   (09 Декабря 2014 19:16)
Исследование не закончено!
Рано делать выводы!
Для полноты картины желательно проверить
qaac -V63
Требуем продолжения эксперимента!

0  
[5] Audiophile   (10 Декабря 2014 00:17)
зачем? чем так знаменательно это значение?

кодеры сравнивлись на битрейте около 200 кбит/с

0  
[6] Audiophile   (10 Декабря 2014 00:21)
зачем? чем так знаменательно это значение?

кодеры сравнивались на битрейте около 200 кбит/с

[13] Shuld   (13 Декабря 2014 06:34)
1. Дело не в конкретном значении -V63 (которое близко к 128 кб/с), а в принципе:
будет ли AAC стабильно на другом битрейте, может быть через 10 циклов тоже деградирует?

2. Кстати, а mpc?

[2] zub35   (09 Декабря 2014 18:00)
Нашелся все таки изъян у Opus'a, пускай не столь серьезный как у других, но все-же изъян, в пользу AAC.

И сразу вопрос: справедливо ли будет делать вывод, что постепенное понижение битрейта для AAC в 100 проходов, будет равносильно по качеству, сжатию оригинала сразу в нижнею планку?

0  
[7] Audiophile   (10 Декабря 2014 00:22)
Неправильно это называть изъяном. Просто особенность, которая однако никак не влияет на нормальное кодирование.

[11] User   (11 Декабря 2014 04:46)
С другой стороны - тебе понадобится over 9000 раз транскодировать lossy? Максимум - один раз и только из-за того, что не смог найти или не существует в природе lossless вариант.

+3   Спам
[1] Dave_Scream   (08 Декабря 2014 22:40)
Интересное исследование. За OPUS обидно :( не люблю AAC за то, что он платный.

[12] User   (11 Декабря 2014 04:50)
Мне казалось, что для личного прослушивания - бесплатен. Другое дело, когда используешь его в коммерческих проектах - там всё равно будет использоваться Vorbis т.к. есть библиотеки для его использования в разных средах программирования. В любом случаи нужно всячески избегать lossy транскода, путём закачки lossless'ов.

Добавлять комментарии могут только зарегистрированные пользователи.
[ Регистрация | Вход ]
Авторские статьи
Сообщество
Последнее на форуме
Кодеки
TAK FLAC APE WV
MPC OGG AAC/ALAC MP3
WMA TTA OFR LA
Теги
Follow me
Twitter YouTube
Google+ Facebook
Полезные ссылки
Copyright Taras Kovrijenko © 2009–2016