Современные методы позиционирования и сжатия звука
Информация - Компьютеры, программирование
Другие материалы по предмету Компьютеры, программирование
зимуту, т.е. в горизонтальной плоскости. Ощущения, что звук расположен сзади и над слушателем, очень слабые, если нет поддержки в виде дополнительных сигналов. Особо отметим то, что использование алгоритмов HRTF, обеспечивающих воспроизведение звука для бинаурального прослушивания (т.е. в наушниках) и алгоритмов cross-talk cancelation (или для краткости CC; технология позволяющая воспроизводить звук, например из левой колонки так, что бы слышно этот звук было только левым ухом) не является успешным решением проблемы, неважно как хорошо цифры выглядят на бумаге или как крута рекламная компания.
Применение множества акустических колонок это уже другой вид зверей, но они действительно являются частью доступного выбора возможностей, особенно для компьютерных игр. Панорамирование звука обеспечивает явные выгоды при расположении акустических колонок сзади слушателя. Это облегчает проблему выбора места с наилучшим звучанием для прослушивания, так называемый sweet spot. Однако само по себе панорамирование звука никогда не может обеспечить значительных результатов, с точки зрения позиционирования источников звука в вертикальной плоскости. Конечно, до тех пор, пока мы не перестанем размещать колонки только на полу, а не начнем их подвешивать под потолком.
API и Rendering Engine - это две разные вещи!
Играя в игры, вы используете API и rendering engine (рендерин энджин). API (application programming interface или, для краткости, интерфейс) это, по сути, просто набор команд, используемых разработчиком при написании игры -- это не технология 3D звука или чего-то другого.
Rendering engine или механизм воспроизведения звука (далее просто звуковой движок) представляет собой процесс взаимодействия алгоритмов 3D звука со звуковыми потоками с целью расположения источников акустики в пространстве. Если API (например, DS3D или наш QMDX) поддерживает множество звуковых движков, тогда в одном и том же приложении будет воспроизводиться звук немного отличающийся при использовании разных звуковых движков, почти так же, как и звуковая дорожка MIDI (другой набор команд) будет звучать немного иначе на разных аппаратных синтезаторах от различных производителей.
Так как различные звуковые движки и схемы реализации имеют разную степень эффективности соответствующий интерфейс позиционирования не должен ограничиваться возможностями какого-то одного звукового движка. В действительности, API говорит: "поместите этот звук здесь" и звуковой движок делает эту работу наилучшим способом, помещая звук в нужное место. При этом звуковой движок использует свои алгоритмы и имеющуюся конфигурацию воспроизведения звука (наушники, две колонки, 15 колонок, что угодно).
Люди, которые делаю заявления типа "эта игра поддерживает только DS3D" совершенно не понимают сути вещей. Если игра написана под интерфейс DS3D - это отлично! Она будет работать со всеми 3D звуковыми картами в любой последовательности. На каждой звуковой карте, игра будет использовать имеющийся звуковой движок, неважно, кем он сделан QSound, EMU, Aureal или кем-то еще.
Существует масса звуковых интерфейсов, таких, как DS3D, QMDX, QMixer, A3D 1.x и 2.0 и звуковые API третьих фирм, таких как HMI, EAR, Diamondware и другие. Если программист выбрал для использования интерфейс "Фирмы Х" (при этом он может также использовать более чем один API для конкретного приложения) это совсем не означает, что вы должны обязательно использовать аппаратное обеспечение "Фирмы Х" что бы все работало.
Что сбивает с толку, так это знание того, какой звуковой движок поддерживает данный API.
Лишь немногие API созданы для поддержки специфичных аппаратных возможностей, которые могут быть недоступны при использовании звуковых карт других производителей или они могут быть неспособными поддерживать основные функциональные возможности конкурирующих продуктов.
Хороший API должен поддерживать как можно больше аппаратного обеспечения и так много функциональных особенностей, насколько это возможно, так, чтобы разработчик игры мог использовать один интерфейс и получить хороший результат на всех звуковых платах.
Например, если кто-то купит игру, которая была написана в расчете на новейшую версию интерфейса QMixer, эта игра будет иметь отличные 3D звуковые эффекты даже на звуковой карте с поддержкой только обычного стерео звука. Если та же игра будет запущена на системе оснащенной 3D картой на чипсете от Aureal, игра все равно будет использовать чипсет Aureal для воспроизведения 3D звука, в итоге пользователь услышит то, за что он заплатил.
Большинство разработчиков убедились в очевидном преимуществе использования таких API, как DS3D, QMixer и QMDX, которые не являются зависимыми от производителя аппаратного обеспечения и, следовательно, будут прекрасно работать с любой 3D звуковой картой.
Что такое "Panning"?
Panning (панорамирование) -- этот термин происходит от простого устройства, изобретенного Лесом Полом (Les Paul) в далеких 50-х годах, которое использовалось для расположения моно фонических звуковых дорожек в явно определенное положение слева/справа в стерео звуковом поле.
"Panoramic Potentiometer" (или для краткости "Pan Pot", панорамный потенциометр) это нечто вроде регулятора баланса в стерео системе. В то время как регулятор баланса управляет всем входящим стерео сигналом и выдает отрегулированный стерео сигнал на выходе, pan pot управляет моно сигналом на входе, а на выходе выдает его разделенным на части, передавая их в выходные каналы, левый и правый.
Любой микшерский пульт стерео звука (использующийся в студии ?/p>