Samlitude 8ХХ64
- Автор темы СобакаНах
- Дата начала
- Статус
в идеале битность миксдауна должна быть битность_трека*количество_треков, только в этом случае гарантированно ничего не потеряется из-за ошибок округления
с умножением попутал, сорри, количество бит - битность трека плюс количество треков.
пример: у вас битность -2 десятичные цифры, т.е. сигнал - от -99 до 99, лишние цифры отбрасываются, а дальше начинаем думать сколько сколько будет 99+99?
SilverEye
Тэкс, я тут.
Возвращаемся к нашим веселым картинкам.
Если я правильно понял интерфейс Сопли, то: 1 - это у нас Винамп с Фубаром, они равны в ноль, 2 - это родной спектр песни, а 3 - это у нас разница между Винампом (а значит и Фубаром) и WMP, и разница вся по низам?
Тэкс, я тут.
Возвращаемся к нашим веселым картинкам.Если я правильно понял интерфейс Сопли, то: 1 - это у нас Винамп с Фубаром, они равны в ноль, 2 - это родной спектр песни, а 3 - это у нас разница между Винампом (а значит и Фубаром) и WMP, и разница вся по низам?
Это почему же?
[ADDED=SilverEye]1137944153[/ADDED]
Now Easy Jay, именно так. Насчёт точности выставления двух треков относительно друг друга можешь не сомневаться. Проводил тесты на других материалах - то же самое.
[ADDED=SilverEye]1137944314[/ADDED]
Да, конечно же всякие постобработки во всех плейерах были выключены (я их и так не включаю никогда, но всё равно проверил всё), чистый сигнал.
Так внутренняя обработка у тебя всё равно в 32 бита, и исходный файл тоже в 32 BIT float, именно для этих ситуаций
проверяется количеством битов в числе b (битность) единиц * количество треков
фак, нельзя думать о высоком и разом готовиться к экзамену по физике: не количеству, а битности количества треков...
rinka:
смысл в том, чтобы рассчитать битность при которой изменение одного трека на 1 единицу в одном семпле ещё влияет на результат микса.
так вот я утверждаю что при битности по формуле такое будет происходить а не сожрется погрешностями округления.
ЗЫ, реальные цифры: если треки 16 битные и не рулятся по уровню при 32 битном миксе и количеству треков до 2 в 16й это выполняется
Так, во-первых, опередели, что такое "не влияет на результат". Во-вторых, сложение семплов происходит целочисленно, и никакого округления там быть не может.
Может, ты путаешь с шумом квантизации? Но он ведь при проходе через АЦП появляется. А в программе-то он откуда тогда? Программа, производящая сложение семплов, и АЦП - не совсем одно и то же. :smile:
Может, ты путаешь с шумом квантизации? Но он ведь при проходе через АЦП появляется. А в программе-то он откуда тогда? Программа, производящая сложение семплов, и АЦП - не совсем одно и то же. :smile:
целочисленное деление с целью понижения уровня сигнала дает ошибки, а с шумом квантизации я не путаю, это вообще из другой оперы
ЗЫ. что-то у нас два разных топика на приблизительно одну тему образовалось...
[ADDED=Vasfed]1137951199[/ADDED]
лан, не будем воевать из-за мелочей, порешим на том, что сводить надо в микшере с высокой внутренней разрядностью (типа нюши 3.2 в которой 80 бит), лаги будут но ниже уровня шума других девайсов тракта.
Да, ладно, не прибедняйтесь.
Вот конкретно на данный момент четыре активных, один во флейме, второй в создании музыки, третий - в железе, четвертый - вот он. И вообще это тема вечная, народная забава такая. Радует, что в железе мы таки пришли к выводам.
Вот они:http://rmmusic.ru/showthread.php?t=17700&page=6
СобакаНах, и прочие сочувствующие могут почитать всю тему целиком, советую. :thumbsup:
это точно... :beer:Originally posted by Now Easy Jay
И вообще это тема вечная, народная забава такая.
прям как антиномии чистого разума у Канта, правда в нашем случае некоторые из них все-же удается измерить объективно...
Так мы ж о микшировании сигналов говорим, а не об обработке. :smile:
А если уж и заговорить о понижении/повышении громкости, то погрешность (при изменении громкости один раз) будет появляться только в самом младшем бите. И увеличением битности её не исправить, всё равно будет в самом младшем бите появляться. :smile:
просто в случае более высокой битности этот самый младший бит будет отвечать за более низкое по уровню изменение сигнала :thumbsup:
Originally posted by Now Easy Jay
Да, ладно, не прибедняйтесь.
Радует, что в железе мы таки пришли к выводам.
http://rmmusic.ru/showthread.php?t=17700&page=6
СобакаНах, и прочие сочувствующие могут почитать всю тему целиком, советую. :thumbsup:
Спасибо нах,обязательно почитаю,мне это очень интересно. :beer:
Vasfed, он и так отвечает за изменение сигнала на одну единицу измерения. Сколько у нас динамический диапазон? Ну, скажем, 250 дБ? Сколько у нас чисел представляется 32 битами? 2^32 = 4294967296 чисел.
Т.е. диапазон между двумя числами n1 и n2, при n2 = n1 + 1 представляет собой динамический диапазон, равный 250/4294967296 = 0,0000000582076609134674072265625 от части нашего исходного динамического диапазона (но это только при изменении младшего бита числа, представляющего семпл!). Для нахождения погрешности в процентах составим пропорцию:
250/0,0000000582076609134674072265625 = 100/x,
где x - погрешность в процентах.
x = 0,0000000582076609134674072265625 * 100/250 = 0,000000023283064365386962890625 %.
:lol:
Т.е. диапазон между двумя числами n1 и n2, при n2 = n1 + 1 представляет собой динамический диапазон, равный 250/4294967296 = 0,0000000582076609134674072265625 от части нашего исходного динамического диапазона (но это только при изменении младшего бита числа, представляющего семпл!). Для нахождения погрешности в процентах составим пропорцию:
250/0,0000000582076609134674072265625 = 100/x,
где x - погрешность в процентах.
x = 0,0000000582076609134674072265625 * 100/250 = 0,000000023283064365386962890625 %.
:lol:
а при 16 битах в 110дБ- это уже 0,0016784924086366063935301747158007 дБ, и 0,0015259021896696421759365224689097%
- уже ближе к значимым цифрам
Ну тогда объясни мне, старому, каков смысл увеличивать битность при 32 битах? Ты же это утверждал. :gigi: И увеличив битность ты ведь не избавишься от погрешности? Она всё равно будет, и никуда не денешься. :smile: (это при изменении громкости, заметь, не при микшировании! С микшированием вообще не будет погрешности).
а откуда ты берешь 32-битные записи? :biggrin:
ведь даже самые навороченные цап-ацп имеют разрядность 24 бита, а по динамическому диапозону и того меньше :tongue:
вы просто повышаете разрядность ещё при записи :biglaugh:
а при микшировании без изменения громкости (если грамотно записано и сигнал под 0 поджат) вы точно никуда не денетесь - иначе в клип уйдет
Запутали окончательно...не люди а вычислительные машины :biglaugh:
Для меня это важно.Значит какой порядок может быть оптимален на MD?
запись в 2444100-48000 ->MD-сведение в стерео файл премастеринг 32 float???44100 или выше????(дитер выключен)качество сумирования "очень медленно для только32 битных файлов"-> Новый проект ,импорт стерео файла(3244100или выше) и мастеринг (л3 ,экв,если надо энхансер)->MD 1644100 (дитер POW-1-2 По выбору либо по умолчанию)качество сумирования "Ультра медленно 1"......
Поправте как бы вы эти операции проделали...пожалуйста.
ray:
Для меня это важно.Значит какой порядок может быть оптимален на MD?
запись в 2444100-48000 ->MD-сведение в стерео файл премастеринг 32 float???44100 или выше????(дитер выключен)качество сумирования "очень медленно для только32 битных файлов"-> Новый проект ,импорт стерео файла(3244100или выше) и мастеринг (л3 ,экв,если надо энхансер)->MD 1644100 (дитер POW-1-2 По выбору либо по умолчанию)качество сумирования "Ультра медленно 1"......
Поправте как бы вы эти операции проделали...пожалуйста.
ray:- Статус