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

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

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

16-ти битный профессиональный конвертер типа Apogee AD1000 без вопросов уберет по качеству любую ныне продающуюся \"24-х битную\" мультимедию в диапазоне до 500 $.


А с чем конкретно ты его сравнивал? Речь идет о сравнении в 16 битном режиме записи или же о 16 vs 24? Да и неплохо бы тест услышать. Все таки AD это не DA, это легко проверить.
 
Originally posted by dugdum®
Тебе домашнее задание:
1) посмотри даташит на популярные топовые микросхемы АЦП и взгляни на заявленный производителем динамический диапазон для идеальных условий их работы.  
2) сравни это с теоретическим значением динамического диапазона 24-х битного сигнала.  
3) попробуй ответить себе на вопрос почему они различаются и настолько. после этого за уши притянутые идеи относительно \"термостабилизации АЦП\" рассеются как будто их и не было ) и добрую часть твоего FAQ тоже можно будет смело стереть.

Так отчего тебе самому не поведать общественности о том, что там написано и какие выводы из этого можно сделать. Не все же даташиты читают.
 
Итак про 32 float я переформулировал, если что не так - подскажите.
Относительно частоты квантования - если кто-нибудь докажет мне что лучше вначале записать на 44100 и потом конвертировать в 48000 или записать в 48000 а потом конвертировать в 44100, т.е. совершать лишнее конвертирование от нечего делать, даже если потери от этого при нынешних математических ухищрениях малы (но зачем?!) то тогда я соглашусь что этот пункт надо менять...
Также и по п.7. Как схемотехник я убежден что из тех же элементов можно сделать хорошие и плохие приборы и что есть платы разного качества и что за качество можно бороться на техническом уровне и потому не вижу что в этом пункте неверно... Докажите мне что лучше брать полупрофессиональную плату чем профессиональную и я этот пункт уберу.
 
<div class='quotetop'>QUOTE(\"dugdum®\")</div>
пункт 7, практически весь неправильный и противоречит элементарным законам физики. (тоже объяснил почему)[/b]
и ответ в соседнем топе, но как раз в тему
Originally posted by Alexey Lukin
Да, ниже 20 разрядов только шум. Соотношение сигнал/шум лучших конвертеров достигает 115...120 дБ - это как раз уровень 20-го бита (-120 дБ). Уменьшить уровень шумов не удается из-за термального (броуновского) шума (хотя можно, теоретически, пойти по пути повышения максимального напряжения). Поэтому если у конвертера есть хотя бы 20-битная точность, то это уже хорошо. Гораздо важнее не \"битность\", а именно \"аккуратность\". 16-битные профессиональные конвертеры будут звучать намного лучше, чем 24-битные, установленные в дешевые звуковые карты.
Думаю компетентность Лукина в этом вопросе под сомнение никто не ставит?
 
Originally posted by supersonic
По поводу 24 vs 32 dugdum прав. Никакого смысла хранить данные в 32 битах нет. Точность отображения у этого формата в конечном счете равняется тем же 24 битам. Мантисса у 32 бит - 23битная + 1 бит на знак. А лишние 8 бит это порядок степени. Если по-простому, то эти 8 бит нужны фактически только для реализации механизма уровней без клиппинга. Если конечный результат будет в 24 битах, то формат хранения 32float или 24fixed дают совершенно одинаковый результат. Хранение данных в 32float ничего кроме увеличения объема на диске не дает.

PS Лукин по-моему даже где-то в недрах RMM об этом рассказывал.
Не совсем он прав ибо -вот его ответ на вопрос о реализации математики в хосте: преобразование типов данных, необходимое для того чтобы подсунуть 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>
2dugdum
Заявленные параметры АЦП в даташите, это руководство к выбору или нет, данной микросхемы инженера к реальному проекту.
Тебе сказал же хозяин топика, что он рассматривает АЦП в целом ,а не микросхему.
Проблема стабильности опорного напряжения действительно есть. Но к звуку, реальному на сколько она относится, я сказать не могу. Но к точности преобразования имеет точно, и чем выше разрядность ,тем она актуальней становится. Так же как и качество резисторов, емкостей и т.д. Как ты правильно заметил про тепловой шум.
Фак написан для начинающих, для раскручивания затронутой тобой проблемы, не для этого форума. И многим знать это вовсе не надо, потому как подготовка и специфика иная должна быть у людей.[/b]

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

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

 
Писать треки в проект лучше, все-таки в формате 32 бита с плавающей точкой. Во-первых, вы сразу получаете треки в том же формате, что и внутренний формат хоста и в дальнейшем никаких преобразований \"на лету\" не потребуется.

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

Originally posted by NickCrow

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

Еще раз подчеркиваю, что точность представления данных в формате 32float РАВНА 24 битам. В плане погрешности вычеслений 32 не дают никакого ощутимого преимущества.
Почитать можно здесь
[url="http://www.jamminpower.com/PDF/48-bit%20Audio.htm"]здесь

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

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

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

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

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

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

Ну всё, мне видимо по этой теме больше нечего добавить.
 
<div class='quotetop'>QUOTE(\"supersonic\")</div>
Еще раз подчеркиваю, что точность представления данных в формате 32float РАВНА 24 битам.[/b]
Разница не только в количестве бит, но и в формате представления числа. Прочти, пожалуйста, начало моего предыдущего топика (про форматы и способы представления чисел - там я специально указал диапазоны - чем выше диапазон, тем выше точность)
В формате 24 бита можно отобразить диапазон чисел от - 8388352 до + 8388352. В формате 32float можно отобразить диапазон чисел 3.4E-38 до 3.4E+38. Если ты опять не понял - то я уже не знаю, как еще обьяснить.
 
Originally posted by supersonic

Если же вернуться к \"преобразованию на лету\" то мизерные потери процессорного времени при этом НЕСОИЗМЕРИМО меньше дополнительного времени, которое тратится медленной дисковой системой на чтение более длинного 32битного файла, который на 1/3 длиннее 24 битного.
Т.е выгод от хранения данных в 32 битах нет просто никаких.
Вы можете описать примерный механизм "Преобразования на лету",как в этом случае используется оперативная память,какие изменения вносятся в темпо файлы проекта? Это я к чему?Да к тому ,что этот механизм ни кто из производителей хостов не описывает.Откуда тогда такая инфа, о том ,что потерь больше на считывании с носителя подготовленой пользователем информации32 бита против конвертации в реальном времени в процессе обращения к 24 битному файлу?
Для чего то в хостах ведь существует буферизация(и темпо файлы проекта) куда попадают поочерёдно фрагменты обрабатываемого файла(ну скажем величиной 2гб) -это ни о чём не говорит?
 
NickCrow
Точность представления и диапазон - это разные вещи.
Еще раз подчеркиваю, что точность представления данных в формате 32float РАВНА 24 битам.
 
NickCrow нет, суть-то в том, что если ненормализованный 32 фп не превышающий 0 дб и 24 битный такой же файл сравнить - то точность одинаковая, так как биты забитые под показатель степени, в 32 фп не реализованы
 
<div class='quotetop'>QUOTE(\"daicehawk\")</div>
если ненормализованный 32 фп не превышающий 0 дб и 24 битный такой же файл сравнить - то точность одинаковая[/b]
Отличие в том, что в формате floating point шум квантования относительный и равен -144 дБ относительно текущего уровня сигнала. А в формате int шум квантования фиксированный и абсолютный по уровню и равен -144 дБ FS.


<div class='quotetop'>QUOTE(\"daicehawk\")</div>
биты забитые под показатель степени, в 32 фп не реализованы[/b]
Это почему? Очень даже реализованы. Без них нельзя бы было применить к сигналу 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 - при этом данные не испортятся, т.к. шум квантования - относительный. При выводе на звуковую карту этот формат преобразуется в целочисленный, и снизу появляется абсолютный по величине шум ЦАП, а сверху происходит клиппинг.
 
  • Like
Реакции: smack
<div class='quotetop'>QUOTE(\"Alexey Lukin\")</div>
по точности этот формат находится примерно на уровне 24...26-битного целочисленного формата, однако он позволяет не заботиться об уровнях: они могут быть как очень низкими, так и превышающими 0 дБ FS - при этом данные не испортятся, т.к. шум квантования - относительный[/b]
Так какой же вывод - пишем или не пишем в 32 float? Я так понимаю что пишем?
 
Если есть возможность - пишем. Другая альтернатива - 24bit.
И думаю тема себя исчерпала. Санет, спасибо за статью.
 
Итак попробую в последний раз обосновать почему я написал так как написал. В последний - потому что в топике я уже поменял формулировки, так-сказать "под давлением общественности". Меня упрекали в том что я писал неправду о реальной битности конвертеров и придумал несуществующие в природе конвертеры.
Только ведь правда это не всегда хорошо. Например дипломатия по сути - это "искусство вранья" и это вранье спасает миллионы жизней. А правда даже в отношениях двух людей может убить или как минимум испортить жизнь... По этому поводу неплохо почитать Дейла Карнеги. Я не сторонник его лицемерства, но доля правды там есть.
В преподавании ложь используется педагогический прием. Например вначале утверждается что определенную гармоническую последовательность использовать категорически нельзя, а на следующем курсе уже оказывается что можно...
Я конечно мог бы инженерно объяснить все что там происходит, со всеми шумами флуктуациями, электронами и дырками и даташит мне для этого не нужен. Помоему и так понятно что цифры не стыкуются. Но вопрос в том, нужно ли подобное объяснение инженеру, который это и так понимает? И станет ли от этого яснее начинающему, который потому и возмущается по поводу цены профессиональных плат, потому что он начинающий. Или это его еще больше запутает? А если он поумнеет и наберется опыта, то FAQ ему будет не нужен, он и так уже все будет знать, ибо будет читать не FAQ а книги. А если не будет, значит он сюда попал случайно.
Я дал другую, менее наглядную, но более "правдивую" формулировку, только не знаю кто от этого выиграл...
 

Сейчас просматривают