FAQ-АЦП, биты, платы и уровень записи

Тема в разделе "FAQ/HELP", создана пользователем sunet, 2 авг 2006.

  1. supersonic

    supersonic Well-Known Member

    Регистрация:
    17 июл 2004
    Сообщения:
    1.981
    Симпатии:
    800
    Адрес:
    Москва
    Вот именно об этом я и твержу. Средний пользователь не понимает как устроена программа, но ведется на громкие слова типа 64 битный движок. А вот досточтимый г-н Лукин на одном из форумов даже подсчитывал ошибку которая возникает при суммировании 10 каналов для разных битностей. Уровень шума там был порядка -140-160db. Не так страшен черт как его малюют.
     
  2. Hyper

    Hyper Trance music abused

    Регистрация:
    25 май 2006
    Сообщения:
    1.950
    Симпатии:
    444
    Род занятий:
    Музыка, регистрация Юр. лиц.
    Адрес:
    Москва
    Я вот непонимаю, что мы тут воду в ступе толчём... Вопрос: Писать или не писать в 32fp? Ответ: Писать! А почему? А потому, что хуже от этого никому не будет. Даже если PT и другие некоторые студийные программы его не понимают. Пишите! Переконвертировать из 32 в 24 лучше чем из 24 в 32. Это факт! И переконвертировать никогда не поздно. Как говорится "фарш назад не провернёшь"...
     
  3. Ifrit

    Ifrit Guest

    <div class='quotetop'>QUOTE(\"Hyper\")</div>
    Чем лучше-то?
     
  4. supersonic

    supersonic Well-Known Member

    Регистрация:
    17 июл 2004
    Сообщения:
    1.981
    Симпатии:
    800
    Адрес:
    Москва
    Ну уж извините. Если кому-то достаточно идульгенции чужого авторитетного мнения, ради бога. А я хочу знать предмет и понимать происходящие процессы, чтобы пользоваться ими осознанно. Только так всю жизнь и работаю. А чужое мнение бывает и ошибочным, даже не смотря на авторитет.
     
  5. sunet

    sunet Victor Buruiana, 1959

    Регистрация:
    18 июл 2005
    Сообщения:
    9.149
    Симпатии:
    3.802
    Пол:
    Мужской
    Род занятий:
    music, recording, acoustic, radio
    Адрес:
    Chisinau, Moldova
    В скольких форумах этот вопрос обсуждали, он так и оставался открытим...
     
  6. Hyper

    Hyper Trance music abused

    Регистрация:
    25 май 2006
    Сообщения:
    1.950
    Симпатии:
    444
    Род занятий:
    Музыка, регистрация Юр. лиц.
    Адрес:
    Москва
    supersonic

    Т.е. под вопрос ставится предмет преимущества 32 над 24?
     
  7. supersonic

    supersonic Well-Known Member

    Регистрация:
    17 июл 2004
    Сообщения:
    1.981
    Симпатии:
    800
    Адрес:
    Москва
    Нет, вопрос для каких именно целей это преимущество оправдано и СЛЫШНО ушами.
     
  8. Hyper

    Hyper Trance music abused

    Регистрация:
    25 май 2006
    Сообщения:
    1.950
    Симпатии:
    444
    Род занятий:
    Музыка, регистрация Юр. лиц.
    Адрес:
    Москва
    Для целей обработки фонограммы это точно. Ну и записи. Хотя остальные преимущества это скорее самовнушение.
     
  9. supersonic

    supersonic Well-Known Member

    Регистрация:
    17 июл 2004
    Сообщения:
    1.981
    Симпатии:
    800
    Адрес:
    Москва
    Хорошо... Кручу в третий раз.

    Проделай, пожалуйста, простой тест.

    Существующие конвертеры пока 24 битные.

    1. Возьми любой 24 битный файл или оцифруй с конвертера.
    2. Сделай его копию в формате 32 float
    3. Обработай одним и тем же EQ с одинаковыми настройками.
    4. Ковертни в 24 (конвертер воспроизводит только целочисленный формат, это то что ты слышишь).
    5. Cложи в противофазе.

    Результат 0. Побитная идентичность.

    Можно загнать 24бит файл и его 32float копию на соседние дорожки в Кубейсе, вставить в инсерты одинаковые EQ и у одной дорожки инвертировать фазу. На выходе тишина.

    Можно вставить использовать родные кубейсовскиt 32float EQ, можно, скажем Waves, у которых внутренняя математика 48 fixed, можно Voxengo, которые 64 float. Результат одинаковый.

    Формат данных никак не влияет на обработку плагинами.

    В принципе из одного этого теста можно много понять о том, как устроен Кубейс, как он взаимодействует с плагинами, чего он может, а чего нет.
     
  10. Phone Cuts

    Phone Cuts New Member

    Регистрация:
    7 сен 2004
    Сообщения:
    10.205
    Симпатии:
    1.285
    Род занятий:
    Graphic Design and Development
    Адрес:
    Toronto, CA
    а можно по-подробнее?:)
     
  11. supersonic

    supersonic Well-Known Member

    Регистрация:
    17 июл 2004
    Сообщения:
    1.981
    Симпатии:
    800
    Адрес:
    Москва
  12. sunet

    sunet Victor Buruiana, 1959

    Регистрация:
    18 июл 2005
    Сообщения:
    9.149
    Симпатии:
    3.802
    Пол:
    Мужской
    Род занятий:
    music, recording, acoustic, radio
    Адрес:
    Chisinau, Moldova
    Интересно...
     
  13. dugdum®

    dugdum® собака павлова

    Регистрация:
    12 янв 2005
    Сообщения:
    2.330
    Симпатии:
    968
    Адрес:
    Москва, ЮАО
    supersonic,
    браво! :)
    для меня больше всего удивительно что два эквалайзера горб/яма взаимокомпенсируются, ну никак не ожидал...
     
  14. sunet

    sunet Victor Buruiana, 1959

    Регистрация:
    18 июл 2005
    Сообщения:
    9.149
    Симпатии:
    3.802
    Пол:
    Мужской
    Род занятий:
    music, recording, acoustic, radio
    Адрес:
    Chisinau, Moldova
    Может быть я и не прав, это только так, полуночная мысль, но может все совпадает потому что один файл сделан из другого, т.е. это вообще один и тот же файл, а если бы он был записан сразу как 32-й может получилось бы иначе. И кстати что из чего 32 из 24-х, или 24 из 32-х получено? Во втором случае не было бы несколько иначе?
     
  15. dugdum®

    dugdum® собака павлова

    Регистрация:
    12 янв 2005
    Сообщения:
    2.330
    Симпатии:
    968
    Адрес:
    Москва, ЮАО
    <div class='quotetop'>QUOTE(\"sunet\")</div>
    не получилось бы. потому что преобразование 24 int -> 32 float без каких либо потерь протекает. с точки зрения самих данных файлы идентичны. ну и конечно если с 32 float ничего не делать, после преобразования обратно получим оригинал.
     
  16. supersonic

    supersonic Well-Known Member

    Регистрация:
    17 июл 2004
    Сообщения:
    1.981
    Симпатии:
    800
    Адрес:
    Москва
    24>32. При записи происходит абсолютно идентичный процесс. Конвертер цифрует в 24, а в 32 переводится на лету программно.

    Кроме того, dugdum уже ответил, и я повторюсь, что точность отображения данных, она же разрешение волны по вертикали, в 24 fixed и 32 float идентична и равняется 2^23=8388608 дискретных уровня на знак.
     
  17. supersonic

    supersonic Well-Known Member

    Регистрация:
    17 июл 2004
    Сообщения:
    1.981
    Симпатии:
    800
    Адрес:
    Москва
    Поскольку до сих не все понимают принцип арифметики с плавающей точкой применительно к аудио, возьму на себя труд объяснить это в популярной форме букваря с картинками.. :biglaugh:

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

    [​IMG]

    В целочисленной модели аудио количество "ступенек" по вертикальной оси определяется числом бит. Чем мельче ступеньки, тем лучше качество.

    Для 16 бит их будет 2^15=32768 уровней по вертикали, для 24 бит 2^23=8388608 уровней. Порог различимости человеческого слуха лежит на уровне порядка 20 бит. Т.е. для предельного качества достаточно "нарисовать" волну 2^19=524288 уровнями.

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

    Уменьшение громкости на ~6 дб и повторное увеличение на 6дб съедает 1 бит. Соответственно если в 24битном файле уменьшить громкость на 72 дб,

    [​IMG]

    а потом нормализовать, количество "ступенек" уменьшится вдвое.

    [​IMG]
     
  18. supersonic

    supersonic Well-Known Member

    Регистрация:
    17 июл 2004
    Сообщения:
    1.981
    Симпатии:
    800
    Адрес:
    Москва
    Чтобы компенсировать такие потери и было решено использовать формат данных с плавающей точкой. В этом случае количество возможных уровней у 24 fixed и 32 float одинаково и равно 2^23=8388608. Дополнительные 8 бит задают мастштабирующий коэффициент, поэтому в этом формате возможно уменьшить громкость, но сохранить при этом исходную детализацию, т.е. количество "ступенек" остается неизменным.

    [​IMG]

    Т.о. становится возможным изменять громкость без изменения разрешения волны.
     
  19. J_on

    J_on Active Member

    Регистрация:
    19 ноя 2004
    Сообщения:
    2.034
    Симпатии:
    20
    Адрес:
    Москва
    supersonic
    Правильно ли я понимаю, и сказанного тобой и выше товарищем Лукиным следует, что писать в формате 32 не критично, а вот обработка только 32, что собственно и есть в например куню.

    Зы В тулзе внутренняя шина 24 или 32?
     
  20. Ifrit

    Ifrit Guest

    <div class='quotetop'>QUOTE(\"J_on\")</div>
    48 fixed начиная с версии (вроде бы) 5.1
     
  21. Цыхра

    Цыхра Well-Known Member

    Регистрация:
    19 июн 2003
    Сообщения:
    4.516
    Симпатии:
    3.424
    Пол:
    Мужской
    supersonic
    Что-то у тебя на третей картинке и частота дискретизации уменьшилась )))
     
  22. insane

    insane Well-Known Member

    Регистрация:
    6 сен 2004
    Сообщения:
    1.156
    Симпатии:
    128
    Пол:
    Мужской
    Адрес:
    Москва
    Ниче не уменьшилось, как было 32 отсчета так и осталось
     
  23. Цыхра

    Цыхра Well-Known Member

    Регистрация:
    19 июн 2003
    Сообщения:
    4.516
    Симпатии:
    3.424
    Пол:
    Мужской
  24. Ifrit

    Ifrit Guest

    Вот, наткнулся у себя, может кому интересно/полезно будет. Вложение - White Paper по ПТ шине/микшеру.
     
  25. insane

    insane Well-Known Member

    Регистрация:
    6 сен 2004
    Сообщения:
    1.156
    Симпатии:
    128
    Пол:
    Мужской
    Адрес:
    Москва
    Цыхра
    В исходном сигнале http://img139.imageshack.us/img139/743/1xv0.gif 32 отсчета.
    При уменьшении амплитуды в результате округления каждая вторая ступенька "теряется" (округляется до уровня предыдущей). http://img321.imageshack.us/img321/4727/2qf8.gif
    Количество отсчетов остается прежним.
    При пересчете с помощью float округления нет, поэтому ступеньки сохраняются.
    Для наглядности отсчеты нужно было показать точками а не линиями...
     
  26. insane

    insane Well-Known Member

    Регистрация:
    6 сен 2004
    Сообщения:
    1.156
    Симпатии:
    128
    Пол:
    Мужской
    Адрес:
    Москва
    Не, ну в реальности конечно все не так страшно, при однократном преобразовании много не потеряешь. Но если преобразований много, то ошибки начнут накапливаться и даже это "чуть-чуть" выльется в цифровой шум и прочие артефакты.

    А вот пример как выглядит треугольник на -60dB в аудишене. Заметьте, тут мешает именно недостаток битности. Сэмплы можно подвигать руками и наглядно видно, насколько они дискретны. В 32float такой проблемы нет.

    Другое дело, что практически во всех программах внутренняя обработка идет в 48/64бит или в 32float, так что особо волноваться нечего :smile:
     
  27. Цыхра

    Цыхра Well-Known Member

    Регистрация:
    19 июн 2003
    Сообщения:
    4.516
    Симпатии:
    3.424
    Пол:
    Мужской
    ступил-с, прдон-с
     
  28. NickCrow

    NickCrow engineer

    Регистрация:
    23 янв 2005
    Сообщения:
    849
    Симпатии:
    1.237
    Пол:
    Мужской
    <div class='quotetop'>QUOTE(\"supersonic\")</div>
    <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.
     
  29. dugdum®

    dugdum® собака павлова

    Регистрация:
    12 янв 2005
    Сообщения:
    2.330
    Симпатии:
    968
    Адрес:
    Москва, ЮАО
    2. z3ta - 2x oversampling;

    мимо =)
     
  30. NickCrow

    NickCrow engineer

    Регистрация:
    23 янв 2005
    Сообщения:
    849
    Симпатии:
    1.237
    Пол:
    Мужской
    <div class='quotetop'>QUOTE(\"dugdum®\")</div>
    Возможно. Сейчас под рукой нет z3ta и его описания. Если у Вас есть точная информация по этому режиму - поделитесь.
    По пунктам 1 и 3 возражений нет?
     
  31. dugdum®

    dugdum® собака павлова

    Регистрация:
    12 янв 2005
    Сообщения:
    2.330
    Симпатии:
    968
    Адрес:
    Москва, ЮАО
    да неизвесно что там происходит. оверсемплинг в z3ta+ это как бы увеличение частоты дискретизации внутри плагина... что происходит в других плагинах неизвестно. скорее всего точность мат моделей/ресурсоемкость увеличивают, к битности это врядли имеет отношение. для звука мало значения имеет 32 там или 64...
     
  32. dugdum®

    dugdum® собака павлова

    Регистрация:
    12 янв 2005
    Сообщения:
    2.330
    Симпатии:
    968
    Адрес:
    Москва, ЮАО
    послушай кстати z3ta на 44 кГц и на 96 кГц, это как два разных синтезатора по качеству.
     
  33. NickCrow

    NickCrow engineer

    Регистрация:
    23 янв 2005
    Сообщения:
    849
    Симпатии:
    1.237
    Пол:
    Мужской
    <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) для обеспечения необходимой точности вычислений. Вопрос: почему мы должны понижать точность вычислений при обработке звука и не использовать все предоставленные нам возможности (при наличии, естественно, ресурсов)?
     
  34. dugdum®

    dugdum® собака павлова

    Регистрация:
    12 янв 2005
    Сообщения:
    2.330
    Симпатии:
    968
    Адрес:
    Москва, ЮАО
    я в арт акустиксе не слышу улучшений звука, когда нажимаешь эту кнопку (кастрюля она кастрюля и есть =). насчет гитар рига не знаю, не стоит он у меня. вот в z3ta от оверсемплинга явно есть эффект.

    <div class='quotetop'>QUOTE(\"NickCrow\")</div>
    а почему мы должны их повышать и больше рассходовать ресурсы если на слух не наступает улучшения?
     
  35. NickCrow

    NickCrow engineer

    Регистрация:
    23 янв 2005
    Сообщения:
    849
    Симпатии:
    1.237
    Пол:
    Мужской
    Простой пример, позволяющий понять - зачем нужна высокая точность при вычислениях. Чтобы было понятнее - пример с использованием привычных всем десятичной системы и десятичных дробей.
    Результат деления 1 на 3 при использовании вышеприведенных систем будет всегда только приблизительным = 0,333333 (3 в периоде) и точность полученного результата будет зависеть от количества этих троек, которые мы можем сохранить. Т.е. в приведенном примере видно, что результат даже очень простой операции может быть приблизительным и в последующие операции передается округленным. А если таких операций несколько миллионов?
     
  36. dugdum®

    dugdum® собака павлова

    Регистрация:
    12 янв 2005
    Сообщения:
    2.330
    Симпатии:
    968
    Адрес:
    Москва, ЮАО
    ну и? если разницы не слышно, то что, какой вывод?

    очередная надуманная проблема.

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

    надо 64 бита, да ради бога, например Traktion 2 уже имеет такой микшер (галочку надо поставить).
    только толку от этого ноль.
     
  37. sunet

    sunet Victor Buruiana, 1959

    Регистрация:
    18 июл 2005
    Сообщения:
    9.149
    Симпатии:
    3.802
    Пол:
    Мужской
    Род занятий:
    music, recording, acoustic, radio
    Адрес:
    Chisinau, Moldova
    Уважаемые админы! Вижу дебаты закончились, корректировки вроде сделал, так что если кто правописание проверит, можно перекидывать в FAQ.
     
  38. supersonic

    supersonic Well-Known Member

    Регистрация:
    17 июл 2004
    Сообщения:
    1.981
    Симпатии:
    800
    Адрес:
    Москва
    Понижать не надо. Но и завышать без причин нет смысла. Потому что в конечном итоге точность результата у нас ограничена определенным количеством знаков. Если результат деления 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.
     
  39. daicehawk

    daicehawk овес-тодорогнеукупишь

    Регистрация:
    9 июл 2004
    Сообщения:
    3.086
    Симпатии:
    520
    Род занятий:
    технический писатель
    Адрес:
    Ярославль\оч редко Европа типа Осло
    supersonic вот-вот , я с 20 поста об этом талдычу
     
  40. Stalewar

    Stalewar New Member

    Регистрация:
    13 июл 2005
    Сообщения:
    841
    Симпатии:
    31
    Адрес:
    Москва
    Я вот когдато и задавал вопрос именно такого смысла ХДЕ ДАКАЗАТЕЛЬСТВА когда разработчик заявляет о поддержки плагином количества бит.Ведь если последовательно включенно несколько плагинов и один поддерживает только 24,другой 32 а другой вообще втесался с 16 бит(например) и таких в разнобой 5-10 штук.Ну как известно шум квантования при 24-32 битах ничтожно мал.Но если при постройке Небоскреба на каждом этаже ошибаться на 5 см то вверху уйдут метры.Согласен, пример плохой,но смысл в моем вопросе тот же.Если в куб начинает пересчитывать после каждого плага (например) в 32 бита а каждый последующий плагин обратно в свой режим работы,не многовато ли будет каки? Транкейт еще однако.Учат, типа после одного пересчета применить нойзшепинг и т.п. а тут целых 20 и получается без нойзшейпинга и остальной радости:rolleyes:
     
  41. supersonic

    supersonic Well-Known Member

    Регистрация:
    17 июл 2004
    Сообщения:
    1.981
    Симпатии:
    800
    Адрес:
    Москва
    Когда говорят о накоплении ошибок имеют в виду то что происходит при расчетах ВНУТРИ плагина. Там данные могут проходить тысячи и миллионы циклических пересчетов. Но повода для паранойи нет, не надо за каждым углом видеть притаившуюся ошибку округления. То, что повседневно делает юзер в кубейсе, кручение фейдеров громкости, ручек панорамы, эквалайзеров и плагинов никаких страшных ошибок наделать не может.

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

    Даже если взять любой проект, пересчитать данные в 16 бит и пересвести. Уверяю тебя, ничего криминального со звуком не произойдет. Или вставь на любом треке IDR с транкейтом в 16 бит. В миксе ничего ты не услышишь.

    Что касается дитера. Это не лекарство против ошибок округления. Дитер их не отменяет. Это косметическое средство, чтобы сделать их менее заметными на слух. Другими словами это еще более грубая ошибка добавляемая к сигналу, но звучащая приятнее на слух, чем шум квантования. Ключевое слово здесь НА СЛУХ. Применять 24 битный дитер после каждого плагина не только бесполезно но и вредно. Во первых дитер на уровне -144дб элементарно не слышно, зато как раз в последующих вычислениях ошибки и будет накапливаться. Дитер применяется один раз и в самом конце.

    Проблемы якобы накопления ошибки при манипулировании фейдерами и использовании плагинов уже лет 7-8 как не существует. С тех пор, как все мультитреки перешли на избыточные внутренние форматы данных.
     
  42. NickCrow

    NickCrow engineer

    Регистрация:
    23 янв 2005
    Сообщения:
    849
    Симпатии:
    1.237
    Пол:
    Мужской
    <div class='quotetop'>QUOTE(\"supersonic\")</div>
    Именно так. Использование более точных форматов данных дает возможность разработчику улучшать качество своих разработок, применяя более сложные алгоритмы в больших объемах, не опасаясь, что в результате этих вычислений накопится существенная ошибка округления.
     
  43. Вижу,здесь тоже баталии о форматах. Кратко,чтобы не затевать больших дискуссий.
    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
     
  44. mexap

    mexap Well-Known Member

    Регистрация:
    7 ноя 2004
    Сообщения:
    2.479
    Симпатии:
    1.135
    Адрес:
    Н.Новгород
    Dmitry Polyakov 1. Процессоры Intel давно имеют 32-разрядные форматы...

    АГА, только процессоры интел и умеют... :cool: Некорректненько как то... :lol:
     
  45. _________
    Что умеют и что некорректно ? Что большинство PC в мире работает на процессорах, имеющих расширенную архитектуру прототипов Intel iAPX x86? А если речь о картах с DSP, то это сути абсолютно не меняет, среда разработки весьма унифицированна по отношению к специализации процессора (теперь, на радость писателям), разве что добавляется регистр-аккумулятор N+8, а представительский уровень в 7-level OSI остается прежним. Все вещи, связанные с погрешностью, стилем создания программ, микшированием и перегрузкой плагинами, остаются на месте.

    Дмитрий Поляков.

    http://musphere.narod.ru
     
  46. Alexey Lukin

    Alexey Lukin Well-Known Member

    Регистрация:
    11 июн 2003
    Сообщения:
    1.904
    Симпатии:
    1.174
    <div class='quotetop'>QUOTE(\"Dmitry Polyakov\")</div>
    Это почему? Можно ссылочку или аргументацию?
     
  47. mexap

    mexap Well-Known Member

    Регистрация:
    7 ноя 2004
    Сообщения:
    2.479
    Симпатии:
    1.135
    Адрес:
    Н.Новгород
    1. Между прочим ЦАП не задействуется при микшировании в хосте, как собственно многие и миксят.
    2. И как же при таких чудовищных ошибках миксования 30-50 треков я у себя слышу разницу от типа использованного эквалайзера на барабанных треках (lin phase, обычный)? :eek:
     
  48. ______________
    Представьте, что вы выкрутили ручку noise на синтезаторе, на полную. А дальше по муговской схеме фильтр. С резонансом. Вы услышите разницу звучания шума с резонансом и без ? Услышите. Аналогия понятна ? Нет прямой связи между тем, какие искажения вы уже внесли в сигнал из-за округлений и т.д., и будут ли чувствоваться ушами параметры дальнейшей обработки такого сигнала. Речь идет о вкладе каждой составляющей и о тонком пороге, при котором звучание еще профессиональное.

    Дмитрий Поляков.

    http://musphere.narod.ru
     
  49. _____________
    А насчет ЦАП - уже начался испорченый телефон форума. Я прекрасно знаю, что используется, а что нет, и читать между строк то, чего нет, не обязательно. Я написал точную формулировку. Почему это так - см. другое сообщение.

    Дмитрий Поляков.

    http://musphere.narod.ru
     
  50. _____________
    Уже все давно аргументировано. Читайте здесь:

    http://www.muzoborudovanie.ru/forum/view.p...%E2%E0%ED%E8%E5

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

    Тем, кто хочет быстро и сверхпонятно, читать не обязательно, чтобы не расстраиваться из-за "бредней".

    Моя задача здесь не в начинании годового курса дискретной математики, теории цифровой обработки сигналов и т.д., я сам многому еще могу поучиться.
    Я вижу, вы инженер, что вы появляетесь на этом форуме, значит, имеет место быть некий интерес к музыке. Если не затруднит, прочитайте вот эту небольшую заметку. Что является целью, будет ясно из прочитанного.

    http://musphere.narod.ru/projects.html

    Дмитрий Поляков.
     

Поделиться этой страницей