Я хотел бы рассмотреть и послушать MQA. В идеале кодирование и декодирование тестового сигнала в MQA стало бы самым приемлемым вариантом для изучения всех эффектов и понимания, как все это работает. Но поскольку программный код охраняется правом собственности, все, что мы можем сделать — это исследовать эффект, оказываемый MQA на сам аудиосигнал.
У меня нет ЦАПа, способного работать с MQA-кодеком (и, честно говоря, желание обладать им не занимает верхние строчки в списке моих приоритетов), но так сложилось, что у моего друга оказался ЦАП Mytek Brooklyn, который имеет нативную поддержку MQA и способен декодировать аудио с разрешением вплоть до 24 бит/384 кГц. К тому же в его распоряжении находится профессиональный АЦП фантастического качества — аудиоинтерфейс RME Fireface.
Имея на руках отличные ЦАП и АЦП, мы сможем провести некоторые сравнения. Главные вопросы, которые нас интересуют:
1. Будет ли декодированный ЦАПом MQA близок к исходному сигналу с частотой дискретизации свыше 88/96 кГц?
2. Можно ли сравнить результаты выходов «железного» и софтового декодера MQA? Какая между ними разница?
Методика
Чтобы объективно оценить декодирование MQA, мы должны начать с оригинала, обладающего «истинным» высоким разрешением — с ультразвуковым содержимым и низким уровнем шума. Этот же файл должен быть доступен и на сервисе TIDAL, чтобы у нас была возможность сравнить его с софтовым декодированием. Для «захвата» звука мы прогоним его через ЦАП и запишем трек в исходном разрешении. Затем запишем результат программного декодирования интерфейса TIDAL. И, наконец, запишем выхлоп ЦАПа в режиме «полного» MQA-декодирования.
В соответствии с этими требованиями мы с другом решили использовать трек «Blågutten» с альбома группы Hoff Ensemble «Quiet Winter Night», взятый на демо-странице лейбла 2L. Как видно из таблицы описания, оригинальный файл доступен в формате DXD (24 бит/352,8 кГц) и представляет собой «наиболее прозрачное» разрешение для ЦАПа. Напомню, что подобный метод был задействован в прошлом году, когда я обозревал ЦАП Meridian Explorer 2. Тем не менее, есть несколько замечаний:
1. АЦП RME Fireface 802, используемый для захвата выходного сигнала ЦАПа, позволяет записать файл с максимальным разрешением в 24 бит/192 кГц. Поэтому, несмотря на то, что мы можем проигрывать формат DXD с оригинальным исходным разрешением в 24 бит/352 кГц и обеспечивать аппаратное MQA-декодирование с таким же заявленным разрешением с помощью Mytek Brooklyn, все сравнения будут выполняться при максимальной частоте дискретизации в 192 кГц.
2. Измерения были сняты с балансных выходов Brooklyn с целью обеспечения наименьшего уровня шума и наилучшего разрешения. Чтобы не перегрузить АЦП, напряжение на XLR-выходе ЦАПа Brooklyn было выставлено в + 4 В, а громкость в –5 дБ. На АЦП Fireface чувствительность для входа XLR была установлена на отметке в +4 дБ. См. настройки ниже:
Эти настройки позволили снизить максимальную амплитуду до ~1,9 дБ, чтобы обеспечить отсутствие клиппинга при записи тестового сигнала 0 dBFS:
Результаты
В отличие от моего предыдущего теста, сравнивающего Hi-Res файлы с MQA-декодированием на TIDAL, полученным непосредственно из цифрового рипа, не забывайте, что эти результаты зависят от качества использованной связки ЦАП/АЦП. Вот почему я потратил время на приведенное выше описание методики проведения сравнения. По сути, сигнал в некоторой степени покажет ограничения процесса ЦАП/АЦП, включая характеристики уровня шума, которые я попытаюсь указать там, где могу.
Чтобы ответить на вышеизложенные вопросы, я собираюсь начать с нескольких сравнений между 4-мя образцами:
A. ЦАП Brooklyn, воспроизводящий оригинальный DXD-трек (24 бит/352,8 кГц), — «референс».
B. ЦАП Brooklyn, воспроизводящий MQA-поток, декодированный интерфейсом сервиса TIDAL, — «софтовый MQA».
C. ЦАП Brooklyn, использующий при воспроизведении встроенный декодер MQA, — «железный MQA».
D. ЦАП Brooklyn, использующий при проигрывании декодирование Tidal, а затем собственный декодер MQA — «софтово-железный MQA».
Обратите внимание на образец D. Согласно словам моего друга, ЦАП Brooklyn распознает частично декодированную версию в 88 кГц от TIDAL (рекламные тексты MQA называют это выходом «MQA Core» (MQA-ядра) и затем займется ее декодированием, а также, вероятно, проведет внутренний апсемплинг до 24 бит/352,8 кГц. Во время выполнения этого преобразования индикатор MQA в «Бруклине» горит красным цветом (в обычном стандартном режиме — это зеленый или синий).
Давайте попробуем ответить сразу на несколько вопросов. Отметим, что я прослушал каждый трек и уже имел свои собственные субъективные впечатления. Но чтобы вы действительно могли объективно оценить услышанное, запустим специальную утилиту Audio DiffMaker для каждого сравнения (чтобы наглядно показать, в чем заключается «остаточная» разница в первые 30 секунд воспроизведения музыки). Предполагаю, только таким образом можно понять сходство и различие в звучании, даже если вы собираетесь послушать это сугубо для себя.
Здесь представлены настройки, используемые в DiffMaker для записи — в основном это заданные по умолчанию параметры:
1. В чем состоят отличия между воспроизведением «референсной записи» и «софтового MQA» сервиса TIDAL?
Здесь представлена диаграмма спектра частот с этими «отличиями»:
На диаграмме спектра частот видно, что разница в области, находящейся ниже отметки в 60 кГц, минимальна! Все это указывает на то, что MQA действительно «работает», как о нем говорится в рекламе, и обеспечивает до определенного предела Hi-Res вывод из MQA-файла. Еще более интересным является то, что амплитуда разницы между фактическим воспроизведением DXD и программным MQA-декодированием в среднем колеблется в районе -70 дБ RMS! Причем этот уровень расхождения низок, особенно учитывая, что большая его часть — просто ультразвуковой шум выше 60 кГц!
К этому моменту, надеюсь, мы все придем к выводу, что шум свыше 60 кГц не желателен, но и не слышен, поэтому вернусь к нему чуть позже. А пока проигнорируем этот ультразвуковой шум и выполним даунсемплинг файла с частотой дискретизации в 192 кГц до 96 кГц (с помощью софта iZotope RX 5), чтобы увидеть, насколько хороши частоты до «нулевых» 48 кГц:
Ниже 48 кГц особой разницы между «референсной записью» DXD и «программным MQA» TIDAL не существует. Даже самый громкий семпл с разницей в звучании понижается до -70 дБ и в течение 30 секунд сбрасывается до среднего значения около - 90 дБ!
Для полной картины позвольте мне показать, как выглядели бы эквивалентные результаты диаграммы/амплитуды, если бы мы пропустили эту референсную запись через MP3-кодировщик (LAME 3.99, 320 кбит/с) и сравнили с эталоном:
Очевидно, что MP3-версия менее точна по сравнению с MQA-декодированием, показанным выше. Я верю тем, кто участвовал в слепых тестах-прослушиваниях (подобных тем, что мы проводили несколько лет назад) и считает, что MP3-кодирование с помощью LAME в битрейте 320 кбит/с для подавляющего большинства людей показалось более «прозрачным» по сравнению с lossless-файлом в разрешении 16 бит/44 кГц. По сравнению с «программным MQA»-декодированием, разница составляет целых 15 дБ, представленные разницей в средней RMS-мощности в «нулевом» файле (помните, что шкала децибел (дБ) — логарифмическая).
Все эти манипуляции служат доказательством того, насколько «тонким» может быть различие. Если это все, что вы запомните из данного блог-поста, этого может оказаться вполне достаточно.
2. В чем состоят отличия между воспроизведением «референсной записи» и «железного MQA» с потокового сервиса TIDAL?
Снова ничего, кроме шума выше 60 кГц, поэтому давайте обратим внимание на то, что происходит в области до 48 кГц:
Диаграмма спектра частот показывает, что в действительности аппаратное декодирование на выходе даже в «меньшей степени отличается», чем рассмотренная выше программная обработка. Имеет место быть аналогичное снижение в показателях RMS-мощности, рассчитанное для этого «нулевого» файла приблизительно в среднем на 6-7 дБ ниже. Очень впечатляюще! Это хороший знак, указывающий на то, что аппаратный способ действительно добавляет больше «точности» в декодирование, по крайней мере, в области аудиочастот до 48 кГц.
3. Как насчет гибридного «софтово-железного MQA»?
Здесь первый шаг в декодировании выполняется с помощью TIDAL до 24 бит/88 кГц, а затем Mytek Brooklyn декодирует все полностью аппаратным способом до DXD.
Как я и упоминал выше, есть интересный вариант (опция) декодирования, использующий сначала программное декодирование TIDAL (MQA Core), а затем ЦАП Brooklyn. По аналогии с тем, что уже сделано выше, начнем с диаграммы спектра частот, показывающей разницу при использовании записи с полным разрешением в 24 бит/192 кГц:
И снова мы получили только шум выше 60 кГц, поэтому сейчас сфокусируемся на разнице в области до 48 кГц с файлом в разрешении 24 бит/96 кГц, полученным в результате высококачественного даунсемплинга с помощью iZotope RX 5.
Если сравнить результаты по RMS-мощности, то чисто «железное MQA-декодирование» с помощью ЦАПа Brooklyn демонстрирует чуть более низкие показатели (т.е. более «точные»). Если учесть, что мы пропускаем тестовый сигнал через ЦАП/АЦП, то эта маленькая разница оказывает незначительное влияние, и комбинированное «софтово-железное MQA-декодирование» по сути идентично в плане качества «железному MQA-декодированию» (на что указывают полученные результаты измерений).
4. Если существует разница между «аппаратным MQA» и «софтовым MQA», можно ли сравнить их в частотной области?
Безусловно. Предположим, что мы рассматриваем одну и ту же точку в музыкальном треке примерно через 9 секунд после его начала (там имеется пик сигнала, что облегчает мне установку маркера с точностью в миллисекунду), тогда FFT (быстрое преобразование Фурье, БПФ) частоты выглядит, как «разница» на графике. Это оригинальная запись с помощью Fireface (24 бит/192 кГц), а не файл «разницы», обработанный DiffMaker'ом:
Итак, что мы видим?
Желтая линия графика представляет собой оригинальный «референсный» DXD-файл из 2L, который, как я предполагаю, был передан MQA-издателям. В зеленом цвете у нас «софтовое MQA-декодирование» TIDAL, которое, как известно, «разворачивается» только до частоты семплирования в 88 кГц. Следовательно, начиная от ~ 44 кГц в FFT, оно соответствует уровню шума АЦП. Интересно, что до 43 кГц или около того программное декодирование, по-видимому, является самым близким по отношению к DXD-оригиналу, но это происходит всего лишь в определенное мгновение времени и не распространяется на весь трек.
Фиолетовая и голубая линии являются аппаратными опциями декодирования. Они используют декодер Mytek Brooklyn либо с применением прямого «железного MQA», либо, соответственно, «софтово-железного MQA». При последнем сначала используется программное декодирование сервиса TIDAL до 88 кГц. Действительно, обе линии имеют некоторое дополнительное пространство над графиком «софтового» декодирования TIDAL вплоть до 75 кГц, когда я проигрываю запись и мониторю ее в режиме реального времени. Однако интерес вызывает несовпадение ультразвукового сигнала по уровню с «референсным» DXD, загруженным из 2L.
Обратите внимание: начиная примерно с 60 кГц и выше, «референсный» сигнал обладает немного большим уровнем шума, чем аппаратные версии MQA-декодирования. Это источник всех высокочастотных помех при каждом сравнении (который я отфильтровываю с помощью даунсемплинга до 24 бит/96 кГц).
Существует несколько возможных причин, объясняющих, откуда берется весь этот шум выше 60 кГц. Во-первых, вполне возможно, что DXD-файл, загруженный из сайта 2L, не является тем же самым источником, который используется в MQA-кодированной версии. Во-вторых, MQA-процесс фильтрует ультразвуковой шум при кодировке или устанавливает границы этого уровня шума. Разумеется, существует некоторый контент выше 45 кГц, но он не имеет явного сходства с оригинальным DXD-файлом. Только представители 2L могут сказать наверняка, использовался ли этот загруженный нами DXD-файл для создания MQA-трека.
5. В чем заключается разница между «софтовым MQA-» и «железным MQA-декодированием»?
Очевидно, что различий немного. Разница в ультразвуковом шуме на этот раз, особенно начиная с 75 кГц, — результат повышения уровня шума от АЦП, как видно из вышеприведенного FTT. То есть, если я отфильтрую те шумы в программе с фильтром нижних частот (ФНЧ) на отметке в 60 кГц, останутся следующие отличия:
Как и ожидалось, если вы увеличите масштаб диаграммы спектра частот, то увидите переходную зону, где программный декодер имеет спад чуть выше 40 кГц. Все, что выше, по-видимому, является «дополнительной» информацией, которую аппаратному декодеру удалось восстановить до предела в 60 кГц, ограниченного ФНЧ.
Обратите внимание, что средняя RMS-амплитуда «нулевого» файла с разрешением в 24 бит/192 кГц опускается вниз до - 90 дБ или около того (очень, очень мягкий спад).
6. Из любопытства, как насчет сравнения недекодированного MQA и DSD с сайта загрузки 2L для трека «Blågutten»?!
Для этого используем все тот же FFT-график в точке музыкального трека, рассмотренного выше. В итоге получаем всю разницу форматов, предоставляемых сайтом 2L для этой музыки:
Как вы видите, кривая недекодированного MQA-сигнала падает на отметке в 22 кГц со слегка усиленным уровнем шума выше 20 кГц (мы наблюдали это, когда я изучал MQA в прошлом году). Кривая DSD64 показывает обычный высокий уровень ультразвуковых помех выше 25 кГц, который является следствием работы технологии формирования нойз-шейпинга, перемещающей шумы за пределы слышимого диапазона. Точно также ведет себя DSD128, но с той лишь разницей, что это происходит на октаву выше и на частоте более 50 кГц. Очевидно, что PCM свободен от этих ограничений, связанных с уровнем шума. Само собой разумеется, мы рассматриваем ультразвуковой шум, и я оставляю вас подумать над тем, имеет ли это какое-либо заметно слышимое значение при правильном обращении с фильтрами. Похоже, нам понадобится DSD256, чтобы достичь низкого уровня шума в диапазоне до 100 кГц и иметь возможность конкурировать с PCM (192 кГц).
7. Все это очень хорошо с Hi-Res записями сайта 2L, но как насчет более типичных «хай-резов»?
Например, возьмем популярные рок-альбомы, которые, вероятно, изначально были записаны в аналоге и затем прошли мастеринг с повышением громкости и динамической компрессией.
Для сравнения я попросил моего друга записать трек Led Zeppelin «Good Times, Bad Times» (динамический диапазон DR8). Хотя он и записал его в разрешении 24 бит/192 кГц (но, поскольку этот трек декодируется только до 96 кГц, а все, что выше — это шум), я провел даунсемплинг записи. Вспомните, как я уже исследовал подобные треки несколько недель назад, сравнивая MQA-декодирование с хайрезом 24 бит/96 кГц, и обнаружил их явное сходство.
Здесь показана «разница» между «железным MQA» и «софтовым MQA»:
Как вы видите на представленной диаграмме спектра частот, разница между аппаратным и программным декодированием на этой записи более очевидна, чем на образце с сайта 2L (см. пункт 5). Интересно, не так ли? Громкий трек с псевдо-высоким разрешением, изначально записанный на аналоговую ленту, может продемонстрировать больше отличий, чем изначально чистая Hi-Res запись в формате DXD. Однако разница в средней RMS-мощности по-прежнему остается небольшой в области ниже планки -70 дБ, причем большая часть этого находится в диапазоне ультразвуковых частот.
Вот намек на причины существования различий:
Выше представлен еще один пример сравнения «Good Times, Bad Times», но на этот раз в частотной области в одном и том же месте (точке) песни. Здесь мы можем наблюдать более четкую «разницу» между программным и аппаратным декодированием в диапазоне 35–45 кГц. Похоже, что параметры цифровой фильтрации у TIDAL и алгоритма Mytek несколько отличаются, что приводит к более раннему спаду у «Бруклина».
В случае с Brooklyn мы видим небольшое количество шума в районе 55 кГц. Шум появился, очевидно, по причине антиалиасного фильтра. При поступлении сигнала с разрешением в 24 бит/96 кГц от TIDAL используемый антиалиасный фильтр Mytek оказал более сильное влияние, чем алгоритм повышения дискретизации для MQA-декодирования, применяющийся при поступлении MQA-данных с разрешением в 24 бит/48 кГц. Другой причиной появления шума может быть математическая точность, особенно — возможность появления межсемпловой перегрузки (межсемпловых пиков) в наиболее громких участках. Если это правда, то чем громче аудиотрек с большим количеством семплов, приближающихся к максимуму 0 дБ, тем более будет заметен эффект от различных типов фильтрации. И, наконец, третья причина заключается в том, что этот дополнительный шум вызван «процессорным шумом» Mytek’а, возникающим при декодировании (хотя лично я сомневаюсь в этом).
Выводы
Пора завершить эксперимент и подвести итоги. Вот, что я узнал из этого теста:
1. Как я уже отметил в своем предыдущем тесте, сравнивая файлы с высоким разрешением, для которых использовался тот же мастеринг, что и программный MQA-декодер TIDAL, MQA делает свою «работу» именно так, как и было заявлено — восстанавливает данные выше частоты в 22/24 кГц с достаточной степенью точности. Он использует биты информации, находящиеся ниже шумового порога, чтобы восстановить высокочастотный материал, расположенный над базовой частотой Найквиста в 22,05/24 кГц. Аппаратное декодирование, которое рассматривалось на примере трека «Blågutten», действительно воссоздало ультравысокие частоты выше 44,1 кГц, что является пределом для программного декодера TIDAL «MQA Core», который работает с частотами до 44,1/48 кГц (что соответствует частотам дискретизации в 88,2/96 кГц).
2. Я не уверен, базируется ли MQA-кодирование трека «Blågutten» на одном и том же DXD-образце, так как восстановленная с помощью Mytek Brooklyn форма волны выше 44,1 кГц и, по-видимому, не очень соотносится с ультразвуковым шумом DXD. Наблюдая за тем, как MQA-метод должен «сворачивать» данные, следует отметить, что более высокие октавы, вероятно, содержат меньшее количество битов, с которыми можно работать. Хотя есть вероятность, это просто отражение потери, когда каждая более высокая октава выше основной полосы становится менее точной (имеет больше потерь) при декодировании.
3. При сравнении софтового MQA-декодирования TIDAL с аппаратным алгоритмом Mytek Brooklyn, фактические результаты получаются весьма и весьма схожими. Безусловно, программно-аппаратное декодирование кажется более «точным» по сравнению с тем, что делает TIDAL, но та небольшая разница, которую я слышу при этом, не производит на меня большого впечатления.
4. ЦАП Brooklyn способен декодировать аудиоданные с разрешением в 24 бит/88,2 кГц (а также, предположительно, 96 кГц), полученные на выходе программного декодера TIDAL. Это говорит о том, что в выходном сигнале программного декодера имеется контрольная сумма файла или сигнатурный код, с помощью которых ЦАП может обнаружить, что этот сигнал исходит от MQA-источника и при необходимости продолжить «декодирование» или «воспроизведение» (как, предположительно, будет происходить у ожидаемых прошивок моделей AudioQuest Dragonfly Red/Black). Если не брать во внимание указывающую на это наглядную (красную) индикацию на дисплее, то окончательный декодированный выходной сигнал выглядит очень похожим на прямое программно-аппаратное декодирование (24 бит/44 кГц) с помощью Brooklyn.
До сих пор я не обсуждал мои субъективные впечатления от различных записей. Полагаю, данные Audio DiffMaker говорят сами за себя! При таких высоких уровнях глубины корреляции я просто не смог дифференцировать (отличить) программное декодирование TIDAL от аппаратного декодирования с использованием Mytek Brooklyn в любой последовательности. Эта технология запатентована, поэтому нам неизвестно, какие именно специальные настройки использовались для этого ЦАПа. Тем не менее, совершенно очевидно, что данный эффект настолько мал и едва различим, что даже профессиональный АЦП работающий с разрешением в 24 бит/192 кГц, не способен уловить большой разницы.
На самом деле, когда я воспроизвожу один из этих файлов (к примеру, как в пункте № 1, где рассматривалась разница между исходным DXD-файлом и программным декодированием TIDAL) на своем ASUS Xonar Essence One через наушники с выкрученным на 100% регулятором громкости, то едва слышу незначительный сигнал поверх фонового шума! При любом нормальном музыкальном сигнале это было бы невыносимо громко для моих старых добрых наушников Sony MDR-V6. Я не в состоянии «расслышать», как настолько низкоуровневые отличия. Помните, что шкала децибел — логарифмическая, и когда играет реальный музыкальный сигнал, все незначительные тонкости становятся еще более замаскированными.
Громкий трек Led Zeppelin со сжатым динамическим диапазоном, судя по всему, покажет более заметную разницу между программным декодированием TIDAL и аппаратным Brooklyn. Предполагаю, это указывает на то, как фильтры обрабатывают пики в динамически сжатой записи DR8. Что касается качества апсемплинга, то настольный компьютер имел бы гораздо больше возможностей, чем обычный процессор в конвертере. Я уверен, если бы учредители MQA захотели, то соответствующий программный декодер TIDAL мог бы стать еще более точным и справлялся с межсемпловыми перегрузками лучше, чем аппаратный алгоритм ЦАПа. Поэтому я бы воздержался от каких-либо заявлений, что софтовый декодер в любом случае уступит аппаратной реализации.
Кстати, однажды я попросил жену посидеть со мной в специально оборудованном для прослушивания музыки подвале, чтобы оценить различные варианты MQA- декодирования на аудиосистеме в следующей конфигурации: Raspberry Pi 3 CRAAP config --> TEAC UD-501 --> Emotive XSP-1 --> два моноблока Emotiva XPA-1L --> АС Paradigm Signature S8v3 + SUB1…
Она потеряла интерес уже через 5 минут прослушивания, и мы решили посмотреть очередной эпизод сериала «Молодой Папа».
Основываясь на том, что я узнал в прошлый раз и оценивая результат, полученный при тестировании современного высококачественного ЦАПа с MQA-декодированием, я могу похвалить компанию MQA за создание интересного компрессионного кодека для потоковой передачи сигнала. Такой кодек позволяет незаметно внедрить данные в область ниже шумового порога и достаточно неплохо воссоздать первое развертывание до 88/96 кГц MQA Core (хотя у меня и есть некоторые оговорки насчет находящихся выше октав). Тем не менее я не вижу никаких доказательств того, чтобы эффект «временного устранения размытия» (temporal deblurring) был слышимым. Это довольно интересно, учитывая, что я оцениваю здесь один из треков лейбла 2L, который должен раскрыть потенциал MQA-алгоритма. Более того, эти демо 2L рекламировались год назад на выставке CES2016 как великолепный результат применения MQA-процесса.
Я не думаю, что все это должно быть чем-то неожиданным, так как современные ЦАПы чрезвычайно точны, и, честно говоря, у меня не перехватывает дыхание от всех этих хвалебных статей. Помните, как я уже писал несколько месяцев назад в своей статье о коррекции акустики помещения, что если мы действительно хотим получить согласованное во времени звучание, то должны принимать во внимание взаимодействие акустических систем и помещения. Единственный способ достичь этого, заключается в проведении индивидуальных измерений в вашей комнате. На протяжении многих лет эти измерения успешно использовались в домашних кинотеатрах, поэтому в AV-ресиверы встраивались автокалибровочные системы (наподобие Audyssey), которые базировались на DSP-процессорах.
Здесь представлена заключительная демонстрация. Если я применяю ПО Acourate для создания фильтра коррекции акустики помещения и запускаю референсный DXD-файл в разрешении 24 бит/192 кГц через свертку DSP, используя софтовый мультимедиа-центр JRiver 22, то как будет выглядеть «разница» при сравнении результата на выходе после акустической коррекции комнаты с исходником?
Вот как выглядит коррекция в частотной и временной области в комнате для прослушивания! Эффект, связанный со сглаживанием частотных пиков и провалов, становится очевидным при A/B-тестировании. При этом заметны улучшения во временной области, связанные с широтой и объемом звуковой сцены. Эта «разница» может быть наглядно продемонстрирована с помощью амплитудной статистики, ясно показывающей, что звуковое воздействие от применения DSP приводит к значительно более высокому среднему значению RMS-мощности в остаточном файле. Какие бы улучшения не обеспечивал MQA, все это крайне незначительно по сравнению с данным уровнем коррекции.
Эпилог
Думаю, это все, что я хочу сказать об MQA. В конечном итоге, здесь действительно нет сюрпризов. Ну а как еще может быть на самом деле (особенно, если верить рекламным преувеличениям)? От начала и до конца это был механизм сжатия PCM «высокого разрешения» для обеспечения возможности потоковой передачи. Начнем с того, что высокое разрешение никогда не было настолько явно слышимым, поэтому мы не можем ожидать того, что метод с частичным сжатием с потерей данных обеспечит большие отличия в звучании. В действительности нас бы сильно насторожил тот факт, если бы все это звучало с заметным отличием от Hi-Res источника, из которого и было выведено! Что касается «устранения размытия» (de-blurring) — кто знает, что они имели в виду. Может быть, это всего лишь их минимально-фазовый апсемплинг, или, возможно, применяется какой-то «фоновый» DSP в процессе кодирования, использующий импульсные характеристики АЦП/ЦАП. В любом случае я не вижу и не слышу здесь большого влияния. Безусловно, меня можно раскритиковать, что я провожу тесты с помощью RME Fireface, и каким-то образом преимущества MQA были потеряны при прохождении через этот АЦП. Если это так, то я бы отметил: разница будет действительно незначительной, особенно с учетом высокого качества этого записывающего устройства!
Глядя на столь незначительную разницу при использовании аппаратного декодирования Mytek Brooklyn, я, разумеется, не буду срочно обновлять свои цифро-аналоговые преобразователи специально для работы с MQA. На самом деле, я все еще придерживаюсь мнения о том, что программное декодирование — это лучший вариант. Естественно, это ни в коей мере не отражается на впечатляющих записях, сделанных моим другом с выхода ЦАПа Brooklyn: это очень точное устройство.
Недавно я услышал, что термин DRM вновь приобрел актуальность. Несколько лет назад, когда я впервые написал об MQA, я задумался над вопросом о «защите от копирования» и о том, что слово «authenticated» (аутентичный, подлинный) больше относится к безопасности, чем к качеству звука. Похоже, что любители поковыряться в программном MQA-декодере, обнаружили способность данного софта декодировать различные формы «скремблирования». Хотя до сих пор мы не видели серьезного ухудшения звука; то есть файлы MQA, с которыми я сталкивался, звучат довольно хорошо и близки к разрешению CD без использования декодера MQA. Но в будущем такие файлы могут звучать хуже, что объясняется конструкцией стандартных цифро-аналоговых преобразователей без MQA-декодеров, на которых они будут воспроизводиться.
Позвольте уточнить, лично я отношусь к MQA довольно индифферентно и пишу об этом только на злобу дня. Я не утверждаю, что звукозаписывающие компании или MQA хотели что-то эдакое. Я просто пишу о том, что они смогли сделать. Безусловно, можно было бы свободно создавать резервные копии музыкальных файлов (некоторые люди, по-видимому, считают, что один этот факт сам по себе не делает MQA частью схемы DRM). Однако при этом все равно следует использовать аппаратное или программное декодирование с поддержкой MQA для обеспечения высокой точности звучания (в особенности, если скремблирование MQA намеренно снижает качество недекодированного звучания). Следовательно, свобода, с которой мы сейчас наслаждаемся ровным и точным звучанием Hi-Res файлов, будет ограничена.
Мой личный итог: до тех пор, пока существует стандарт PCM для интересной мне музыки, я не нуждаюсь и не беспокоюсь об MQA, основываясь на моем прослушивании и объективных сравнениях. Естественно, если вы считаете, что потоковая передача с высоким разрешением важна, то она имеет свою нишу — специально предназначенный для этого сервис TIDAL.
Еще раз спасибо моему другу, который, чтобы сделать эти скрупулезные записи, предоставил в «виртуальное» пользование ЦАП Mytek Brooklyn DAC, АЦП RME Fireface и свое время.
Желаю всем отличной недели! На протяжении многих лет я наслаждался композициями Арво Пярта. На прошлой неделе я слушал его «Плач Адама» (2012). Еще один прекрасный, глубокий, волнующий и духовный хоровой и оркестровый опыт.
Я надеюсь, что и вы все наслаждаетесь музыкой. Конечно, я бы с радостью узнал, что вы думаете о «звучании» MQA, если вы проводили собственные сравнения.
Дополнение: только сейчас я заметил сообщение на веб-сайте MQA, ссылка на который в тексте выше. Они по-прежнему утверждают, что файл MQA при воспроизведении в не декодированном варианте звучит «превосходно»:
«Нет декодера? Вам не нужен декодер, чтобы наслаждаться нашим "стандартным" качеством звука, которое было широко признано сообществами по мастерингу и превосходит по качеству CD». Для меня это что-то новенькое, исходя из обсуждений, которые я вел «не для протокола».
Легче будет поверить танцам с бубном, чем правильной научной рекомендации, что «MQA опирается на недавние исследования в слуховой неврологии, цифровом кодировании…»
Что касается утверждения Боба Людвига:
Нет. Теорема Найквиста — Шеннона не перевернулась с ног на голову (хотя они, вероятно, могут и перевернуться в своих могилах). Полагаю, Боб Стюарт просто не объяснил мистеру Людвигу, как правильно ее применять. Не такой уж и «сногсшибательный материал» здесь представлен, если у вас найдется время подумать об этом. «Точный аналог», да? Но что означает «точный»?
О да, позвольте мне напомнить, что минимально-фазовую фильтрацию с «не очень неестественным» предварительным звоном (pre-ringing) на определенном этапе наверняка слышали все. Это замечательное устройство для воспроизведения музыки называется iPhone (и iPad).
Обращаясь к журналу Absolute Sound!!! Боб Л., пожалуйста, скажите, что это не так! Реклама MQA просто должна была снова, само собой разумеется, заканчиваться словом «революция».
Оригинал: COMPARISON: Hardware-Decoded MQA (using Mytek Brooklyn DAC