DSP и Native-системы в цифровом аудио — есть ли разница?

Сравнение результатов работы цифровых рабочих аудио-станций (DAW) на базе DSP (Pro Tools TDM 7), и на базе CPU (т.н. native-системы) на примере программы Reaper 5.

Вопрос сравнения результатов работы DAW на разных платформах в настоящее время вряд ли представляет для абсолютного большинства их пользователей сколь-либо серьёзный интерес (они просто работают в них :), но тем не менее он до сих пор периодически возникает в различных сообществах как специалистов, так и любителей цифрового микширования аудио, и даже иногда проводятся некие практические сравнения, пишутся статьи и даже снимаются сравнительные видео.

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

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

Так как же корректно сравнивать результаты? Самым простым и в то же время самый действенным способом сравнения результатов работы различных DAW является т.н.»побитовое сравнение» — файлы миксов попарно складываются друг с другом в противофазе, в результате чего получается некий разностный файл, который впоследствии можно прослушать и проанализировать. Другим вариантом является тестирование исключительно на слух, когда прослушиваются непосредственно результаты (миксы), но так как оно является весьма сильно подверженным всевозможным субъективным факторам восприятия, то для максимально корректного результата его необходимо выполнять исключительно «вслепую», когда прослушивающий не знает, какой именно результат он слушает. Тестирование на слух обычно применяется для прослушивания аналогового и гибридного (аналого-цифрового) оборудования, в случае же чисто цифрового сравнения (чем собственно и является сравнение миксдаунов различных DAW) в тестировании на слух нет никакой фактической необходимости, разумеется при условии того, что воспроизведение миксов происходит на одной и той же системе. В данном случае побитовое сравнение даёт абсолютно всю необходимую и достаточную информацию о разнице результатов работы различных DAW на различных платформах, соответственно им и будем пользоваться в нашем исследовании. Разумеется, дополнительно послушать и сравнить результаты на слух нам тоже абсолютно ничего не помешает.

Проводить побитовое сравнение можно либо в любой DAW, поместив испытуемую пару миксов синхронно по времени на две соседние дорожки, и нажав на одной из них кнопку переворота фазы, либо даже в двухдорожечном аудиоредакторе, так как практически все они позволяют сложить два файла в противофазе. Проверить корректность побитового вычитания несложно — взять один и тот же файл, продублировать его в DAW на соседнюю дорожку (обычно это делается с помощью команды duplicate track или аналогичной), и нажать на любом из этих треков кнопку переворота фазы — в результате мы должны услышать абсолютную тишину, и индикаторы в DAW также не должны абсолютно ничего показывать.

Также не лишним будет напомнить, что совершенно некорректно сравнивать содержимое аудиофайлов некими «чисто компьютерными» методами (всевозможными «командерами» и прочими программами, обнаруживающими совпадающие файлы) — в них как правило сравнивается весь файл целиком, который может содержать различающуюся в зависимости от условий его создания дополнительную служебную информацию. В аудиоредакторе же или DAW сравнивается именно аудиоинформация, при этом служебная информация игнорируется и не искажает результаты сравнений.

И вот тут в результате первых же тестов обнаруживается первый и очень важный нюанс — не все исследуемые системы в миксах выдают синхронный по времени результат — в некоторых экспортируемые миксы оказываются сдвинутыми назад буквально на несколько семплов. Если не учитывать эту особенность — при побитовом сравнении получаем абсолютно некорректный результат даже для абсолютно идентичных по звучанию файлов (фактически это равнозначно тому, что синхронно сдублированный файл сдвинули по времени вперёд или назад — разумеется ни о каком корректном побитовом сравнении таких дубликатов не может быть и речи, хотя фактически это один и тот же файл). В чём причина такого поведения систем — пожалуй точно это знают только разработчики, и выяснять это в данном исследовании какого-либо смысла не имеет, но соответственно скорректировать само сравнение надо обязательно, иначе получаем в корне неверные результаты. Сделать это проще всего визуально по форме волны на достаточном увеличении, когда видны непосредственно сами семплы, и максимально упросить задачу нам поможет специальный файл с единичным импульсом, дополнительно импортируемый в тестовые проекты. Это небольшой по времени аудиофайл с цифровой тишиной и находящимся в ней в произвольном месте единственным семплом с максимальной амплитудой сигнала (на слух воспринимается как щелчок), который и будет являться маркером времени. В данном случае я поместил импульс самым первым семплом файла 00-1imp.wav, а файлы мультитрека подготовил таким образом, что звук в них начинается через некоторое время (оставил один такт тишины). Таким образом маркеру ничто не помешает быть слышимым и видимым при сравнении. Скорректировать результаты по времени таким образом становится несложно: в редакторе на максимальном зуме по времени (когда непосредственно видны сами семплы) в самом начале всех миксов проверяем — если в миксе импульс является первым семплом — оставляем всё как есть, если же нет — отрезаем все семплы до него, чтобы он стал первым, и сохраняем этот изменённый файл для последующего сравнения.

Итак, можно приступать к непосредственному сравнению. Несколько слов о проекте для сравнения — в общем случае он может быть абсолютно любым, главное чтобы в нём содержались как моно, так и стерео-файлы одинаковой частоты и битности. В данном проекте все файлы 24-битные с частотой 44100 Гц, но в предварительных исследованиях также использовался проект с частотой 48000 Гц (другие частоты и битности не исследовались). В процессе исследования также выяснилось некоторое важное отличие в поведении разных систем по отношению к стерео-файлам, поэтому для более показательного сравнения хотя бы в одном из таких файлов желательно наличие явной разницы уровней по каналам. Такой мультитрек я нашёл у себя в архивах — он содержит моно и стерео-файлы барабанов, моно-файлы баса, акустической и электрической гитар, а также стерео-файл электропиано, в котором прослеживается явная разница между уровнями левого и правого каналов. Всего получилось 24 музыкальных трека, и один трек-маркер с единичным импульсом, который я расположил первым в проекте.

Но прежде чем начать — несколько ключевых моментов, о которых (почему-то 🙂 нередко забывают при проведении подобных тестов. Во-первых, это наличие в любых DAW механизмов, реализующих закон панорамирования (pan law или pan depth). В двух словах pan law это значение, на которое уменьшается уровень панорамируемого сигнала при помещении его в центр панорамы. Более подробно про pan law можно почитать, например, тут: https://… (см.раздел Stereo Pan Law).

Используемых на практике значений несколько — 0dB (не уменьшать уровень), -2,5 dB, -3 dB, -4,5 dB, -6 dB. В некоторых системах эти значения настраиваются, в некоторых же — значение фиксировано «вшито» в систему, и изменению пользователем не подлежит. Разумеется, абсолютно некорректно сравнивать результаты, производимые в системах с разными значениями pan law, так как в миксах наверняка есть треки, расположенные по панораме не только в крайних точках слева или справа. Стало быть, необходимо либо выставить одинаковое значение pan law во всех испытуемых системах, либо скорректировать по уровню треки, находящиеся не в крайних точках панорамы. Например, в системе Pro Tools TDM значение pan law является фиксированным с уровнем -2,5 dB, а в программе Cubase такого значения нет, поэтому сравнивать их «в лоб» с разными значениями pan law некорректно. Но если выставить в программе Cubase значение pan law = 0 и понизить уровни расположенных в центре панорамы каналов на -2,5 dB — сравнение будет являться корректным, но разумеется только для расположенных по краям и в центре панорамы каналов. Почему же только для них?

Мы плавно подошли к следующему важному вопросу, вытекающему из предыдущего — а как же тогда собственно регулируется панорама при перемещении из центра до крайних точек слева и справа? Если уровень регулируется в децибелах, и принимает определённые (вполне конкретные для любых систем) значения, то панорама — в процентах либо в абстрактных единицах в некоем диапазоне (как правило от центра (ноля) до 100 влево или вправо, в некоторых системах плагинах возможно варианты до 50 или вовсе от 0 до 1), и более того — это изменение не является линейным! В различных программах используются квадратичные, синусоидальные, либо свои собственные функции изменения панорамы, которые могут быть также с дополнительной (отключаемой) компенсацией центрального уровня. Подробнее с иллюстрациями можно посмотреть, например, тут:

Как правило, эти функции «зашиты» в систему намертво, и управлять ими без сторонних средств не представляется возможным. Разумеется, и в данном случае результаты, полученные при использовании в тестовых проектах точек панорамы, отличных от центра (понижаемого на значение pan law) и самых крайних точек слева и справа (остающихся неизменными по уровню), при разных законах панорамирования для не крайних точек не могут считаться корректными. Но тут крайне важно понимать, что по сути это всего лишь небольшие изменения уровней, которые при невозможности выбора абсолютно одинаковых законов могут быть легко скомпенсированы вполне очевидным образом — регулировкой уровня.

Вот почему в итоге я выбрал программу Reaper (работающую на CPU компьютера) для сравнения с системой Pro Tools TDM — в ней (текущая версия 5) не просто есть значение pan law = -2,5 dB, а также можно для каждого трека назначить своё значение pan law, причём даже совсем не обязательно то, выбор из которых предоставляется в настройках, а любое отрицательное, например -2,4 или даже -10 🙂 Reaper использует свой собственный оригинальный закон регулировки панорамы (см.по ссылке выше), а какой закон использует система Pro Tools TDM несложно выяснить экспериментальным путём при помощи тестовых сигналов. К примеру, всё тот же единичный импульс воспроизводится в обоих системах при одинаковых значениях панорамы, и результаты (стерео-файлы) сравниваются. В частности, для точек панорамы L50 (и R50 соответственно, только в «зеркальном» отображении) различия систем Pro Tools TDM и Reaper 5 составляют 0,28 и 0,75 dB — для компенсации этой разницы на треках с панорамой L50 и R50 в системе Reaper 5 я использовал встроенный JS-плагин Channel Mixer, в котором выставил эти значения соответствующим образом.

И наконец, третий важный момент — практически сразу же при проведении исследования выявилось различное поведение систем при работе со стерео-файлами. Вероятно исторически так сложилось, что в более ранних системах стерео-файлы вынуждены были разделяться на два моно-файла — возможно это как-то связано либо с ограничением ресурсов, либо с более привычной и очевидной на тот момент концепцией копирования работы аналогового оборудования. Опять же, с полной уверенностью об этом могут говорить разве что разработчики, а нам необходимо лишь учитывать этот факт при проведении тестов, чтобы не нарушить корректность результатов. Система Pro Tools TDM поддерживает работу со стерео-файлами, но вероятно разделяет их при этом на два моно-файла, обрабатывающиеся независимо. На что же это влияет в контексте подобных исследований?

Во-первых, стерео-файл поделённый на два моно-файла при их панорамировании в крайние точки панорамы будет иметь поведение, аналогичное двум отдельным моно-файлам в режиме крайних точек панорамы, и соответственно их уровень в крайних точках не будет изменяться на установленное в системе значение pan law. В отличие от этого, системы работающие со стерео-файлами как с единым файлом — могут понижать его уровень в соответствии с выставленным в системе значением pan law. Если такое понижение происходит, то для компенсации различного поведения систем необходимо указать в этой системе для стерео-файлов pan law = 0, либо компенсировать понижение их уровня увеличением на значение pan law.

Второй ключевой момент — работа стерео-файлов со стерео-плагинами динамической обработки. Очевидно, что в системах с раздельной обработкой стерео-файлов как двух моно-файлов и неизбежной разницей по уровням в левом и правом каналах динамическая обработка тоже будет работать как двойное моно, даже если мы установили в программе стерео-плагин. В системах же с обработкой стерео-файла как единого целого — стерео-плагины будут работать в режиме стерео, и результаты подобного сравнения могут быть некорректными. Наиболее критично это для плагинов динамической обработки, и как правило совершенно не критично например для эквализации. Для учёта и компенсации подобного различного поведения систем существует как минимум два выхода — если в плагине есть функция stereo link или аналогичная — отключить её (иногда называется dual mono — её соответственно необходимо включить), либо, если возможности раздельной работы для двух каналов плагин не предоставляет — поступить аналогично системе с двойными моно-файлами — разделить стерео-файл на два моно-файла, и обработать их моно-версиями плагинов с теми же настройками, что и стерео-версии. В процессе исследования системы Pro Tools TDM также обнаружился крайне любопытный факт — если перед плагином динамической обработки стоит другой плагин, в котором включена функция объединения каналов — динамический плагин работает со стерео-файлом как с единым целым! Если же плагины поменять местами, либо вовсе убрать первый плагин с линком — динамический плагин работает со стерео-файлом как с двумя моно-файлами! Сию багофичу тоже необходимо учитывать при проведении подобных исследований.

И ещё небольшое общее замечание касаемо работы плагинов — как все понимают, протестировать все существующие на данный момент плагины физически не представляется возможным. Некоторые плагины и вовсе могут являться уникальными и не иметь аналогов на других исследуемых системах, а некоторые могут быть перенесены на другие системы с какими-либо изменениями или даже ошибками, поэтому в данном случае для исследования необходимо выбирать максимально известные, распространённые, годами проверенные варианты. Думаю, ни для кого не секрет, что именно такую репутацию несут плагины фирмы Waves — их мы и будем использовать при проведении исследования. Нам важен сам факт корректной работы плагинов в разных средах, то есть даже один одинаково работающий плагин в разных средах даст нам абсолютную уверенность в том, что система взаимодействует с плагинами того и иного формата корректно. В данном случае будут использоваться два плагина, как наиболее часто используемые по функционалу варианты — эквалайзер Waves Q1 и компрессор Waves C1, причём оба они будут использоваться в моно и стерео-вариантах.

И тут опять сразу же выясняется очень интересный факт — TDM и RTAS плагины на системе Pro Tools работают не синхронно по времени — каждый TDM плагин в цепи инициирует отставание обрабатываемого трека на несколько семплов. При этом сами алгоритмы плагинов и в TDM, и в RTAS (и в VST, чуть забегая вперёд) работают абсолютно одинаковым образом, поэтому для корректного исследования данный временной сдвиг (очередная багофича, по сути) разумеется необходимо скомпенсировать. Экспериментальным путём было выяснено, что в исследуемой системе Pro Tools TDM 7 каждый TDM плагин отодвигает дорожку по времени на 3 семпла назад, два плагина — соответственно на 6 семплов, ну вероятно и так далее (более 2-х плагинов на треке в данном исследовании не использовалось). Для компенсации этого явления в программе Reaper 5 те треки, которые содержат плагины, отодвигались на 3 и 6 семплов назад командой Nudge, в противном случае в результате получаем ту же самую некорректность, что и при побитовом сравнении не синхронных по времени файлов.

Ну и последняя функция микширования, которая будет исследоваться — автоматика. На некоторых треках будут сделаны линейные изменения уровня от начала до конца файла (fade in и fade out). Почему важно, что изменения происходят линейно — у разных систем как правило несколько выбираемых пользователем кривых автоматики, но разумеется только линейная даёт нам определённую уверенность в их одинаковости, соответственно для исследования самого принципа работы систем именно её мы и выбираем.

Итак, собственно проекты, скриншоты, и результаты (как есть, без компенсации по времени, а файл с разницей уже с компенсацией по времени, разумеется) находятся в архиве вместе с данным текстом по адресу:

https://…

В проектах систем Pro Tools TDM (ПО версии 7) трек с единичным импульсом, моно и стерео-треки с музыкальным материалом с различными уровнями, панорамированные в центральные и крайние точки панорамы (0, L100, R100, а также два моно-трека панорамированны в точки L50 и R50), автоматизация fade in и fade out на моно и стерео-треках, а также плагины Waves Q1 и С1 в моно и стерео-вариантах, расположенные по одному (только эквалайзер) или по два (эквалайзер и компрессор) на трек. Используются stereo-микшер.

В проекте системы Reaper для всего проекта установлено значение pan law -2,5dB, а для стерео-треков — 0dB, для компенсации различного поведения систем при работе со стерео-файлами. На треках с панорамой L50 и R50 также дополнительно установлены плагины изменения уровня для компенсации различий в законах панорамирования для не крайних точек панорамы. Также все треки с плагинами, напомню, отодвинуты по времени на 3 (один плагин) и 6 (два плагина) семплов.

Соответственно после миксдаунов для компенсации сдвига по времени системы Pro Tools TDM необходимо выполнить синхронизацию по единичному импульсу, как было описано выше. Разница получается всего 4 семпла. Что интересно — в системах Pro Tools более поздних версий (не TDM) в такой компенсации уже нет необходимости — первый же семпл является импульсом, и всё выводится абсолютно синхронно с системой Reaper, также нет в них и задержек TDM плагинов, и при использовании RTAS плагинов в дополнительных сдвигах треков тоже нет никакой необходимости.

В итоге, после учёта всех выявленных в исследовании особенностей (синхронизация по времени, законы панорамирования, различное поведение систем при работе со стерео-треками, а также задержка TDM-плагинов) имеем разницу между результатами на уровнях -90 dBFS rms, которая абсолютно очевидно лежит за пределами человеческого восприятия. Никаких расхожих в определённых кругах легенд и мифов о каких-либо существенных принципиальных отличиях систем на базе DSP от систем на базе CPU на практике не подтверждается. Файлы миксов и файл разницы можно послушать — никаких «более лучших атак», «более широкого пространства», «отсутствия нативной мути» и прочего подобного превосходства, на протяжении многих лет столь активно муссирующегося в определённых кругах, не слышно ушами и не видно анализаторами.

Результаты исследования однозначно указывают на то, что математика микширования на всех системах работает без каких-либо явных отличий, которые хоть как-то способен уловить человек. Плагины в разных средах тоже работают по одинаковым алгоритмам, разумеется если разработчики не сделали изменений или ошибок при переносе на другую платформу. Порядок же имеющейся разницы (-90 dBFS rms) вероятнее всего указывает на то, что это возможно и есть реальные различия между вычислительными моделями систем (48-integer для систем Pro Tools TDM и 32-floating для native-систем). Как и следовало ожидать, в реальной работе этой абсолютно неслышимой разницей можно и нужно смело пренебрегать.

Выражаю благодарность Иванову Олегу, Спицыну Максиму и Палшкову Павлу за проведение исследований на системах Pro Tools.

Я также заранее прошу прощения у всех специалистов за возможно в некоторой степени упрощённый стиль изложения материала, но как мне кажется это крайне необходимо новичкам и не только, которые не особо сильны в данных технических нюансах. По своей сути исследование достаточно банально, и для полного его понимания абсолютно достаточно обычного среднего образования, никаких особых выкладок и откровений тут конечно же нет, но почему-то очень часто даже в подобного рода несложных вопросах (как правильно синхронизировать и побитово сравнить файлы? что такое pan law? и т.п.) понимание либо отсутствует вовсе, либо присутствует явно в недостаточной степени. Данное сравнение ставит основной целью кардинально улучшить существующую ситуацию — чтобы специалисты не только слепо доверяли неким (авторитетным для них) мнениям, но и умели проверить достоверность этих мнений на практике, понимая ключевые принципы и учитывая все возможные нюансы. Данное сравнение будет размещено на крупных форумах и прочих профильных площадках рунета — обсуждения, замечания, пожелания и репосты крайне приветствуются! 🙂