слушай, я не берусь составлять FAQ и формулирую как могу. а тебе не мешает немного заняться самообразованием на тему АЦП. почитать даташиты очень полезно как раз для того, чтобы больше понять о том предмете, о котором ты взял на себя смелость написать сей рукописный труд-предмет топика =)
<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 бита с плавающей точкой (см. выше диапазоны допустимых значений).
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 нет, суть-то в том, что если ненормализованный 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.
<div class='quotetop'>QUOTE(\"NickCrow\")</div> Увы не совсем. Помимо соображений качества есть еще соображения конкуренции и рекламы. Например людям понадобились десятки лет для того чтоб понять что COCA-COLA не только вредный, но и невкусный продукт. А все потому что фирма 90% прибыли (!!!) вкладывает в рекламу и народ этой обильной рекламе верит. Или пример с телефонами NOKIA - кошмарный дизайн в угоду кичу и оригинальности и ужасное соотношение цена-качество, зато вездесущная и суперагрессивная реклама, и в результате - все покупает эти несуразные телефоны. Теперь все программы предлагают 32 float, значит надо предложить 64 и утверждать что это неоспоримое приемущество, все перейдут на 64, значит надо 128... точно также и частотой. Я не хочу сказать что 64 плохо, просто предлагаю относится ко всему этому осторожно, ибо люди научились зарабатывать деньги на пустом месте... Добавлено: я смотрю мы тут все разом писали о том же... :tongue: