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

  • Автор темы Автор темы Nady
  • Дата начала Дата начала
если вы слушате только тихий высокочастотный шум - то да. Но чаще всего это не так ;)
 
если вы слушате только тихий высокочастотный шум - то да. Но чаще всего это не так ;)
если б знать, когда;) Допустим с выхода ди-эссера на вокале, именно в тот момент, когда он срабатывает - как раз именно так. А перед этим стоит компрессор, который жмёт дБ на тридцать, и вот, в самом начале (а не наоборот) еще "некий" эквалайзер...
И вот тут мы начинаем придирчиво выбирать эквалайзеры:)
 
@imemine, я не могу полностью осознать все сказанное о компьютерных технологиях. Мне хотелось бы услышать однозначный ответ, если он возможен. Если хватает мощности компьютера и система 64 бит, я могу однозначно автоматически избавиться от нежелательных артефактов при обработке ( эквализация, компрессия, микширование) в случае использования только плагинов, умеющих оперировать 64 битными аудиоданными? Получаю ли я надежный запас точности по сравнению с 32 плагинами? Ведь если они(64) есть, то это кому-нибудь нужно?
 
Ведь если они(64) есть, то это кому-нибудь нужно?
Тут надо - отдельно "мухи", отдельно "котлеты".

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

Теперь по-поводу, т.с. интерфеса наружу, т.е. соединения между плагинами по 64-битному интерфесу (конкретно - речь про vst 2.4, это мы все понимаем, надеюсь.)
Вот это - уже менее значимо, или вообще не так значимо для звука, но при прочих равных - естественно хуже быть не должно:) Ну разве только новые баги в новых плагинах:)
На сколько лучше? Думается не сильно лучше, в типичных ситуациях с DAW. Поэтому и производители пока, вобщем-то, не сильно заморачиваются.

зы
Мне хотелось бы услышать однозначный ответ, если он возможен
В идеале 64-бит, конечно. Но реальность - многогранна и не идеальна:)
 
Последнее редактирование:
64 бита, ИМХО, чистый маркетинг, а суммирование - вообще чистая математика.

И математика примерно следующая: Оперируя 24 битными звуковыми потоками, в 64 битном микшере Вы можете гарантированно, без потерь разрядов суммы, оперировать более чем триллионом(!) потоков уровня 0dBFS. А приводить обратно к 24 битам уже на выходе. Оно надо?

PS. 64 бита дают динамический диапазон 385 дБВ. Без комментариев...
 
Последнее редактирование:
Ну конечно надо!
Чтобы при помощи кристально точного звука смоделировать виндажный шум ламп и аналоговых трактов. :)
 
Ах если бы речь шла только о динамическом диапазоне. Но не забываем ли мы о фазах, фронтах волн, атаках? Ведь разрешение слуха по фазам гораздо больше чем по динамике и частоте.
 
64 бита, ИМХО, чистый маркетинг, а суммирование - вообще чистая математика.
Будучи когда-то студентом и регулярно суммируя на ЭВМ всякие интегралы и ряды было замечено, что погрешность этой операции в случае когда слагаемые сильно различаются по порядку не могла удовлетворить никого, даже студента, не говоря уже о преподавателях. На мой взгляд погрешности результата сильно зависят от алгоритма обсчёта, а "лишние" даже теоретически разряды не могут помешать счастью. Пусть будут...
 
А на расход ресурсов процессора это насколько сильно влияет? В рипере perfomance meter вообще не показал изменений при переключении 64bit float/32bit float
 
Мне хотелось бы услышать однозначный ответ, если он возможен. Если хватает мощности компьютера и система 64 бит, я могу однозначно автоматически избавиться от нежелательных артефактов при обработке ( эквализация, компрессия, микширование) в случае использования только плагинов, умеющих оперировать 64 битными аудиоданными? Получаю ли я надежный запас точности по сравнению с 32 плагинами? Ведь если они(64) есть, то это кому-нибудь нужно?
Не туда копаете (сорри за однозначный ответ :) )
 
  • Like
Реакции: olegsound
Будучи когда-то студентом и регулярно суммируя на ЭВМ всякие интегралы и ряды было замечено, что погрешность этой операции в случае когда слагаемые сильно различаются по порядку не могла удовлетворить никого, даже студента, не говоря уже о преподавателях. На мой взгляд погрешности результата сильно зависят от алгоритма обсчёта, а "лишние" даже теоретически разряды не могут помешать счастью. Пусть будут...

На самом деле на 64 битных процессорах использование 64-х битных переменных - переменных с плавающей точкой двойной точности (52 бита на мантиссу), является органичным, вообще не требует каких-либо усилий программистов и не приводит каким либо изменениям производительности, по сравнению с 32 -х битными вычислениями. И причисление данного параметра к конкурентным преимуществам программы - чистый маркетинг.
 
КМК на производительность точно не влияет, соглашусь на 101%, а на точность может влиять - это 100%.
 
Ну, дык, я о том, что это заслуга производителей процессоров и компиляторов, а не ноу-хау производителей Рипера... :D
 
64 бит оправданы при вычислениях рекурсивных операций (фильтры, EQ и т.п. - очень полезно, когда программист не хочет париться дизайном и тупо делает в лоб) и для гипотетических операций динамической обработки в 100дб редакции. В остальных случаях хватает и 32х.
 
На самом деле на 64 битных процессорах использование 64-х битных переменных - переменных с плавающей точкой двойной точности (52 бита на мантиссу), является органичным, вообще не требует каких-либо усилий программистов и не приводит каким либо изменениям производительности, по сравнению с 32 -х битными вычислениями.
Справедливости ради - насчёт производительности - это не совсем так. Если интересно - посмотрите AVX2 расширение для интеловских процессоров. За одну операцию обрабатывается 8 32-битных операндов, и всего-лишь 4 64-х битных. Для avx-512 - аналогично (16-ть против 8-ми).
Другое дело, что звук - не самая ресурсоемкая область, в плане вычислений, тем более чисто микширование.
 

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