Шумит звуковая карта (1 онлайн

[ISEE]

Гейн на 70% лично у меня. И я очень рад, что для вас -80дб это ничтожный шум, но для меня это проблема.
И по-моему стоило просто сказать, что это норма, а не строчить что-то про знания в физике

В каком контексте Вы собираетесь использовать записанное с микрофона? Какова динамика того, что Вы записываете через микрофон? Это голос? Гитара? Флейта...... Каков стиль произведения? Громко? Тихо? Быстро? Медленно?.......... Сколько еще инструментов будут играть одновременно с тем, что записано через микрофон? Это сольная партия или 5-я скрипка в оркестре? Если при записи чувствительность стоит на 0db и в результате записи, полезный сигнал получится, пусть даже -15db, а Ваш шум -80db (на фоне полезного сигнала) ВЫ ЕГО В МИКСЕ НЕ УСЛЫШИТЕ! Хотя бы потому, что станете слушать именно полезный сигнал, а не прислушиваться есть ли там шум. Чисто психологически внимание притягивается к тому, что громче. А другие слушатели даже и "знать не будут помнить", что там, оказывается, может быть еще и шум.
Вот и вся физика, математика, арифметика!
Вы сами то много музыки слушаете? Часто прислушиваетесь на предмет наличия такого шума в том, что слушаете?

 

[Lowcut]

Заметили, кстати, у Аудиента какая шумовая полка странная? Шум увеличивается к высоким частотам. Видать DC-DC конвертор встроенный срёт.

Не верьте тому, что видите, это всего лишь наклон кривой анализатора.
Установите наклон на ноль и будет абсолютно другая картина.

В каком контексте Вы собираетесь использовать записанное с микрофона? Какова динамика того, что Вы записываете через микрофон? Это голос? Гитара? Флейта...... Каков стиль произведения? Громко? Тихо? Быстро? Медленно?.......... Сколько еще инструментов будут играть одновременно с тем, что записано через микрофон? Это сольная партия или 5-я скрипка в оркестре? Если при записи чувствительность стоит на 0db и в результате записи, полезный сигнал получится, пусть даже -15db, а Ваш шум -80db (на фоне полезного сигнала) ВЫ ЕГО В МИКСЕ НЕ УСЛЫШИТЕ! Хотя бы потому, что станете слушать именно полезный сигнал, а не прислушиваться есть ли там шум. Чисто психологически внимание притягивается к тому, что громче. А другие слушатели даже и "знать не будут помнить", что там, оказывается, может быть еще и шум.
Вот и вся физика, математика, арифметика!
Вы сами то много музыки слушаете? Часто прислушиваетесь на предмет наличия такого шума в том, что слушаете?

Психоакустический эффект маскировки.

 

[dugdum®]

Не верьте тому, что видите, это всего лишь наклон кривой анализатора.
Установите наклон на ноль и будет абсолютно другая картина.

Спасибо за замечание, даже не знал что там есть этот "Tilt", да, всё так. Век живи, век учись, как говорится )

 

[Lowcut]

Спасибо за замечание, даже не знал что там есть этот "Tilt", да, всё так. Век живи, век учись, как говорится )
Посмотреть вложение 244002

Есть еще более забавная штука:

Битность и микшеры в Reaper.

Здравствуйте. Узнал, что Reaper позволяет выбрать битность микшеров, по умолчанию это 64bit с плавающей (ещё так-же можно выбрать битность и с целым числом, но это неважно). Но есть ли смысл ставить 32bit с плавающей ? Может ли быть такое, что из-за 64bit могут не запуститься плагины или вовсе...

rmmedia.ru

 

[dugdum®]

Есть еще более забавная штука:

Тут, возможно, просто говорит о том, что внутри плага обработка 32fp
Он совершенно не обязан менять свои алгоритмы из-за смены битности микшера хоста. Рациональность в этом есть: при отсутствии реального выигрыша в результатах работы плагина можно сэкономить немного на ресурсах.

 

[Lowcut]

Тут, возможно, просто говорит о том, что внутри плага обработка 32fp
Он совершенно не обязан менять свои алгоритмы из-за смены битности микшера хоста. Рациональность в этом есть: при отсутствии реального выигрыша в результатах работы плагина можно сэкономить немного на ресурсах.

Дело не в том, что он обязан, дело в том - чего он неспособен.
Про экономию ресурсов - это была шутка юмора, а вот про то, что эта сука удаляет 32 бита - нет.

 

[dugdum®]

Дело не в том, что он обязан, дело в том - чего он неспособен.
Про экономию ресурсов - это была шутка юмора, а вот про то, что эта сука удаляет 32 бита - нет.

А я не шутил, ресурсы действительно немного экономятся. А толку от 64-х битов нет.

 

[Alex_HS]

Все преампы в мире шумят.

А тут ещё и с открытым входом (при неподключенном источнике), т.е. "сферический конь в вакуме". Если мне память не изменяет, то собственные шумы преампа измеряются при закороченном на землю входе, если ошибаюсь - поправьте.
@Long, @digilab2 - ваша тема, объясниете плз!

 

[Lowcut]

А я не шутил, ресурсы действительно немного экономятся. А толку от 64-х битов нет.

Опять вас не туда.
Проблема не в 64 или 32, а в колбасе: 64-32-64-32-... и так целыми вязанками в проекте.
В результате, мы получаем целый букет транкейта, который приводит к суммированию (а то и прогрессии) накопления ошибок квантования, т.е. шуму квантования и нелинейным искажениям.
Умножьте этот ужас на количество переходов, каналов, шин, групп и мастер секцию, и в итоге получаем вселуху и байки про то, что какая-то там ДАВ-а звучит найлепш за инших.)
Так понятно?)

А тут ещё и с открытым входом (при неподключенном источнике), т.е. "сферический конь в вакуме". Если мне память не изменяет, то собственные шумы преампа измеряются при закороченном на землю входе, если ошибаюсь - поправьте.
@Long, @digilab2 - ваша тема, объясниете плз!

о подняли проблему)))

 

[Alex_HS]

@Lowcut, Самая большая проблема - это "слушанье глазами" при недостаточном понимании для правильной интерпретации увиденного, которая приняла поистине катастрофический масштаб в последнее время.

 

[Lowcut]

@Lowcut, Самая большая проблема - это "слушанье глазами" при недостаточном понимании для правильной интерпретации увиденного, которая приняла поистине катастрофический масштаб в последнее время.

 

[Trasher]

Есть еще более забавная штука:

Битность и микшеры в Reaper.

Здравствуйте. Узнал, что Reaper позволяет выбрать битность микшеров, по умолчанию это 64bit с плавающей (ещё так-же можно выбрать битность и с целым числом, но это неважно). Но есть ли смысл ставить 32bit с плавающей ? Может ли быть такое, что из-за 64bit могут не запуститься плагины или вовсе...

rmmedia.ru

Рискну предположить, что виной в обрезке 32 битов является тип sample32(используемый в фабфильтре) , рипер при инициализации опросил эквалайзер узнал тип,и чикнул(а скорее всего понизил точность измерений путем неявного приведения к типу(при условии, что режим обработки в рипере 64 битный) , равной типу обработки плага(sample32) ) , все по-честному.Также замечу либо что-то напартачено в плаге, тк можно при разработке указать два типа одновременно(sample32 и sample64). Это фабфильтр дуркует скорее всего, а рипер начинает подстраиваться под эквалайзер(оптимизировать накладные расходы на обработку сигнала путем приведения к типу) , а на самом деле обработка в рипере идёт 64 битная, только все, что после 32 бит заполнено нулями(тк понижена точность до sample32(проще говоря фабфильтр пытается даунсемплить и создаётся видимость) , приборы определения битности сигнала тут бессильны и никак не помогут, а только введут в заблуждение)) Как-то так.

 

[Long]

собственные шумы преампа измеряются при закороченном на землю входе

-- Бывает и так, встречал, но у не отягощённых совестью изготовителей.
Стандарт - вместо микрофона на вход подключается "эквивалент микрофона", резистор 150 Ом.

А с открытым входом все преампы будут шипеть, как рассерженная змеюка...

 

[Long]

шум -80db (на фоне полезного сигнала) ВЫ ЕГО В МИКСЕ НЕ УСЛЫШИТЕ!

-- Так точно!
Ощущение, что очень многие в школе прогуливали арифметику.
Если уровень полезного сигнала будет 100 дб, то (-80дб) от этого будет 20 дб.
Палаты больниц и санаториев, операционных больниц, шум ночью: 25 db.
Т.е. уровень 20 дб - это меньше, чам самое тишайшее помещение!

P.S. Подробнее - например, здесь: http://www.soundinfo.org/articles/noise/

 

[Long]

Presonus 24c: EIN: -126 dBu (A-взвешенный, 150 Ом, максимальное усиление).
Т.е. при максимальном услении в 50 дб выходной шум преампа будет: 126-50= -76dBu, или примерно 0,12 милливольта.
Не идеал, но и не смертельно.
Микрофон Октава МК-012 при давлении в 100 dB SPL даст на выходе примерно 0,015 вольта.
Делим 0,015 вольта на 0,12 милливольт - получаем сигнал\шум примерно 42 дБ.
Если орать в микрофон со всей дури, до болевого порога, то получим С\Ш около 62 дб.
Больше - не получить. Никак.
(Если где ошибся в арифметике - сорри, таки пятый час ночи...)

 

[Lowcut]

Рискну предположить, что виной в обрезке 32 битов является тип sample32(используемый в фабфильтре) , рипер при инициализации опросил эквалайзер узнал тип,и чикнул(а скорее всего понизил точность измерений путем неявного приведения к типу(при условии, что режим обработки в рипере 64 битный) , равной типу обработки плага(sample32) ) , все по-честному.Также замечу либо что-то напартачено в плаге, тк можно при разработке указать два типа одновременно(sample32 и sample64). Это фабфильтр дуркует скорее всего, а рипер начинает подстраиваться под эквалайзер(оптимизировать накладные расходы на обработку сигнала путем приведения к типу) , а на самом деле обработка в рипере идёт 64 битная, только все, что после 32 бит заполнено нулями(тк понижена точность до sample32(проще говоря фабфильтр пытается даунсемплить и создаётся видимость) , приборы определения битности сигнала тут бессильны и никак не помогут, а только введут в заблуждение)) Как-то так.

Это относится не только к фабфильтру, а ко всем плагинам работающим с разрядностью 32.
И сама проблема кроется не в том, что есть плагины и DAW - 32 и 64, а в том, что при установке плагинов в микшире, нужно учитывать их последовательность исходя из разрядность.
При чем здесь даунсемплинг к квантованию, этого я не понял.
И, о каком бессилии и введении в заблуждения, Вы говорите, тоже. ┐(‘～` )┌

 

[Kokarev Maxim]

Спасибо за замечание, даже не знал что там есть этот "Tilt", да, всё так. Век живи, век учись, как говорится )
Посмотреть вложение 244002

Да, по умолчанию он калиброван под розовый шум (tilt 3db), это ближе к реальной музыке. А с тильтом на 0 будет калиброван под белый - этот вариант лучше для оценки технических характеристик.

 

[dugdum®]

Опять вас не туда.
Проблема не в 64 или 32, а в колбасе: 64-32-64-32-... и так целыми вязанками в проекте.
В результате, мы получаем целый букет транкейта, который приводит к суммированию (а то и прогрессии) накопления ошибок квантования, т.е. шуму квантования и нелинейным искажениям.
Умножьте этот ужас на количество переходов, каналов, шин, групп и мастер секцию, и в итоге получаем вселуху и байки про то, что какая-то там ДАВ-а звучит найлепш за инших.)
Так понятно?)

Дело в форматах данных.
Колбаса 24-16-24-16 fixed как в старых DSP системах была бы проблемой.
Колбаса 64-32-64-32 floating point - проблемой не является, слишком этот транкейт ничтожно мал в плане переносимой звуковой информации.
Надеюсь, тоже понятно объяснил )

 

[Trasher]

Рискну предположить, что виной в обрезке 32 битов является тип sample32(используемый

Это относится не только к фабфильтру, а ко всем плагинам работающим с разрядностью 32.
И сама проблема кроется не в том, что есть плагины и DAW - 32 и 64, а в том, что при установке плагинов в микшире, нужно учитывать их последовательность исходя из разрядность.
При чем здесь даунсемплинг к квантованию, этого я не понял.
И, о каком бессилии и введении в заблуждения, Вы говорите, тоже. ┐(‘～` )┌

Битметр(написанный на jsfx - 100% и возможно некоторые на вст3 и клэп[но тут есть нюансы] ) могут обмануть также как и любой плагин, непреднамеренно конечно же.Как пример:Вы думаете, что сигнал обрезается до 32 бит в микшере рипера из-за плага, по приборам также показывает 32бита(при условии, что включён режим обработки в микшере 64 бита) , а на самом деле идёт обработка в 64 бита с пониженной точностью ( дорисованы нули до 64 битного значения и произведено приведение к типу) те-->размер данных одного семпла по факту 8 байт а не 4. Узнать тип данных при обработке можно только чекнув тип данных, больше я думаю никак (те определиться с размером данных с помощью sizeof или typeid(в jsfx этого функционала нет) ) . Тем более, что битметр от кокоса при инициализации уже работает в режиме переполнения типа(я заглянул в реализацию и нашёл баг) -те уже имеем погрешность в вычислениях(отрезается около 3-7 бит от 64 битного значения). Точность нужна 1:1 а имеем на этапе инициализации данных уже 1к (навскидку 0.93-0.95) при 64 битной обработке,замечу вычислений ещё не было(некоторые входные данные также будут усечены по точности по "битовой маске" или другой реализации алгоритма понижения точности). В итоге имеем:врет или криво работает плаг(с большой вероятностью, надо чекать) врет битметр(100%) от кокосов,самому риперу врать не можно(но не факт) , тк он шлёт результат на вывод(может просто упасть). Обобщу - Рипер работает в 64 битном режиме, а по приборам вы видите(думаете что видите) значение в 32 бита(что ни есть правда, реальное значение == 64 бита округленное до 32 битного значения размером 8байт(понижена точность вычислений) ).

 

[Lowcut]

Дело в форматах данных.
Колбаса 24-16-24-16 fixed как в старых DSP системах была бы проблемой.
Колбаса 64-32-64-32 floating point - проблемой не является, слишком этот транкейт ничтожно мал в плане переносимой звуковой информации.
Надеюсь, тоже понятно объяснил )

Плавающая запятая, тут роли не играет.
А разрядность 16 бит, нет смысла рассматривать и сравнивать априори, мы не в каменном веке, пока.)

 

[Lowcut]

Битметр(написанный на jsfx - 100% и возможно некоторые на вст3 и клэп[но тут есть нюансы] ) могут обмануть также как и любой плагин, непреднамеренно конечно же.Как пример:Вы думаете, что сигнал обрезается до 32 бит в микшере рипера из-за плага, по приборам также показывает 32бита(при условии, что включён режим обработки в микшере 64 бита) , а на самом деле идёт обработка в 64 бита с пониженной точностью ( дорисованы нули до 64 битного значения и произведено приведение к типу) те-->размер данных одного семпла по факту 8 байт а не 4. Узнать тип данных при обработке можно только чекнув тип данных, больше я думаю никак (те определиться с размером данных с помощью sizeof или typeid(в jsfx этого функционала нет) ) . Тем более, что битметр от кокоса при инициализации уже работает в режиме переполнения типа(я заглянул в реализацию и нашёл баг) -те уже имеем погрешность в вычислениях(отрезается около 3-7 бит от 64 битного значения). Точность нужна 1:1 а имеем на этапе инициализации данных уже 1навскидку 0.93-0.95) при 64 битной обработке,замечу вычислений ещё не было(некоторые входные данные также будут усечены по точности по битовой маске алгоритма понижения точности). В итоге имеем:врет или криво работает плаг(с большой вероятностью, надо чекать) врет битметр(100%) от кокосов,самому риперу врать не можно(но не факт) , тк он шлёт результат на вывод(может просто упасть). Обобщу - Рипер работает в 64 битном режиме, а по приборам вы видите(думаете что видите) значение в 32 бита(что ни есть правда, реальное значение == 64 бита округленное до 32 битного значения размером 8байт(понижена точность вычислений) ).

Мне интересно, как Вы себе представляете это ваше округление.
Если плагин работает только с разрядностью 32, у него еще 32-х, чтобы вписать туда нолики, они их просто отбрасывает,
Было 18 446 744 073 709 551 616 уровней, стало 4 294 967 296, остальных - нет, нет там ни ноликов, ни кроликов, просто - нет.
А вот если следующий за ним плагин будет 64 битным, произойдет повторное увеличение глубины квантования, и образовавшиеся уровни заполнят нолики.

 

[dugdum®]

Мне интересно, как Вы себе представляете это ваше округление.
Если плагин работает только с разрядностью 32, у него еще 32-х, чтобы вписать туда нолики, они их просто отбрасывает,
Было 18 446 744 073 709 551 616 уровней, стало 4 294 967 296, остальных - нет, нет там ни ноликов, ни кроликов, просто - нет.
А вот если следующий за ним плагин будет 64 битным, произойдет повторное увеличение глубины квантования, и образовавшиеся уровни заполнят нолики.

опять путаете 32 fixed и 32 floating point
никто ни в плагинах, ни в daw не считает в 32-х целочисленных разрядах! там данные с плавающей точкой, это 1680 дБ динамический диапазон )
а обычные 32 разряда, как вы посчитали 4 294 967 296, это всего 194 дБ )))

Плавающая запятая, тут роли не играет.

ага, угу

 

[Lowcut]

опять путаете 32 fixed и 32 floating point
никто ни в плагинах, ни в daw не считает в 32-х целочисленных разрядах! там данные с плавающей точкой, это 1680 дБ динамический диапазон )
а обычные 32 разряда, как вы посчитали 4 294 967 296, это всего 194 дБ )))



ага, угу

Что Вы несете.)
Вы хоть знаете, что такое плавающая запятая, ее свойства, и для чего она вообще?
Мне кажется нет, собственно как и то, откуда ноги у 1680 дБ.
Если уж так ржете, представьте доказательства, что нет 32 с фиксированной точкой и wav-файл с динамическим диапазоном 1680 дБ.
Пруф в студию!
Будем ржать вместе.)

PS^ и 32 - это 192, а не 194.)

 

[Trasher]

Мне интересно, как Вы себе представляете это ваше округление.
Если плагин работает только с разрядностью 32, у него еще 32-х, чтобы вписать туда нолики, они их просто отбрасывает,
Было 18 446 744 073 709 551 616 уровней, стало 4 294 967 296, остальных - нет, нет там ни ноликов, ни кроликов, просто - нет.
А вот если следующий за ним плагин будет 64 битным, произойдет повторное увеличение глубины квантования, и образовавшиеся уровни заполнят нолики.

----------------
Про нолики и кроликов.
При приведении типа с большего на меньший будет усечение(в рипере и не только). Тут без вариантов. С меньшего на больший округление нулями(понижение точности в обоих случаях, результаты разные), также ещё вариант развития событий--> переполнение типа(в рипере double) в момент вычислений(те больше double/sample64) , спрошу у Вас, что будет ?))

 

[Lowcut]

С меньшего на больший округление нулями(понижение точности в обоих случаях, результаты разные)

Никакого понижения точности не будет. Будет тоже самое, что и было, но в другой системе "координат".

также ещё вариант развития событий--> переполнение типа(в рипере double) в момент вычислений(те больше double/sample64) , спрошу у Вас, что будет ?))

Я не так хорошо знаю Рипер, чтобы знать где/чего там за "double/sample64", т.ч. ничего сказать не могу.(

 

[dugdum®]

Что Вы несете.)
Вы хоть знаете, что такое плавающая запятая, ее свойства, и для чего она вообще?

Точно, весна! )
Разбаньтесь в гугле наконец. Почитайте про типы данных float и double.

 

[Lowcut]

Точно, весна! )
Разбаньтесь в гугле наконец. Почитайте про типы данных float и double.

Вы давайте не увиливайте!
Жду подтверждений сказанному.

 

[Trasher]

----------------
Про нолики и кроликов.
также ещё вариант развития событий--> переполнение типа(в рипере double) в момент вычислений(те больше double/sample64) , что будет ?))

Спойлер: Не спора ради[фото]

 

[RusAD]

Спойлер: Не спора ради[фото]

Посмотреть вложение 244038

Спойлер: То, что у вас на скриншотах, кажется, к дискуссии о 32/64 битах не относится

На калькуляторе у вас переполнение целочисленного типа произошло, от этого и минус возник. Если считать в wolframalpha, покажет правильное значение, без минуса.
А на скрине из рипера... это, похоже, приколы джаваскрипта, с точностью вычислений не связанные. По крайней мере, вне зависимости от разрядности проекта, ошибка будет одинаковая. Плюс, если использовать браузерный JS, а не риперовский JSFX, то там все еще страннее.

То есть при отображении точность потерялась, а для вычисления нет.

К счастью, VST плагины обычно (а может быть, всегда) написаны на C++, где такой фигни нет.

 

[Trasher]

Спойлер: То, что у вас на скриншотах, кажется, к дискуссии о 32/64 битах не относится

На калькуляторе у вас переполнение целочисленного типа произошло, от этого и минус возник. Если считать в wolframalpha, покажет правильное значение, без минуса.
А на скрине из рипера... это, похоже, приколы джаваскрипта, с точностью вычислений не связанные. По крайней мере, вне зависимости от разрядности проекта, ошибка будет одинаковая. Плюс, если использовать браузерный JS, а не риперовский JSFX, то там все еще страннее.

Посмотреть вложение 244673
То есть при отображении точность потерялась, а для вычисления нет.

К счастью, VST плагины обычно (а может быть, всегда) написаны на C++, где такой фигни нет.

Язык в jsfx(jesussonicFX) - EEL2. Тип int64 в jsfx/eel2 реализован на c/c++(отличается от стандартного представления типа int64) При проверке на переполнение типа не стоит забывать про длину/емкость равную qword(чтобы сравнить со стандартным типом int64 и сделать какие-то выводы) . Также представление типа int64 аналогично(почти) представлению типа double, поэтому он не выбрасывает исключение(изменение знака) при переполнении, а молча начинает фильтрацию значения результата, исключение составляет только int32(он выбрасывает исключение при переполнении типа в плюс бесконечность) . Но это не костыль(int64) , а компромисс.Отображение значений на скрине показано в дебагвью родной ide встроенной в рипер, смысл ide не показывающей реальный полученный результат(тут придётся только поверить на слово) .По поводу точности в реалтайме плагов вст3 формата очень очень спорно.Реактор от нэйтивов также канселит(опционально -для снижения нагрузки на цп) , рипер агрессивно/или не очень фильтрует(автоматом) при работе в режиме переполнения типа(что инт64, что дабл) .Как-то так в общих чертах)