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

слушай, я не берусь составлять FAQ и формулирую как могу. а тебе не мешает немного заняться самообразованием на тему АЦП. почитать даташиты очень полезно как раз для того, чтобы больше понять о том предмете, о котором ты взял на себя смелость написать сей рукописный труд-предмет топика =)

 

Прости, но я тогда останусь при свем мнении :smile:

 

<div class='quotetop'>QUOTE(\"sunet\")</div>

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

 

<div class='quotetop'>QUOTE(\"dugdum®\")</div>

Так я же и предлагаю - конкретно: - цитата - правильная формулировка. Или я непонятно пишу?

 

<div class='quotetop'>QUOTE(\"dugdum®\")</div>

Кстати о птичках, какие конкретно фразы? а то тут уже проблемы начали обсуждаться которых в факе и нет.

 

"поэтому если конечным продуктом ваших трудов будет CD, то записывать надо сразу в 44100, а если DVD – то 48000 Гц."

сомнительный вывод (объяснил почему)

"и если плата и программа позволяют, безусловно следует записывать именно
в формате 32 float."

считаю это неверным. (объяснил почему выше)

пункт 7, практически весь неправильный и противоречит элементарным законам физики. (тоже объяснил почему)

 

<div class='quotetop'>QUOTE(\"dugdum®\")</div>

Хорошо, обсудим. Как быть дальше? Допустим записываем в 24, а потом? Переключаем проект в 32?

 

<div class='quotetop'>QUOTE(\"sunet\")</div>

зачем? ты про какой хост говоришь? есть внутренняя математика хоста в пространстве которой считается миксинг и обработки, и формат хранения данных на диске не имеет к ней отношения. по крайней мере это так в популярном семействе Cubase/Nuendo.

 

<div class='quotetop'>QUOTE(\"dugdum®\")</div>

Допустим Нюендо. Но зачем тогда там этот формат и почему в стольких статьях все-таки его рекомендуют?

Из моего личного опыта - после перехода на 32 проблемм с какимим-либо искажениями вообще не стало...

 

этот формат там потому чтобы программа его "понимала", ну и миксдаун в 32 float никто не отменял, на этом этапе это действительно имеет смысл делать. записывать данные с АЦП в этом формате смысла нет.

 

Ладно, сейчас исправлю эту формулировку на более нейтральную и пойду спать...

 

По поводу 24 vs 32 dugdum прав. Никакого смысла хранить данные в 32 битах нет. Точность отображения у этого формата в конечном счете равняется тем же 24 битам. Мантисса у 32 бит - 23битная + 1 бит на знак. А лишние 8 бит это порядок степени. Если по-простому, то эти 8 бит нужны фактически только для реализации механизма уровней без клиппинга. Если конечный результат будет в 24 битах, то формат хранения 32float или 24fixed дают совершенно одинаковый результат. Хранение данных в 32float ничего кроме увеличения объема на диске не дает.

PS Лукин по-моему даже где-то в недрах RMM об этом рассказывал.

 

А с чем конкретно ты его сравнивал? Речь идет о сравнении в 16 битном режиме записи или же о 16 vs 24? Да и неплохо бы тест услышать. Все таки AD это не DA, это легко проверить.

 

Так отчего тебе самому не поведать общественности о том, что там написано и какие выводы из этого можно сделать. Не все же даташиты читают.

 

Итак про 32 float я переформулировал, если что не так - подскажите.
Относительно частоты квантования - если кто-нибудь докажет мне что лучше вначале записать на 44100 и потом конвертировать в 48000 или записать в 48000 а потом конвертировать в 44100, т.е. совершать лишнее конвертирование от нечего делать, даже если потери от этого при нынешних математических ухищрениях малы (но зачем?!) то тогда я соглашусь что этот пункт надо менять...
Также и по п.7. Как схемотехник я убежден что из тех же элементов можно сделать хорошие и плохие приборы и что есть платы разного качества и что за качество можно бороться на техническом уровне и потому не вижу что в этом пункте неверно... Докажите мне что лучше брать полупрофессиональную плату чем профессиональную и я этот пункт уберу.

 

<div class='quotetop'>QUOTE(\"dugdum®\")</div>

и ответ в соседнем топе, но как раз в тему

Думаю компетентность Лукина в этом вопросе под сомнение никто не ставит?

 

Не совсем он прав ибо -вот его ответ на вопрос о реализации математики в хосте: преобразование типов данных, необходимое для того чтобы подсунуть VST плагину или хосту информацию в формате 32 bit float для процессора является отдельной операцией, требующей определенных ресурсов. другое дело что если исходник 32 bit float это преобразование скорее всего тоже выполняется, только в холостую,
То есть опять-скорее всего,может быть,вероятно!
Как на самом деле ни кто не знает.

 

dugdum®
sunet

http://www.625-net.ru/archive/z0800/rev1.htm
читать обоим, одному чтобы бессмысленных споров по седьмому пункту не заводить, а второму чтобы соответствующие поправки и дополнения в фак внести.

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

 

на само деле - чтобы вы ни засунули в хост - преобразуется в 32фп. если исходник в 32фп - то никаких преобразований и не будет. проверить легко на "преобразование" - просто загрузить в любой хост 24-битный файл метров так на 100, а потом тот же файл, только в 32фп и сравнить время загрузки

 

Попробую объяснить, для чего нужны 32 bit floating point.
1. Типы данных, которые используются для хранения и обработки аудио (а также и любой другой информации) на PC, выбираются из стандартного набора типов данных, присущих данной компьютерной платфоме (в комплексе: PC железо + система программирования).
- для 16-ти битного представления используется тип signed integer, диапазон значений от -32768 до 32767;
- для 32-ти битного представления используется тип signed long, диапазон значений от -2147483648 до 2147483647;
- для 32-ти битного представления с плавающей точкой используется тип float, диапазон значений от 3.4E-38 до 3.4E+38 (т.е. от 3,4 умноженное на 10 в -38 степени до 3,4 умноженное на 10 в 38 степени);
Сразу прошу обратить внимание, что применение формата с плавающей точкой позволяет значительно расширить возможный диапазон чисел не увеличивая объем данных в байтах.
- для 64-ти битного представления с плавающей точкой используется тип double, диапазон значений от 1.7E-308 до 1.7E+308.
2. При обработке цифрового звука производится много математических операций. Результат очень многих операций округляется, в результате чего происходит накопление погрешности округлений, и какова будет конечная величина погрешности - зависит от количества вычислений и от точности используемого формата данных - поэтому внутренний формат представления данных в большинстве хост-программ 32 бита с плавающей точкой (в последнее время происходит переход на 64 бита с плавающей точкой), но приведенный к диапазону значений от -1 до 1, т.к. многие вычисления, которые производятся при обработке цифрового звука, гораздо удобнее производить с диапазоном чисел от -1 до 1,
Писать треки в проект лучше, все-таки в формате 32 бита с плавающей точкой. Во-первых, вы сразу получаете треки в том же формате, что и внутренний формат хоста и в дальнейшем никаких преобразований "на лету" не потребуется. Во-вторых, все, что сказано выше об погрешностях округления при вычислениях относится не только к работе внутренних алгоритмов хоста и плагинов, но и к деструктивным операциям с аудио-треками, которые иногда приходиться производить и конечная погрешность последовательности нескольких таких операций будет несоизмеримо ниже при использовании 32 бита с плавающей точкой (см. выше диапазоны допустимых значений).

 

NickCrow для этого и есть опции - сохранять временные файлы в 32/64 флоутин пойнт

 

2dugdum
Заявленные параметры АЦП в даташите, это руководство к выбору или нет, данной микросхемы инженера к реальному проекту.
Тебе сказал же хозяин топика, что он рассматривает АЦП в целом ,а не микросхему.
Проблема стабильности опорного напряжения действительно есть. Но к звуку, реальному на сколько она относится, я сказать не могу. Но к точности преобразования имеет точно, и чем выше разрядность ,тем она актуальней становится. Так же как и качество резисторов, емкостей и т.д. Как ты правильно заметил про тепловой шум.
Фак написан для начинающих, для раскручивания затронутой тобой проблемы, не для этого форума. И многим знать это вовсе не надо, потому как подготовка и специфика иная должна быть у людей.
.

 

<div class='quotetop'>QUOTE(\"Alexandre\")</div>

автор топика написал конкретный бред про "настоящие" 24-х битные конверторы и полупрофессиональные 20-ти битные которые устанавливают в звуковые платы.
это ошибка.
дело в том что "настоящих" 24-х битных (которые он прото выдумал) не существует в природе.
ну и акценты про влияние на звук он расставил тоже не верно. количество бит на него влияет в последнюю очередь. хотя безусловно на хорошей аппаратуре различие между 16-битным ЦАП и более точным слышно. различие есть в детальности, и это я не просто так говорю, а потому что я много слушаю разной высококачественной аппаратуры, есть большой опыт в этом.
но если на semi-pro карточку в 24 бита записываешь там ни о какой детальности вообще речи нет, это другой уровень, и продукты эти предназначены для любительской ниши рынка. Надо очень четко понимать это. Профессиональный 16-ти битный АЦП даст несравнимо лучшее качество. Самое тяжелое место в технологии АЦП это клок-генераторы, из-за них весь сыр-бор. Во всех недорогих компьютерных платах они примитивны, и не обеспечивают требуемых параметров.

 

А по-моему он и написал о термостабилизации кварцевого генератора, сейчас это наз клок генератором, но суть то одна.
Про опыт влияния, я имел в виду вот что. Берем 2 микросхемы АЦП одинаковые , но они в разных моделях и сравниваем. А лучше, даем тех задание двум разным инженерам и одинаковый набор обвеса этих микросхем и сравниваем звук, который получили от двух разных решений.
Я сейчас не занимаюсь этим, но в свое время много занимался цифровыми реверами, когда они только входили в обиход.
Там ведь тоже качество в первую очередь определялось АЦП и ЦАП.
Я считаю спор это здесь не к месту, здесь иная публика, и эти заморочки не особо многих интересуют.

 

Слушай, ну ты если звуком занимался, то должен знать, что стабилизация медленно изменяющихся параметров, таких как температура, не подходит для борьбы с фазовыми шумами (jitter). Это повлияет только на долговременную стабильность частоты генератора, которая при изменении в определенных пределах вообще не влияет на субъективное восприятие звука.

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

 

Хосты и платформы бывают разные. Скажем у PT и Лоджик внутренний формат данных 48 fixed. И даже в Ку/Ню, где внутренняя шина 32float не избежать преобразований на лету, потому что многие плагины имеют 64-битную внутреннюю математику. Кроме того возможны варианты совмещения различных платформ, скажем если к 32float Кубейсу подключить внешние железки или DSP работающие в 48fixed.

Еще раз подчеркиваю, что точность представления данных в формате 32float РАВНА 24 битам. В плане погрешности вычеслений 32 не дают никакого ощутимого преимущества.
Почитать можно здесь
здесь

Кроме того. Давай рассмотрим две цепочки.

Конвертер цифрует в 24 бита.

Вариант 1. Пользователь преобразует эти данные в 32float и хранит на диске в 32битном формате. Кубейс считывет данные из файла и передает их в 32битную шину.
Вариант 2. Пользователь НЕ преобразует данные и хранит их в 24 битах. Кубейс считывает данные из 24битного файла, преобразует их на лету в 32float и передает в 32битную шину.

Вся дальнейшаяя обработка внутри программы, весь рутинг между каналами, подгруппами, плагинами и сумматорами происходит в 32 битах. Какая разница, кто преобразует 24fixed в 32float, пользователь принудительно в самом начале или по ходу проигрывания программа автоматически? И как это может повлиять на накопление ошибок? Никак.

Если же вернуться к "преобразованию на лету" то мизерные потери процессорного времени при этом НЕСОИЗМЕРИМО меньше дополнительного времени, которое тратится медленной дисковой системой на чтение более длинного 32битного файла, который на 1/3 длиннее 24 битного.

Т.е выгод от хранения данных в 32 битах нет просто никаких.

 

Да это все ежу понятно. Я говорю, что у МЕНЯ нет статистики реальной о прослушивании того чего о чем я выше говорил. Теория - это одно, практика это другое.
Звуком я и сейчас занимаюсь, только на другом уровне и в другой немного области. Я человек конкретный и посему воздух зря не сотрясаю. У меня принцип, верить не словам, а пока сам не услышу. Я взрослый и бывалый мальчик, поэтому имею мнение СВОЁ ,как и хозяин топика на сей счет. А слова типа я дигустирую и сравниваю, здесь не хиляют. Поэтому я и сказал , не надо эту тему дальше развивать.
Топик полезный для начинающих и автор в принципе нормально осветил проблему. Разговор не шел о конкретной модели звуковой карты, а шел в общем.
Я к примеру для дом демок цифрую в 48/16 и мне хватает, хотя могу и оцифровать 96/24. Но реально я на слух не слышу разницу оцифрованной гитары в этих 2-х форматах.
Посему для меня значит-это приемлемо. Звук микса мне мой ндравится ))))
Но это не значит, что это надо делать поголовно всем и вся. А ведь теоретически надо в 96/24, т.е. ,чем больше,тем лучшей)))))

 

Alexandre, я очень рад что FAQ написан для начинающих. Просто из него надо убрать заведомо неверную дезинформацию.
Дело не в том что у меня "мнение" и у автора "мнение". Всё-таки есть вещи общепринятые, от которых отталкиваются. Законы физики например. Хотя и их время от времени пересматривают =)

Ну всё, мне видимо по этой теме больше нечего добавить.

 

Согласен!!!!!

 

<div class='quotetop'>QUOTE(\"supersonic\")</div>

Разница не только в количестве бит, но и в формате представления числа. Прочти, пожалуйста, начало моего предыдущего топика (про форматы и способы представления чисел - там я специально указал диапазоны - чем выше диапазон, тем выше точность)
В формате 24 бита можно отобразить диапазон чисел от - 8388352 до + 8388352. В формате 32float можно отобразить диапазон чисел 3.4E-38 до 3.4E+38. Если ты опять не понял - то я уже не знаю, как еще обьяснить.

 

Вы можете описать примерный механизм "Преобразования на лету",как в этом случае используется оперативная память,какие изменения вносятся в темпо файлы проекта? Это я к чему?Да к тому ,что этот механизм ни кто из производителей хостов не описывает.Откуда тогда такая инфа, о том ,что потерь больше на считывании с носителя подготовленой пользователем информации32 бита против конвертации в реальном времени в процессе обращения к 24 битному файлу?
Для чего то в хостах ведь существует буферизация(и темпо файлы проекта) куда попадают поочерёдно фрагменты обрабатываемого файла(ну скажем величиной 2гб) -это ни о чём не говорит?

 

NickCrow
Точность представления и диапазон - это разные вещи.

 

NickCrow нет, суть-то в том, что если ненормализованный 32 фп не превышающий 0 дб и 24 битный такой же файл сравнить - то точность одинаковая, так как биты забитые под показатель степени, в 32 фп не реализованы

 

<div class='quotetop'>QUOTE(\"daicehawk\")</div>

Отличие в том, что в формате floating point шум квантования относительный и равен -144 дБ относительно текущего уровня сигнала. А в формате int шум квантования фиксированный и абсолютный по уровню и равен -144 дБ FS.


<div class='quotetop'>QUOTE(\"daicehawk\")</div>

Это почему? Очень даже реализованы. Без них нельзя бы было применить к сигналу gain в -100 дБ и практически ничего не потерять.

 

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

 

Попробую еще раз пояснить особенности формата 32-bit float - может, для FAQ пригодится.

В "обычных", целочисленных форматах шаг квантования фиксирован, и по нему легко вычислить величину шума квантования данного формата: она примерно равна -6*p дБ, где p - разрядность квантования (например, для 16 бит получаем примерно -96 дБ).

Что же такое "плавающая запятая"? Наверное, из школьных учебников физики вам запомнились такие формы записи больших и малых величин: 4.51*10^5 или 3.56*10^-12. Здесь число представляется в виде мантиссы (3.56) и порядка (-12). Чем больше цифр в мантиссе, тем больше относительная точность представления числа. Чем больше допустимых цифр в порядке, тем больше возможный диапазон представления чисел.

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

В компьютере мантисса и порядок кодируются определенным числом разрядов (и, разумеется, применяется двоичная система счисления: 1.01001 * 2^-101). В формате 32-bit float для мантиссы отводится 24 бита, а для порядка - 8 бит. Это значит, что относительная точность числа будет составлять 24 бита (т.е. шум будет на уровне -144 дБ от величины числа), а диапазон - примерно от 10^-38 до 10^38.

Отсюда следуют важный вывод для работы со звуком в формате 32-bit float: по точности этот формат находится примерно на уровне 24...26-битного целочисленного формата, однако он позволяет не заботиться об уровнях: они могут быть как очень низкими, так и превышающими 0 дБ FS - при этом данные не испортятся, т.к. шум квантования - относительный. При выводе на звуковую карту этот формат преобразуется в целочисленный, и снизу появляется абсолютный по величине шум ЦАП, а сверху происходит клиппинг.

 

<div class='quotetop'>QUOTE(\"Alexey Lukin\")</div>

Так какой же вывод - пишем или не пишем в 32 float? Я так понимаю что пишем?

 

Если есть возможность - пишем. Другая альтернатива - 24bit.
И думаю тема себя исчерпала. Санет, спасибо за статью.

 

Итак попробую в последний раз обосновать почему я написал так как написал. В последний - потому что в топике я уже поменял формулировки, так-сказать "под давлением общественности". Меня упрекали в том что я писал неправду о реальной битности конвертеров и придумал несуществующие в природе конвертеры.
Только ведь правда это не всегда хорошо. Например дипломатия по сути - это "искусство вранья" и это вранье спасает миллионы жизней. А правда даже в отношениях двух людей может убить или как минимум испортить жизнь... По этому поводу неплохо почитать Дейла Карнеги. Я не сторонник его лицемерства, но доля правды там есть.
В преподавании ложь используется педагогический прием. Например вначале утверждается что определенную гармоническую последовательность использовать категорически нельзя, а на следующем курсе уже оказывается что можно...
Я конечно мог бы инженерно объяснить все что там происходит, со всеми шумами флуктуациями, электронами и дырками и даташит мне для этого не нужен. Помоему и так понятно что цифры не стыкуются. Но вопрос в том, нужно ли подобное объяснение инженеру, который это и так понимает? И станет ли от этого яснее начинающему, который потому и возмущается по поводу цены профессиональных плат, потому что он начинающий. Или это его еще больше запутает? А если он поумнеет и наберется опыта, то FAQ ему будет не нужен, он и так уже все будет знать, ибо будет читать не FAQ а книги. А если не будет, значит он сюда попал случайно.
Я дал другую, менее наглядную, но более "правдивую" формулировку, только не знаю кто от этого выиграл...

 

<div class='quotetop'>QUOTE(\"sunet\")</div>

Да, лучше писать сразу во float, т.к. последующую обработку лучше вести во float.

 

<div class='quotetop'>QUOTE(\"Alexey Lukin\")</div>

Просто хотелось добавить - если вы собираетесь нести что-то на другую студию - предварительно убедитесь, что они могут "понять" 32 бит флоат, потому как, например, ПроТулз НЕ понимает 32 бита.
А в Соник Солюшнс тоже 24 фиксед пойнт на ввод и вывод, внутренняя обработка - 40 бит фиксед (в ХД - 48).

 

Действительно исчерпано.Ну если веских доводов не приведут сейчас.Я всё делаю интуитивно(что не знаю)вот и пишу тоже в 32флоат и ни какого угрызения совести за большие размеры файлов.:biglaugh:

 

На досуге замутил простой тест.

Взял гиговый проект 24/44. 25 треков, с плагинами, с уровнями/панорамами, подргуппами и т.п. Сделал его копию на диске и все егойные wavки перелопатил в 32 бит.

Уровень загрузки процессора и HDD в Кубейсе не изменился. Засек время рендеринга. 24 битный проект считается чуть-чуть быстрее. 1:35 против 1:45, даже сделал несколько баунсов из разных копий папок, чтобы исключить влияние оптимизации HDD.

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

Далее. Послушал вслепую оба баунса. Никакой разницы.

В связи с этим имею вопросы к сторонникам 32 бит и к Лукину в частности

1.

Я цифрую через 24 битный конвертер. Есть два варианта писать на диск в 24fixed или 32float.

ADC24 > WAV 24> Конверсия в 32 при воспр. > 32 Шина Ку/Ню
ADC24 > Конверсия в WAV 32 при записи> Воспр. > 32 Шина Ку/Ню

Как и где может при этом возникнуть разница в конечном миксдауне и чем она обусловлена?

2. Был в топике резонный довод, что хранение аудио в избыточном формате может быть оправдано последующей деструктивной обработкой.

Какие по-вашему деструктивные операции из используемых в реальной жизни могут сделать разницу между 24 и 32 заметной на слух? Про то что в теории можно уменьшить уровень на 300 дб и вернуть обратно, это понятно, а что-нибудь поближе к реальности.

А то получается противоречие. С одной стороны у нас в Факе написано о 19 битном пороге и избыточности даже формата 24, а с другой стороны мы рекомендуем еще более избыточный формат. Я желаю знать, ЧЕМ ИМЕННО это оправдано.

В инете много всяких теоретических доводов о накоплении ошибок и т.п. Я хочу конретный практический пример, где и как такие ошибки могут накопиться, чтобы вылезти на СЛЫШИМЫЙ уровень. Я хочу УСЛЫШАТЬ деградацию аудио в результате таких ошибок. Применительно разницы между 24 и 32.

 

<div class='quotetop'>QUOTE(\"supersonic\")</div>

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

 

Для каких именно вычеслений жизненно необходима такая точность? Для каких операций она оправдана? На каком этапе? Не на всякий случай, про запас, а конкретно пожалуйста. Можно так и в 64 float, он же типа еще точнее.

 

<div class='quotetop'>QUOTE(\"supersonic\")</div>

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

 

<div class='quotetop'>QUOTE(\"supersonic\")</div>

Не только можно, но и нужно. Очень многие плагины уже давно производят внутреннюю обработку в 64 bit float. В новом стандарте VST v.2.4 одно из основных новшеств - это поддержка плагинами ввода и вывода сигналов в формате 64 bit float. Несколько секвенсоров за последнее время приобрели возможность внутренней обработки в 64 bit float. Внимание! - а теперь вопрос - как Вы думаете, какую цель преследуют разработчики? Вариантов ответов не предлагаю, поскольку ответ очевиден.
<div class='quotetop'>QUOTE(\"supersonic\")</div>

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

 

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

Предел по вертикали хорошо известен и даже упомянут тобой в твоем Факе.

Битность исходных данных имеет значения сугубо для определенного ряда вычислений. Скажем для расчета очень крутых НЧ фильтров может не хватить и 32бит.

Суть в том что пользователь DAW выбирая избыточную битность никак не может повлиять на то, что происходит внутри плагинов. Если внутри плагина исполуется "плохой" алгоритм, и там в результате вычислений накапливается ошибка, вас не спасет ни 32 ни 64 бита. Ни даже 128.

 

Отчего же тогда результат одинаковый, если сводить 24 и 32 битный проекты?

 

<div class='quotetop'>QUOTE(\"NickCrow\")</div>

Увы не совсем. Помимо соображений качества есть еще соображения конкуренции и рекламы. Например людям понадобились десятки лет для того чтоб понять что COCA-COLA не только вредный, но и невкусный продукт. А все потому что фирма 90% прибыли (!!!) вкладывает в рекламу и народ этой обильной рекламе верит. Или пример с телефонами NOKIA - кошмарный дизайн в угоду кичу и оригинальности и ужасное соотношение цена-качество, зато вездесущная и суперагрессивная реклама, и в результате - все покупает эти несуразные телефоны.
Теперь все программы предлагают 32 float, значит надо предложить 64 и утверждать что это неоспоримое приемущество, все перейдут на 64, значит надо 128... точно также и частотой.
Я не хочу сказать что 64 плохо, просто предлагаю относится ко всему этому осторожно, ибо люди научились зарабатывать деньги на пустом месте...

Добавлено: я смотрю мы тут все разом писали о том же... :tongue: