Про биты(не путать с битами)

  • Автор темы Автор темы Nady
  • Дата начала Дата начала

Nady

Well-Known Member
7 Дек 2011
772
273
63
Беларусь. Ошмяны.
Я вот чего не могу взять в толк. Система может быть 32 либо 64. И там эта разрядность выполняет свою роль. Программа тоже может быть 32 или 64. И эта программа не обязательно для работы со звуком. То есть опять же пока речь идёт только о совместимости, быстродействии, вобщем о чем угодно, только не о звуке. Но разработчик, скажем рипера, заявляет, что его программа ведёт вычисления в 64 бит. И эти биты уже имеют непосредственное отношение к описанию волновой формы. И я так понимаю, что при простых операциях суммирования-вычитания это может сказываться на точности. (Хотя разве при сложении двух изначально квантованных 16 битами семплов может получиться число не попадающее в сетку 16 битного квантования?) Ну да ладно. При компрессировании, эквализации и т.д такое запросто может и должно получаться. Главный вопрос, который меня интересует, как узнать, какие плагины честно умеют работать с 64 битным звуком? Не работать в 64 среде, а работать с 64 звуком? Ведь теоритически какая штука может получиться- рипер загнал каким-нибудь своим 64 компрессором в 64, а потом чужой плаг откинул нафиг лишние разряды по своему усмотрению и вернул в 16. Дальше больше. То есть вопрос простой - о тех ли битах мы думаем, когда читаем в описании плагина 32/64?
 
Поясните подробне, что вы хотите сказать употребляя словосочетание "64х битный звук"?
 
Ну я не силён в математике, но мне казалось, что чем меньше шаг квантования и выше частота дискретизации, тем точнее можно описать сигнал и произвести операцию с ним. А чем больше бит, тем меньше шаг. Не?
 
Насколько мне известно формат RF64 есть и глубина там 64 бита а вот обработок под него(вст-шки) естчё не встречал и не встречу пока(хотя конвертеры(софт) есть с 64 битным аудиопроцессингом и то считают наверное в оффлайне через ЦПУ,для онлайн режимов железо кардинально менять надо и асио переделывать,хотя 2.3 подерживает 64 битный аудиопроцессинг путем: 32MSB 32LSB,но это костыли всё-же,штейнберги сами в документации пишут,что это NON-Native.).
 
Последнее редактирование:
RF64 не имеет никакого отношения ни к разрядности аудиоданных, ни к разрядности обработки. Он всего лишь позволяет создавать файлы без ограничения размера в 4 ГБ.
 
Ну фиг с ними с 64. Во сколько они там считают? 24, 32 с плавющй? Не суть . Вопрос может ли вообще возникнуть ситуация когда аудиопоток скажем из внутренних секвенсорных 24 или 32 транкейтится сторонним плагином до 16, а затем ,по возвращении в хост, снова загоняется в 24? Что в таком случае останется от сигнала после пары таких плагинов? Где в описании плагинов указана не разрядность системы, в которой они могут работать, а поддерживаемая разрядность обработки?
 
Так точность всегда требует больших размеров веса файла,так как цифры на порядок будут больше,простое сравнение веса того же стерео-вавчика(44100,16) и (192000,32),я думаю последний будет по весу больше хотя оба по длительности будут одинаковы(у первого за микролисекунду 44.1 отсчёта,а у второго 192 отсчёта+глубины по битности(топорно говоря)),вес файла-это одно из вытекающих просто(лично мое мнение).
 
Последнее редактирование:
По сути 24 битная точность,затем обработка плагином с 16 битной точностью,затем опять перестроение в хосте в 24 бита=>ухудшение качества(математически если мыслить) исходника без изменения начального размера файла,улучшения точности построения например синуса точно не будет,а вес останется,но есть и костыли,позволяющие добиться улучшения качества при 16 битной точности(двойная точность),от 8 битной точности в обработке вроде как уже постепенно отказываются,но не факт.
 
Из описания некоторых плагинов Voxengo. "GlissEQ является пятиполосным параметрическим динамическим эквалайзером - уровень полосы изменяется в зависимости от программного материала.
Есть пять типов фильтров, регуляторы частоты, добротности, уровня и степени зависимости уровня для каждой полосы,
возможность индивидуального прослушивания полос, регулятор общего выходного уровня, кнопка отключения эквалайзера, возможность сравнения двух настроек, режим повышенного качества работы.
Поддерживаются стерео- и моносигналы любой частоты дискретизации, внутренняя обработка 64-разрядная.". И что это значит?
 
И ещё. Из тех же воксенгов. "Overtone GEQ соответствует спецификациям VST версии 2.4, соответственно может оперировать полностью 64 битными данными (если это поддерживается хостом)" :unsure:
 
Ну фиг с ними с 64. Во сколько они там считают? 24, 32 с плавющй? Не суть . Вопрос может ли вообще возникнуть ситуация когда аудиопоток скажем из внутренних секвенсорных 24 или 32 транкейтится сторонним плагином до 16, а затем ,по возвращении в хост, снова загоняется в 24? Что в таком случае останется от сигнала после пары таких плагинов? Где в описании плагинов указана не разрядность системы, в которой они могут работать, а поддерживаемая разрядность обработки?

Будет только, если в плагине есть дитер. В остальных случаях ПОТОК(24 или 16 - не важно) через плагин не должен изменять свою битность... Даже в ТДМ и прочих DSP
 
В зависимости от частоты дискретизации в проекте,например пишитесь в линию на бюджетную зв.карту с частотой 44100 при 16 битах моно=>т.е динамический диапазон сигнала будет=65536 значений громкости + 44,1 отсчёта за милисекунду,в воксенге будет перестроение и сигнал там будет иметь уже по максимуму с учетом передискретизации частоты(что не факт) и значений там будет=9223372036854775808 на битность и на "математическую модель(может быть,что угодно и нужно это всё распределить по уму и точность может быть не везде 64 бита)",(если без плавающей зпт,но точно утверждать не буду так как не знаю),с последними цифрами идут вычисления(повышение,понижение громкости изменение частоты и т.д. согласно алгоритмам эквалайзера),на выходе из обработки данные округляются к параметрам обработки DAW ну а затем и к параметрам железки(зв.карты).Напоследок скажу натив 64 бита,есть 32 с двойной точностью,что почти тоже самое(эмуляция 64 бит),но утверждать не буду.
 
Последнее редактирование:
ну здрасьте приехали, есть, конечно
http://en.wikipedia.org/wiki/IEEE_floating_point
http://ieeexplore.ieee.org/xpl/articleDetails.jsp?reload=true&arnumber=4610935
Во сколько они там считают? 24, 32 с плавющй? Не суть .
как это не суть. Ещё какая суть. В целочисленных 24 битах нет промежуточных значений и есть клиппинг. В 32-битных числах с плавающей точкой наоборот. 8 дополнительных разрядов и иная форма представления данных - это вам не хухры-мухры.
Вопрос может ли вообще возникнуть ситуация когда аудиопоток скажем из внутренних секвенсорных 24 или 32 транкейтится сторонним плагином до 16
конечно может. Любой плаг-ин, который выполняет bit reduction именно это и делает. Простейшие примеры - мастеринг плаг-ины или бит-крашеры.
внутренних секвенсорных 24 или 32
звуковые движки всех современных цифровых рабочих станций как минимум оперируют в 32-bit float. В этом же формате работает VST2. Исключения: VST2.4, Cakewalk Sonar (не помню с какой версии), которые умеют оперировать с данными в 64-bit float (double precision).
а затем ,по возвращении в хост, снова загоняется в 24?
в 32-bit float
Где в описании плагинов указана не разрядность системы, в которой они могут работать, а поддерживаемая разрядность обработки?
если в описании нигде не написано, можете спросить у разработчиков. Большинство плаг-инов оперируют с 32-битными данными. Некоторым плаг-инам для рассчёта требуется повышенная точность, тогда они используют 64-бита. Если суть плаг-ина в понижении разрядности, то обычно желаемую разрядность вы устанавливаете в самом плаг-ине.
Что в таком случае останется от сигнала после пары таких плагинов?
зависит от плаг-инов и хоста. Некоторые делают дизеринг даже при понижении из 32-бит float, в 24 целочисленных бита. Некоторые нет, т.е. просто транкейтят.
 

Тут нет доказательств существования аудио с разрядностью 64 бита. По ссылкам формат представления чисел для машинной арифметики. Ну да, в теории действительно выходит, что можно аудио кодировать в 64 битах, раз числа в ЭВМ бывают 64-разрядные, но речь-то шла про его реальное существование. Там из материала по ссылкам можно сказать и про возможность 128-разрядного аудио. Ваша DAW позволяет выводить микс с разрядностью 64 бита или 128? :)
 
maks991, конечно позволяет. Регулярно делаю экспорт в 64 бита при необходимости последующей обработки в другом редакторе.
Ограничения, о которых говорите вы, связаны с аппаратными особенностями ЦАП звукового устройства. Даже честные 24 бита выдать может не каждое устройство. Однако это ограничение только на выходе из DAW в реальном времени, внутри же неё, операции с плаг-инами, суммирование и т п выполняется в 32 или 64 битах над числами с плавающей точкой, о чём и шла речь в топике.
 
  • Like
Реакции: Nady
Иииии... Помнится когда-то видел специальный плагин, с помощью которого можно было проверить, с какой битностью работает тот или иной плагин(каламбур). Не помню как называется, но точно есть такая штука. Вешаешь ее после испытуемого, и он показывает сколько разрядов возвращается после подопытного. В описании было что-то именно про опасность невидимого транкейта. Никто не встречал?
 
Elle уже попыталась маленько разгрести эту кашу с битами , но мне кажется нужно всё по полкам разложить ...

Я тут написал некие заголовки , которые нужно (ИМХО) рассматривать отдельно и не месить в одну кашу ....т.е 24 битный АЦП и формат , разрядность аудио файла это разные вещи , и разрядность и формат аудио файла и обработка в daw ,тоже разные вещи ....

Разрядность АЦП (Разрешение АЦП )

Формат и разрядность аудио файла ( есть скажем WAV , 32 бит , а есть DSD , разрядность которого 1бит )

Внутренние вычисления и преобразования в DAW
- работа с RAM (32 бит / 64 Бит )

- работа с аудио файлом (в определённом формате , с определенной разрядностью )

- микшер (суммирование) , хедрум (1bit = - 6 dBFS (Примерно) , 32 бит = - 192dBFS и т.д )

- хост / плагин ( 64 бита в плагинах , без объяснений , это частенько о работе с памятью и о работоспособности с 64 битным хостом , если написано про внутреннюю обработку , то это уже о операциях с двойной точностью , честно сказать тут производители со своим маркетингом , борзеют маленько ...а кто то вообще видел реально 64 битный плагин ? ;) )

Разрядность ЦАП
 
Последнее редактирование:
Иииии... Помнится когда-то видел специальный плагин, с помощью которого можно было проверить, с какой битностью работает тот или иной плагин(каламбур). Не помню как называется, но точно есть такая штука. Вешаешь ее после испытуемого, и он показывает сколько разрядов возвращается после подопытного. В описании было что-то именно про опасность невидимого транкейта. Никто не встречал?

Про плагины не знаю, видимо следует гуглить по запросу "bitscope vst"
Я сразу вспомнил видео с Субботиным где он говорил про битность
http://www.youtube.com/watch?v=T05eCpobt4k&feature=youtu.be&t=1m59s
 
  • Like
Реакции: Nady
И как расценивать этот мультик?
 

Вложения

  • Биттер.gif
    Биттер.gif
    385,3 KB · Просмотры: 105
это значит что на выходе с 1й - 32, а со 2й - 64.
 
Это я понимэ. Вопрос в другом- так может использовать только те, на выходе у которых 64? Чтобы до последнего этапа все варилось без дитеров и транкейтов. Качество получше будет. Не?
 
когда наступит тот день, что вы сможете отличить на слух 32 от 64 - тогда и переходите.
 
Меня вот кстати тоже давно интересует вопрос оправданности использования внутренней обработки в 64бит флоат. Ведь даже 32 с плавающей запятой дают практически бесконечный запас точности (31бит - это, если не ошибаюсь, 186дБ, плюс плавающая запятая на всякие экстремально тихие или экстремально громкие ситуации).
И ладно бы я не парился, но ведь это увеличение разрядности должно и на нагрузке на процессор сказаться не в лучшую сторону?

хотя насчет битов я видимо не сильно разбираюсь, сколько там на положение запятой влияет... видимо так в 32битах: https://en.wikipedia.org/wiki/Single-precision_floatin ?
 
Последнее редактирование:
Иииии... Помнится когда-то видел специальный плагин, с помощью которого можно было проверить, с какой битностью работает тот или иной плагин(каламбур)
в Adobe Audition в статистике есть Actual Bit Depth
еще:
http://www.stillwellaudio.com/plugins/bitter/

На счёт 64-битной обработки - это наиболее актуально для рекурсивных алгоритмов, где может накапливаться ошибка. Типичный пример - рекурсивные фильтры (в большинстве эквалайзеров), когда используются какие-то предельные параметры (крутизна характеристик, ультра-НЧ, ВЧ и пр.).
Замечу, что для простой (без алгоритмеческих и аппаратных извращений:) ) и адекватной (SNR > 96 db) целочисленной обработки - 24 бита в таких случаях - может быть мало. Поэтому специализированные целочисленные dsp чипы имеют и 32, а в хороших случаях и 48 битные операции.
И вот тут-то, не стоит забывать, что реально в используемом в PC 32-битном формате с плавающей точкой IEEE 754 для мантиссы отведено всего-лишь 24 бита, а совсем не 32. На сколько это существенно - вопрос не такой простой, но скажем так, при определенных параметрах фильтров - будет работать точно не лучше чем целочисленный вариант с такой же (24 бита) точностью - а это не лучший вариант.

Реально только в формате 64-бит с плавающей точкой IEEE 754 в мантиссе больше чем 48 бит (а именно 53, включая знак). Т.е. обеспечивается уверенный запас, аналогичный традиционным аппаратным DSP реализациям.

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


зы
Ведь даже 32 с плавающей запятой дают практически бесконечный запас точности (31бит - это, если не ошибаюсь, 186дБ, плюс плавающая запятая на всякие экстремально тихие или экстремально громкие ситуации)
если делаешь какую-то операцию типа сложения - то порядки приводятся к одинаковому, и "сверхтихий звук" (при сложении с нормальным) идёт лесом и результат может оказаться немногим лучше, если бы это делалось в 24-битной целочисленной арифметике. Как повезёт, причём когда повезёт, а когда нет - аналитически оценить и описать (в терминах звука, т.е. частоты, SNR, четных\нечетных гармоник) довольно сложно...
 
Последнее редактирование:
  • Like
Реакции: Nady и fruitcore
для мантиссы отведено всего-лишь 24 бита, а совсем не 32
а разве это "всего-лишь", если еще и для запятой 8 бит выделено?

или я вообще как-то не так понимаю представление и обработку аудиоданных?:D

если делаешь какую-то операцию типа сложения - то порядки приводятся к одинаковому, и "сверхтихий звук" (при сложении с нормальным) идёт лесом и результат может оказаться немногим лучше, если бы это делалось в 24 битной целочисленной арифметике. Как повезёт, причём когда повезёт, а когда нет - аналитически оценить и описать (в терминах звука, т.е. частоты, SNR, гармоники) довольно сложно...
а, все ясно, где проблема. Но блин, громкий звук же замаскирует более тихий полюбому.. Хотя.. хотя примерно представляю себе ситуацию, где это хоть как-то будет заметно.
К примеру громкий громкий и низкий синус (еле разборчивый) накладывается на тихий тихий информативный сигнал; потом от этого отфильтровываем низ, а информация в моменты пиков синусоиды уже потеряна. Примерно так?)
 
Последнее редактирование:
точно:) Учитывая, что вполне адекватная ВЧ часть обычно низка по амплитуде, а с ней обычно ассоциируют "прозрачность" - тема является весьма актуальной...

но повторюсь - наиболее это значимо при рекурсивной обработке внутри плагинов, реально на шинах микшера будет >144 dB динамического диапазона, даже при single precision 32-bit.
Если только придумать что-то зверское после какой-либо из шин, чтобы это могло стать заметным (впрочем, есть же любители вешать, например, искажалки на общие посылы...).
 
Последнее редактирование:

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