FAQ-АЦП, биты, платы и уровень записи
- Автор темы sunet
- Дата начала
I
Ifrit
Guest
Вот, наткнулся у себя, может кому интересно/полезно будет. Вложение - White Paper по ПТ шине/микшеру.
Цыхра
В исходном сигнале http://img139.imageshack.us/img139/743/1xv0.gif 32 отсчета.
При уменьшении амплитуды в результате округления каждая вторая ступенька "теряется" (округляется до уровня предыдущей). http://img321.imageshack.us/img321/4727/2qf8.gif
Количество отсчетов остается прежним.
При пересчете с помощью float округления нет, поэтому ступеньки сохраняются.
Для наглядности отсчеты нужно было показать точками а не линиями...
В исходном сигнале http://img139.imageshack.us/img139/743/1xv0.gif 32 отсчета.
При уменьшении амплитуды в результате округления каждая вторая ступенька "теряется" (округляется до уровня предыдущей). http://img321.imageshack.us/img321/4727/2qf8.gif
Количество отсчетов остается прежним.
При пересчете с помощью float округления нет, поэтому ступеньки сохраняются.
Для наглядности отсчеты нужно было показать точками а не линиями...
Не, ну в реальности конечно все не так страшно, при однократном преобразовании много не потеряешь. Но если преобразований много, то ошибки начнут накапливаться и даже это "чуть-чуть" выльется в цифровой шум и прочие артефакты.
А вот пример как выглядит треугольник на -60dB в аудишене. Заметьте, тут мешает именно недостаток битности. Сэмплы можно подвигать руками и наглядно видно, насколько они дискретны. В 32float такой проблемы нет.
Другое дело, что практически во всех программах внутренняя обработка идет в 48/64бит или в 32float, так что особо волноваться нечего :smile:
А вот пример как выглядит треугольник на -60dB в аудишене. Заметьте, тут мешает именно недостаток битности. Сэмплы можно подвигать руками и наглядно видно, насколько они дискретны. В 32float такой проблемы нет.
Другое дело, что практически во всех программах внутренняя обработка идет в 48/64бит или в 32float, так что особо волноваться нечего :smile:
У
Удалённый пользователь 2234
Guest
<div class='quotetop'>QUOTE(\"supersonic\")</div>
В результате обсуждения все, кажется, наконец-то поняли, что применение формата 32 float вместо fixed форматов позволяет кардинально увепичить точность вычислений, и соответственно при обработке нужно использовать 32 float. Тогда должно быть понятна и логика перехода на 64 float - аргументы абсолютно те же.
Для тех, кто не верит математике (хотя для того, что бы не тратить свое драгоценное время на тесты, лучше математику знать) - а верит только своим собственным ушам - простые примеры, позволяющие ушами услышать разницу между обработкой 32 float vs 64 float.
1. Guitar Rig 2 - кнопка Hi Res;
2. z3ta - 2x oversampling;
3. ArtsAcoustic Reverb - кнопка 32/64.
<div class='quotetop'>QUOTE(\"sunet\")</div>
Маркетинг, соображения конкуренции и рекламы, конечно, имеют место быть - куда ж без этого. Но в данном случае (DSP - 32 float vs 64 float) происходит абсолютно естественный процесс предоставления разработчикам возможности улучшать качество и возможности своих продуктов за счет более точного формата данных. Именно предоставление возможности - совершенно понятно, что качество обработки в первую очередь определяется качеством алгоритмов, и плохой алгоритм не спасут ни 64 float, ни что-то еще.
В результате обсуждения все, кажется, наконец-то поняли, что применение формата 32 float вместо fixed форматов позволяет кардинально увепичить точность вычислений, и соответственно при обработке нужно использовать 32 float. Тогда должно быть понятна и логика перехода на 64 float - аргументы абсолютно те же.
Для тех, кто не верит математике (хотя для того, что бы не тратить свое драгоценное время на тесты, лучше математику знать) - а верит только своим собственным ушам - простые примеры, позволяющие ушами услышать разницу между обработкой 32 float vs 64 float.
1. Guitar Rig 2 - кнопка Hi Res;
2. z3ta - 2x oversampling;
3. ArtsAcoustic Reverb - кнопка 32/64.
У
Удалённый пользователь 2234
Guest
<div class='quotetop'>QUOTE(\"dugdum®\")</div>
По пунктам 1 и 3 возражений нет?
Возможно. Сейчас под рукой нет z3ta и его описания. Если у Вас есть точная информация по этому режиму - поделитесь.
По пунктам 1 и 3 возражений нет?
да неизвесно что там происходит. оверсемплинг в z3ta+ это как бы увеличение частоты дискретизации внутри плагина... что происходит в других плагинах неизвестно. скорее всего точность мат моделей/ресурсоемкость увеличивают, к битности это врядли имеет отношение. для звука мало значения имеет 32 там или 64...
У
Удалённый пользователь 2234
Guest
<div class='quotetop'>QUOTE(\"dugdum®\")</div>
<div class='quotetop'>QUOTE(\"dugdum®\")</div>
<div class='quotetop'>QUOTE(\"dugdum®\")</div>
В приведенных примерах 1 и 3 (Guitar Rig 2 - кнопка Hi Res и ArtsAcoustic Reverb - кнопка 32/64) переключается именно битность.
<div class='quotetop'>QUOTE(\"dugdum®\")</div>
Надо почитать мануал - под рукой нет.
<div class='quotetop'>QUOTE(\"dugdum®\")</div>
После оцифровки звук ничем не отличается от любой другой цифровой информации. Пример. Все математические функции из стандартной библиотеки С++ (и других языков) принимают данные и возвращают значения в формате double (64 float) для обеспечения необходимой точности вычислений. Вопрос: почему мы должны понижать точность вычислений при обработке звука и не использовать все предоставленные нам возможности (при наличии, естественно, ресурсов)?
я в арт акустиксе не слышу улучшений звука, когда нажимаешь эту кнопку (кастрюля она кастрюля и есть =). насчет гитар рига не знаю, не стоит он у меня. вот в z3ta от оверсемплинга явно есть эффект.
<div class='quotetop'>QUOTE(\"NickCrow\")</div>
а почему мы должны их повышать и больше рассходовать ресурсы если на слух не наступает улучшения?
<div class='quotetop'>QUOTE(\"NickCrow\")</div>
а почему мы должны их повышать и больше рассходовать ресурсы если на слух не наступает улучшения?
У
Удалённый пользователь 2234
Guest
Простой пример, позволяющий понять - зачем нужна высокая точность при вычислениях. Чтобы было понятнее - пример с использованием привычных всем десятичной системы и десятичных дробей.
Результат деления 1 на 3 при использовании вышеприведенных систем будет всегда только приблизительным = 0,333333 (3 в периоде) и точность полученного результата будет зависеть от количества этих троек, которые мы можем сохранить. Т.е. в приведенном примере видно, что результат даже очень простой операции может быть приблизительным и в последующие операции передается округленным. А если таких операций несколько миллионов?
Результат деления 1 на 3 при использовании вышеприведенных систем будет всегда только приблизительным = 0,333333 (3 в периоде) и точность полученного результата будет зависеть от количества этих троек, которые мы можем сохранить. Т.е. в приведенном примере видно, что результат даже очень простой операции может быть приблизительным и в последующие операции передается округленным. А если таких операций несколько миллионов?
ну и? если разницы не слышно, то что, какой вывод?
очередная надуманная проблема.
вычислительные ресурсы лучше потратить на те вещи, которые дадут выигрыш в звуке,
например более точные мат.модели задействовать для обработок. точные по алгоритмам,
а не по избыточной точности математических операций.
надо 64 бита, да ради бога, например Traktion 2 уже имеет такой микшер (галочку надо поставить).
только толку от этого ноль.
очередная надуманная проблема.
вычислительные ресурсы лучше потратить на те вещи, которые дадут выигрыш в звуке,
например более точные мат.модели задействовать для обработок. точные по алгоритмам,
а не по избыточной точности математических операций.
надо 64 бита, да ради бога, например Traktion 2 уже имеет такой микшер (галочку надо поставить).
только толку от этого ноль.
Уважаемые админы! Вижу дебаты закончились, корректировки вроде сделал, так что если кто правописание проверит, можно перекидывать в FAQ.
Понижать не надо. Но и завышать без причин нет смысла. Потому что в конечном итоге точность результата у нас ограничена определенным количеством знаков. Если результат деления 1/3 нужно получить с точность 5 знаков после запятой, какая разница где накопится ошибка, в 25 знаке или в 125-ом? Работая с аудио мы финальный слышимый результат имеем в 16 или 24 бит, конвертеры полюбэ целочисленные.
Есть процессы которые могут в результате вычислений накопить ошибку, которая вылезет в слышимый диапазон. Если же ошибка округления находится на уровне 25, 27, и 64-го бита никто этого не услышит. Говорить, ошибки округления ВСЕГДА влияют на результат - ОШИБОЧНО. Во многих случаях они остаются за порогом конечного разрешения. Вот здесь и требуется гибкость в подходе чтобы определить, когда и какая точность вычислений оправдана.
Но суть не в этом. Я совсем о другом. Математика ВНУТРИ плагина действительно во многих случаях влияет на результат. Так оставим ее на совести разработчика. Я говорю о том что храня данные в избыточном формате невозможно повлиять на то что произойдет внутри плагина.
Если там есть кнопка 32/64 результат будет разным. Но если ты пропустишь через плагин один и тот кусок аудио, в 24 битах, 32 битный или даже 64 битный финальный результат будет одинаковый.
Как только данные попадают в плагин, они автоматически переводятся в формат его внутренней шины. Будь она 32float, 48 fixed или 64 float, исходный поток 24битных данных автоматически конвертируется. Поэтому нет никакого смысла пересчитывать 24 битные данные конвертера в 32 бит, это все равно автоматически проиcходит в Кубейсе, как только ты нажимаешь кнопку play.
Я вот когдато и задавал вопрос именно такого смысла ХДЕ ДАКАЗАТЕЛЬСТВА когда разработчик заявляет о поддержки плагином количества бит.Ведь если последовательно включенно несколько плагинов и один поддерживает только 24,другой 32 а другой вообще втесался с 16 бит(например) и таких в разнобой 5-10 штук.Ну как известно шум квантования при 24-32 битах ничтожно мал.Но если при постройке Небоскреба на каждом этаже ошибаться на 5 см то вверху уйдут метры.Согласен, пример плохой,но смысл в моем вопросе тот же.Если в куб начинает пересчитывать после каждого плага (например) в 32 бита а каждый последующий плагин обратно в свой режим работы,не многовато ли будет каки? Транкейт еще однако.Учат, типа после одного пересчета применить нойзшепинг и т.п. а тут целых 20 и получается без нойзшейпинга и остальной радости
Originally posted by Newalks
Я вот когдато и задавал вопрос именно такого смысла ХДЕ ДАКАЗАТЕЛЬСТВА когда разработчик заявляет о поддержки плагином количества бит.Ведь если последовательно включенно несколько плагинов и один поддерживает только 24,другой 32 а другой вообще втесался с 16 бит(например) и таких в разнобой 5-10 штук.Ну как известно шум квантования при 24-32 битах ничтожно мал.Но если при постройке Небоскреба на каждом этаже ошибаться на 5 см то вверху уйдут метры.Согласен, пример плохой,но смысл в моем вопросе тот же.Если в куб начинает пересчитывать после каждого плага (например) в 32 бита а каждый последующий плагин обратно в свой режим работы,не многовато ли будет каки? Транкейт еще однако.Учат, типа после одного пересчета применить нойзшепинг и т.п. а тут целых 20 и получается без нойзшейпинга и остальной радости
Когда говорят о накоплении ошибок имеют в виду то что происходит при расчетах ВНУТРИ плагина. Там данные могут проходить тысячи и миллионы циклических пересчетов. Но повода для паранойи нет, не надо за каждым углом видеть притаившуюся ошибку округления. То, что повседневно делает юзер в кубейсе, кручение фейдеров громкости, ручек панорамы, эквалайзеров и плагинов никаких страшных ошибок наделать не может.
Для всех этих операций 32бит выше крыши достаточно. Для того и придумали шину с избыточным форматом данных, чтобы юзер мог не парится вопросами передачи данных между плагинами. Надо различать внутренние проблемы алгоритмов и юзерскую часть. Накопление ошибок, это проблема разработчика. Ты, как пользователь, на это никак повлиять не можешь.
Даже если взять любой проект, пересчитать данные в 16 бит и пересвести. Уверяю тебя, ничего криминального со звуком не произойдет. Или вставь на любом треке IDR с транкейтом в 16 бит. В миксе ничего ты не услышишь.
Что касается дитера. Это не лекарство против ошибок округления. Дитер их не отменяет. Это косметическое средство, чтобы сделать их менее заметными на слух. Другими словами это еще более грубая ошибка добавляемая к сигналу, но звучащая приятнее на слух, чем шум квантования. Ключевое слово здесь НА СЛУХ. Применять 24 битный дитер после каждого плагина не только бесполезно но и вредно. Во первых дитер на уровне -144дб элементарно не слышно, зато как раз в последующих вычислениях ошибки и будет накапливаться. Дитер применяется один раз и в самом конце.
Проблемы якобы накопления ошибки при манипулировании фейдерами и использовании плагинов уже лет 7-8 как не существует. С тех пор, как все мультитреки перешли на избыточные внутренние форматы данных.
У
Удалённый пользователь 2234
Guest
<div class='quotetop'>QUOTE(\"supersonic\")</div>
Именно так. Использование более точных форматов данных дает возможность разработчику улучшать качество своих разработок, применяя более сложные алгоритмы в больших объемах, не опасаясь, что в результате этих вычислений накопится существенная ошибка округления.
D
Dmitry Polyakov
Guest
Вижу,здесь тоже баталии о форматах. Кратко,чтобы не затевать больших дискуссий.
1. Процессоры Intel давно имеют 32-разрядные форматы представления данных, как целочисленные (fixed), так и с плавающей запятой (float), давно имеют встроенные матпроцессоры, всегда работающие с форматом float, появилась возможность работать с 64-bit fixed форматом.
2. Переход на 32-bit float сам по себе не дает преимуществ перед 32 fixed, при условии, что вычисления в 32-fixed реализованы грамотно, а это требует усилий и знаний теории дискретных операций. По сравнению же с 16-bit fixed формат 32-bit float всегда имеет преимущество, за исключением особо контрастных случаев очень тщательной реализации в 16-bit fixed и грубых ошибок при реализации алгоритма в 32-bit float.
3. К сожалению, времена тщательной разработки аппаратных реализаций, когда в распоряжении программистов были только 16-bit/24-bit fixed DSP, требовался грамотный подход к выбору алгоритмов, масштабированию данных/промежуточных результатов, применения поблочно-плавающих форматов, т.е. ко всему тому, что ведет к снижению погрешностей, ушли. Львиная доля современных плагинописателей даже не пытается реализовывать весь процесс вычислений в формате 32-bit/64 бит fixed. Такие вычисления принципиально будут выполняться гораздо быстрее, т.к. сумматор и матричный умножитель работают как жесткая электрическая схема, а вычисления с плавающей запятой всегда требуют несколько стадий выполнения по небольшой, но все же программе вычислений, в которой само по себе суммирование/умножение являются одной из стадий. Операция деления в алгоритмах используется редко, в некоторых ее нет вообще, в других - заменена умножением на обратную величину.
Но писать плагины таким образом невыгодно по экономическим соображениям, проще применять 32-bit/64-bit float и предложить пользователю купить более мощный PC. Поскольку реально ни с какого АЦП (максимум- это 22 действительных бита в лабораторных условиях сродни поискам гравитационных волн) не будет больше чем 15-17 действительных бит, то в большинстве случаев достаточен 16-bit fixed формат для записи входных данных, с отбросом младших разрядов АЦП, конечно, с максимальным динамическим диапазоном, настроенном органами регулировки в АНАЛОГОВОЙ приемной части и на выходах источника звука.
А вот хранение промежуточных лучше делать в 32-bit float. Незачем терять значащие разряды при экспандировании динамического диапазона в процессе обработки, до перехода в аналог. Нельзя сказать, что хранить в 16-bit fixed промежуточные данные совсем нельзя. Уровень внесенных погрешностей при конвертировании будет зависить от конкретной схемы обработки, и если не хотеть ломать на этим голову - то нужно использовать 32-bit float. В принципе, нормализованные данные могли бы отлично храниться в 24/32-bit fixed, но это снижает скорость работы, т.к требует преобразований форматов.
4. 64-бит float всегда будет работать лучше (с точки зрения погрешностей) чем 16/32-bit fixed, но скорость выполнения будет существенно меньше. Опять-таки, при грамотной реализации 32-bit fixed этот формат, с учетом типов применяемых в обработке звука операций/алгоритмов и физических ограничений АЦП/ЦАП, был бы оптимальным.
Ну если только вы не строите сеть из 100 дорожек и 200 плагинов... Гигантомания в этом вопросе расцвела высоко и далеко, оставив музыку далеко позади себя.
5. Про цифровое микширование я писал в другом форуме, кратко - если вы используете как сумматор компьютер, выводите конечный результат по ОДНОМУ каналу ЦАП, у вас больше 8-10 дорожек, то можете все, что здесь, написано, не читать, т.к смысла в этом не будет. При таком микшировании вы внесете такие искажения в сигнал, что нюансы с форматами, при разумном использовании обработки/плагинов в PC, уже будут величиной меньшего порядка. Если же вы привыкли использовать по 100 плагинов - микшируйте как хотите, т.к качественного звука уже не будет принципиально, потому что бездумно применяя миллиарды, пусть даже линейных, операций к дискретным данным, вы последовательно отбеливаете спектр, финалом чего будет практически некоррелированный шумоподобный сигнал. Слушая многие опусы, можно сделать вывод, что это удается достигнуть уже всего лишь на 2-м миллиарде сложений/умножений.
Дмитрий Поляков.
http://musphere.narod.ru
1. Процессоры Intel давно имеют 32-разрядные форматы представления данных, как целочисленные (fixed), так и с плавающей запятой (float), давно имеют встроенные матпроцессоры, всегда работающие с форматом float, появилась возможность работать с 64-bit fixed форматом.
2. Переход на 32-bit float сам по себе не дает преимуществ перед 32 fixed, при условии, что вычисления в 32-fixed реализованы грамотно, а это требует усилий и знаний теории дискретных операций. По сравнению же с 16-bit fixed формат 32-bit float всегда имеет преимущество, за исключением особо контрастных случаев очень тщательной реализации в 16-bit fixed и грубых ошибок при реализации алгоритма в 32-bit float.
3. К сожалению, времена тщательной разработки аппаратных реализаций, когда в распоряжении программистов были только 16-bit/24-bit fixed DSP, требовался грамотный подход к выбору алгоритмов, масштабированию данных/промежуточных результатов, применения поблочно-плавающих форматов, т.е. ко всему тому, что ведет к снижению погрешностей, ушли. Львиная доля современных плагинописателей даже не пытается реализовывать весь процесс вычислений в формате 32-bit/64 бит fixed. Такие вычисления принципиально будут выполняться гораздо быстрее, т.к. сумматор и матричный умножитель работают как жесткая электрическая схема, а вычисления с плавающей запятой всегда требуют несколько стадий выполнения по небольшой, но все же программе вычислений, в которой само по себе суммирование/умножение являются одной из стадий. Операция деления в алгоритмах используется редко, в некоторых ее нет вообще, в других - заменена умножением на обратную величину.
Но писать плагины таким образом невыгодно по экономическим соображениям, проще применять 32-bit/64-bit float и предложить пользователю купить более мощный PC. Поскольку реально ни с какого АЦП (максимум- это 22 действительных бита в лабораторных условиях сродни поискам гравитационных волн) не будет больше чем 15-17 действительных бит, то в большинстве случаев достаточен 16-bit fixed формат для записи входных данных, с отбросом младших разрядов АЦП, конечно, с максимальным динамическим диапазоном, настроенном органами регулировки в АНАЛОГОВОЙ приемной части и на выходах источника звука.
А вот хранение промежуточных лучше делать в 32-bit float. Незачем терять значащие разряды при экспандировании динамического диапазона в процессе обработки, до перехода в аналог. Нельзя сказать, что хранить в 16-bit fixed промежуточные данные совсем нельзя. Уровень внесенных погрешностей при конвертировании будет зависить от конкретной схемы обработки, и если не хотеть ломать на этим голову - то нужно использовать 32-bit float. В принципе, нормализованные данные могли бы отлично храниться в 24/32-bit fixed, но это снижает скорость работы, т.к требует преобразований форматов.
4. 64-бит float всегда будет работать лучше (с точки зрения погрешностей) чем 16/32-bit fixed, но скорость выполнения будет существенно меньше. Опять-таки, при грамотной реализации 32-bit fixed этот формат, с учетом типов применяемых в обработке звука операций/алгоритмов и физических ограничений АЦП/ЦАП, был бы оптимальным.
Ну если только вы не строите сеть из 100 дорожек и 200 плагинов... Гигантомания в этом вопросе расцвела высоко и далеко, оставив музыку далеко позади себя.
5. Про цифровое микширование я писал в другом форуме, кратко - если вы используете как сумматор компьютер, выводите конечный результат по ОДНОМУ каналу ЦАП, у вас больше 8-10 дорожек, то можете все, что здесь, написано, не читать, т.к смысла в этом не будет. При таком микшировании вы внесете такие искажения в сигнал, что нюансы с форматами, при разумном использовании обработки/плагинов в PC, уже будут величиной меньшего порядка. Если же вы привыкли использовать по 100 плагинов - микшируйте как хотите, т.к качественного звука уже не будет принципиально, потому что бездумно применяя миллиарды, пусть даже линейных, операций к дискретным данным, вы последовательно отбеливаете спектр, финалом чего будет практически некоррелированный шумоподобный сигнал. Слушая многие опусы, можно сделать вывод, что это удается достигнуть уже всего лишь на 2-м миллиарде сложений/умножений.
Дмитрий Поляков.
http://musphere.narod.ru
Dmitry Polyakov 1. Процессоры Intel давно имеют 32-разрядные форматы...
АГА, только процессоры интел и умеют...
Некорректненько как то... :lol:
АГА, только процессоры интел и умеют...
Некорректненько как то... :lol:
D
Dmitry Polyakov
Guest
_________Originally posted by mexap
Dmitry Polyakov 1. Процессоры Intel давно имеют 32-разрядные форматы...
АГА, только процессоры интел и умеют...
Что умеют и что некорректно ? Что большинство PC в мире работает на процессорах, имеющих расширенную архитектуру прототипов Intel iAPX x86? А если речь о картах с DSP, то это сути абсолютно не меняет, среда разработки весьма унифицированна по отношению к специализации процессора (теперь, на радость писателям), разве что добавляется регистр-аккумулятор N+8, а представительский уровень в 7-level OSI остается прежним. Все вещи, связанные с погрешностью, стилем создания программ, микшированием и перегрузкой плагинами, остаются на месте.
Дмитрий Поляков.
http://musphere.narod.ru
<div class='quotetop'>QUOTE(\"Dmitry Polyakov\")</div>
Это почему? Можно ссылочку или аргументацию?
1. Между прочим ЦАП не задействуется при микшировании в хосте, как собственно многие и миксят.
2. И как же при таких чудовищных ошибках миксования 30-50 треков я у себя слышу разницу от типа использованного эквалайзера на барабанных треках (lin phase, обычный)?
D
Dmitry Polyakov
Guest
Originally posted by mexap
1. Между прочим ЦАП не задействуется при микшировании в хосте, как собственно многие и миксят.
2. И как же при таких чудовищных ошибках миксования 30-50 треков я у себя слышу разницу от типа использованного эквалайзера на барабанных треках (lin phase, обычный)?
______________
Представьте, что вы выкрутили ручку noise на синтезаторе, на полную. А дальше по муговской схеме фильтр. С резонансом. Вы услышите разницу звучания шума с резонансом и без ? Услышите. Аналогия понятна ? Нет прямой связи между тем, какие искажения вы уже внесли в сигнал из-за округлений и т.д., и будут ли чувствоваться ушами параметры дальнейшей обработки такого сигнала. Речь идет о вкладе каждой составляющей и о тонком пороге, при котором звучание еще профессиональное.
Дмитрий Поляков.
http://musphere.narod.ru
D
Dmitry Polyakov
Guest
_____________Originally posted by mexap
1. Между прочим ЦАП не задействуется при микшировании в хосте, как собственно многие и миксят.
2. И как же при таких чудовищных ошибках миксования 30-50 треков я у себя слышу разницу от типа использованного эквалайзера на барабанных треках (lin phase, обычный)?
А насчет ЦАП - уже начался испорченый телефон форума. Я прекрасно знаю, что используется, а что нет, и читать между строк то, чего нет, не обязательно. Я написал точную формулировку. Почему это так - см. другое сообщение.
Дмитрий Поляков.
http://musphere.narod.ru
D
Dmitry Polyakov
Guest
_____________
Уже все давно аргументировано. Читайте здесь:
http://www.muzoborudovanie.ru/forum/view.p...%E2%E0%ED%E8%E5
Заранее говорю, знаю про дитер и т.д. и т.п. Но у студийных приборов все равно будет много аналоговых выходов, именно по причине, указанной мной в статье.
Тем, кто хочет быстро и сверхпонятно, читать не обязательно, чтобы не расстраиваться из-за "бредней".
Моя задача здесь не в начинании годового курса дискретной математики, теории цифровой обработки сигналов и т.д., я сам многому еще могу поучиться.
Я вижу, вы инженер, что вы появляетесь на этом форуме, значит, имеет место быть некий интерес к музыке. Если не затруднит, прочитайте вот эту небольшую заметку. Что является целью, будет ясно из прочитанного.
http://musphere.narod.ru/projects.html
Дмитрий Поляков.