Попробуем вспомнить занятия по всей ентой хрени. И попробуем на пальцах объяснить.
Ежели мне память не изменяет, то просчет с применением метода плавающей запятой, нужен для увеличения точности вычислений и, соответственно, уменьшения погрешности.
Звук в компе представлен в виде нулей и единиц, просчет также ведется в этой системе исчисления. Теперь, представь, самый громкий звук в виде 16-ти единиц (это для 16-битного представления), самый тихий - одна единичка и 15-ть нулей. При обработке плагином самого громкого места пусть останутся те же самые 16-ть единиц, а вот на самом тихом месте единичка может превратиться в нуль. Ерунда? Я бы не сказал. Если ты будешь просчитывать звук плагинами не в пакете (за один проход), а последовательно - сначала компрессором, например, потом ревером, и т.п., то ошибочка набежит конкретная, слышна будет даже "невооруженным" ухом...
Что такое погрешность при просчете аудио? Шумы, шелчки и прочая хрень. Как от нее избавиться? Тот же самый звук делиться не на 16 кусочков (нулей и единиц), а на 24. Теперь мы получаем хорошее качество, да и погрешность, если и случится такая бяка, может быть и не заметна на слух. На самом деле там куча всяких математических выкладок, но ими можно мозги не забивать, главное осознать, что 24 лучше 16
Это как мерить мелкую деталь обычной линейкой или микрометром, точнее будет конечно последний - у него шкала на десятые доли миллиметнов поделена....
Идем дальше. При 24-битной обработке ошибочки все-таки могут появиться. Естественно, человеку пришла в голову мысля уйти от них так же, как и от 16-битных погрешностей. То есть, 32 бита для представления аналогового звука в цифровом виде... А 32 бита с плавающей точкой... Ну, это как бутерброд с маслом и колбасой, или с маргарином и колбасой - результат один - сытый желудок
В идеале, конечно, надо бы писать сразу в 32 с плавающей. Но, отцифровщик-то все-равно входной сигнал будет рубить на 16 или 24 бита (вот первая ошибка, на которую потом будет накапливаться остальные ошибки при обработках). Потом перевод из 16(24) в 32... Потом использование плагинов с внутренней обработкой в 16 или 24 бита... Потом перевод обратно в 32. Потом мастер в 16 бит для нарезки СД... Это упрощенно-укороченная цепочка, а на самом деле все может быть еще хуже...
Поэтому, лучше использовать хорошие отцифровщики, юзать проги и плагины с 32-битным просчетом (для этого есть пара-тройка плагинов, проверяющих внутреннюю разрядность плагов), и использовать дитеринг и нойз-шейпинг для маскировки шумов, получившихся при просчетах с ошибочками...
Более подробно об этом мона почитать в "шоу-мастерах" и "звукорежиссерах", а также спросить у г-на Лакина (надеюсь, с фамилией я не ложанулся), который иногда заскакивал на этот форум, и который разработал систему дитеринга, используемую в третьем озоне....
)
