Помогите вычесть в ноль. (2 онлайн)

Предположу, что "качество" решает окончательный рендер, у меня, с моим "скромным" компьютером так и происходит
Но качество звука при работе в проекте тоже устраивает, хотя понимаешь, что при рендере всё будет пересчитано тщательнее
В ПТ его внешнее железо - оно позволяет выдать "выходное" качество при работе с проектом
Наверно речь об этом


У меня и запись и синты и сэмплеры, я, скорее "черновой" при работе, я привык, меня всё устраивает )
Если я правильно всё понял )
Верно. Если при низких значениях "всё звучит", то при рендере с повышенными качественными настройками - хуже не станет.
А вот, когда занимавшийся саунд-дизайнерскими задачами (наруливаешь звучок) полезно в самом проекте выставить сразу высокое качество, и периодически проверять звук при помощи "транкейта", например отрендерить в МР3 128 кбит/с что бы убедиться все ли хорошо.
 
  • Like
Реакции: LogicS
Разумеется. Вы поспрашивайте "старых бывалых" с какими настройками они работают в "черновых" проектах: 44.1rHz и 24 bit integer
24 bit integer настроек чего? Если самих файлов мультитрека - то этого с головой и для "чистовых" проектов, 32 bit float кроме защиты от дураков, не следящих за уровнями никакого профита не дают. А микширования в 24 bit integer попросту нет ни в одной DAW, иначе бы при малейшем превышении 0дБ в любом месте стоял бы ацкий срачЪ. Кто юзал старые Waves в TDM не дадут соврать ))

32 (тоже с "плавающей точкой). На что это влияет? На округление результата вычисления (вычитания).
Сказывается ли это на слух - данных нет, в виду малости искажений (не услышал пока ещё ни кто), но для "математики" - разница есть.
В какой-то из старых версий S1 я проверял работу микширования в 32-битном и 64-битном режимах, рендеры вычитались в полный 0.
 
  • Like
Реакции: Sharu, tekknik и LogicS
24 bit integer настроек чего? Если самих файлов мультитрека - то этого с головой и для "чистовых" проектов, 32 bit float кроме защиты от дураков, не следящих за уровнями никакого профита не дают. А микширования в 24 bit integer попросту нет ни в одной DAW, иначе бы при малейшем превышении 0дБ в любом месте стоял бы ацкий срачЪ. Кто юзал старые Waves в TDM не дадут соврать ))
Ну, как же нет - в настройках можно установить битность и частоту для Pro Tools, DP, Reaper за другие не помню, но думаю у всех есть.
 
В какой-то из старых версий S1 я проверял работу микширования в 32-битном и 64-битном режимах, рендеры вычитались в полный 0.
А разве в S1 - 64-х битная математика? Помнится в версии 4 битметр показывал у меня 32Bit f..p. а Reaper к тому времени уже мог и 64.
Ошибка округления будет одна и та-же для одинаковых чисел как в 32-, так и в 64- системе счета. Разница проявится при операциях умножения, например на какой нибудь коэффициент, ну и если "входящее" число 24 целочисленное, то и "выходящее" будет 24, и ошибка округления например в 32-х разрядной системе будет меньше чем значение младшего разряда 24 бит.
 
@max-owl, настройки битности файла при записи и для внутреннего микширования в DAW - это разные настройки
Да, но берём мы 24 бита и суммируем их скажем в 64 плавающих. Результат проц выдаст в 24: "чо пришло то и ушло" - он так "научен". А про ошибку округления я уже чиркнул выше.
 
Да, но берём мы 24 бита и суммируем их скажем в 64 плавающих. Результат проц выдаст в 24: "чо пришло то и ушло" - он так "научен". А про ошибку округления я уже чиркнул выше.
Это не совсем так работает
 

Вложения

  • Скриншот-28-01-2025 18_16_09.png
    Скриншот-28-01-2025 18_16_09.png
    44,2 KB · Просмотры: 31
@max-owl, 7-я. Но вроде, насколько помню, в 5-й версии уже было. В четвертой не помню, хотя с нее и начал.
Не, в 4-й точно еще не было. Спасибо. В те времена это было в Сонар и Рипер и более ни у кого.
 
  • Like
Реакции: Landre
64-х битная математика
Я конечно не настоящий сварщик (в том смысле что программистом по своей специальности не работал ни дня), но... нет никакой особенной "математики" там, имхо. Есть стандарт ieee754 который аппаратно реализован в процах (математический сопроцессор), и все вычисления производятся посредством него. В идеале вся "математика" 32 на 64 меняется заменой типа всего одной переменной (хранящей текущий семпл) с типа float на тип double. Господа практикующие программисты - всё так ведь плюс-минус? :)
 
  • Like
Реакции: Trasher
Я конечно не настоящий сварщик (в том смысле что программистом по своей специальности не работал ни дня), но... нет никакой особенной "математики" там, имхо. Есть стандарт ieee754 который аппаратно реализован в процах (математический сопроцессор), и все вычисления производятся посредством него. В идеале вся "математика" 32 на 64 меняется заменой типа всего одной переменной (хранящей текущий семпл) с типа float на тип double. Господа практикующие программисты - всё так ведь плюс-минус? :)
Да, плюс-минус так. Вопрос лишь в том, а входящий семпл (семплы) для расчета - какой системы? Если все семплы (сгенерированные синтом, отданные фильтром, полученные в результате вычислений "хвосты" реверов и т.д.) 24-х битные, то и суммирование произойдет с такой-же точностью, достаточной для 24-х бит, хоть и в более "могучем" "калькуляторе".
 
  • Like
Реакции: Alexander Yakuba
входящий семпл (семплы) для расчета - какой системы?
ну это да, но это уже второй вопрос. да и в плагинах скорее всего раньше этот самый флоат захардкоживали, да и дело с концом. так что смысла особого нет, потому и вычитается всё опять же в ноль либо в минус 100500...
 
@max-owl, Вы опять путаете х.. с пальцем. Причём здесь формат и разрядность физических файлов, когда речь о разрядности микширования внутри самой DAW.
 
  • Like
Реакции: max-owl и Sharu
ну это да, но это уже второй вопрос. да и в плагинах скорее всего раньше этот самый флоат захардкоживали, да и дело с концом. так что смысла особого нет, потому и вычитается всё опять же в ноль либо в минус 100500...
Да для музыкантов - звукорежиссёров этот аспект вообще не имеет значения никакого. Что бы эти ошибки слышимы стали их "накопить" ещё надо. Чисто умозрительная разница.
 
  • Like
Реакции: Alexander Yakuba
Спасибо, Zerocool, а то я уже ставить ее собрался.:)
Да, очевидно математика микширования и способность "видеть" 64-х битную "вавку" между собой у S1 ни как не коррелирует...
А битметр мог показать результат работы DAW: раз "64" не распознаётся, значит и звуковой семпл будет 32-х битный.
 
Близко по теме 64-битного движка Рипер, недавно попался топик на gearspace.
Разрядность внутренней обработки плагина и ошибки квантования
Всего - вопрос, два ответа.
-- --
- Привет, я использую Reaper, и, насколько мне известно, он имеет 64-битный звуковой движок с плавающей запятой (в настройках проекта битовая глубина микширования треков по умолчанию установлена на 64-битную с плавающей запятой).
Как и большинство из нас, я использую ряд плагинов с разной внутренней разрядностью. Насколько я понимаю, есть плагины, некоторые из которых являются 64-битными fp полностью, некоторые из них являются 64-битными fp, но выход плагина составляет 32-битную fp (я тестировал плагины волн с помощью битметра Stillwell, и я думаю, что они работают так или полностью 32-битными. Также L2 и LinMB - 48-битные, согласно их руководству). Интересно, приводит ли стекирование плагинов с разной битовой глубиной к каким-либо ошибкам квантования в этом сценарии. Если это так, то каков наилучший способ минимизировать это (установить Reaper на 32-битную плавающую запятую и использовать только 32-битные плагины fp или оставить все как есть и использовать только 64-битные плагины fp?)?
Или в конце концов это будет устранено с помощью дизеринга?
Здесь я хотел бы подчеркнуть: тема, возможно, немного занудная, а значения ошибок могут быть очень низкими, но я все равно хочу знать.
-- --
- Оставьте Reaper в 64 бита. Плагины, которые вводят и выводят 32-битные данные, вносят небольшие ошибки квантования. Но поскольку всё это с плавающей запятой, происходит самодизеринг с 64-битного значения с плавающей запятой на 32-битное с плавающей запятой. Таким образом, вы не получите неприятных искажений квантования, как при переходе с плавающей запятой на фиксированную запятую. Я убежденный сторонник дизеринга с фиксированной запятой, даже в 24 битах. Но я не уверен, что есть большая польза от плагинов, имеющих 64-битный ввод и вывод. Теоретически должно быть лучше, но учитывая принцип работы float, я не думаю, что это большая проблема. Так что можете быть уверены: думаю, вы ничего не потеряете, используя 32-битные плагины. Некоторые используют 64-битную внутреннюю версию, и это всё что им нужно. Но для меня важнее не забывать о дизеринге при преобразовании в фиксированную запятую, в том числе в идеале для мониторинга.
-- --
Точность 32-битной обработки находится в районе -150 дБ, поэтому шум при 32-битном микшировании незначителен, а при 64-битной обработке и того лучше. /от себя добавлю, -320 дБ/
Важно то, что обработка шины не является итеративной, поэтому шум не будет накапливаться во что-то слышимое, так что не беспокойтесь об этом. С другой стороны, внутренняя обработка плагинов, то есть итеративная обработка переменных состояния, будет иметь более высокую точность и почти всегда выполняется с точностью до 64 бит, чтобы избежать проблем с шумом.
 
Я конечно не настоящий сварщик (в том смысле что программистом по своей специальности не работал ни дня), но... нет никакой особенной "математики" там, имхо. Есть стандарт ieee754 который аппаратно реализован в процах (математический сопроцессор), и все вычисления производятся посредством него. В идеале вся "математика" 32 на 64 меняется заменой типа всего одной переменной (хранящей текущий семпл) с типа float на тип double. Господа практикующие программисты - всё так ведь плюс-минус? :)
Александр не буду утверждать, предположу. Приведение к типу будет, а как?....это будет зависеть от яп.
 
  • Like
Реакции: Alexander Yakuba
Не-не. У мну семплы были 64-х разрядные из "Кейквока", так вот 4-й их не распознавал (wav-ки) и сам "в такое" еще не умел.
По-моему вы запутались. 4ка, если я не путаю ничего, только с маковским ААС расширением аудио не могла работать.
 
Близко по теме 64-битного движка Рипер, недавно попался топик на gearspace.
Разрядность внутренней обработки плагина и ошибки квантования
Всего - вопрос, два ответа.
-- --
- Привет, я использую Reaper, и, насколько мне известно, он имеет 64-битный звуковой движок с плавающей запятой (в настройках проекта битовая глубина микширования треков по умолчанию установлена на 64-битную с плавающей запятой).
Как и большинство из нас, я использую ряд плагинов с разной внутренней разрядностью. Насколько я понимаю, есть плагины, некоторые из которых являются 64-битными fp полностью, некоторые из них являются 64-битными fp, но выход плагина составляет 32-битную fp (я тестировал плагины волн с помощью битметра Stillwell, и я думаю, что они работают так или полностью 32-битными. Также L2 и LinMB - 48-битные, согласно их руководству). Интересно, приводит ли стекирование плагинов с разной битовой глубиной к каким-либо ошибкам квантования в этом сценарии. Если это так, то каков наилучший способ минимизировать это (установить Reaper на 32-битную плавающую запятую и использовать только 32-битные плагины fp или оставить все как есть и использовать только 64-битные плагины fp?)?
Или в конце концов это будет устранено с помощью дизеринга?
Здесь я хотел бы подчеркнуть: тема, возможно, немного занудная, а значения ошибок могут быть очень низкими, но я все равно хочу знать.
-- --
- Оставьте Reaper в 64 бита. Плагины, которые вводят и выводят 32-битные данные, вносят небольшие ошибки квантования. Но поскольку всё это с плавающей запятой, происходит самодизеринг с 64-битного значения с плавающей запятой на 32-битное с плавающей запятой. Таким образом, вы не получите неприятных искажений квантования, как при переходе с плавающей запятой на фиксированную запятую. Я убежденный сторонник дизеринга с фиксированной запятой, даже в 24 битах. Но я не уверен, что есть большая польза от плагинов, имеющих 64-битный ввод и вывод. Теоретически должно быть лучше, но учитывая принцип работы float, я не думаю, что это большая проблема. Так что можете быть уверены: думаю, вы ничего не потеряете, используя 32-битные плагины. Некоторые используют 64-битную внутреннюю версию, и это всё что им нужно. Но для меня важнее не забывать о дизеринге при преобразовании в фиксированную запятую, в том числе в идеале для мониторинга.
-- --
Точность 32-битной обработки находится в районе -150 дБ, поэтому шум при 32-битном микшировании незначителен, а при 64-битной обработке и того лучше. /от себя добавлю, -320 дБ/
Важно то, что обработка шины не является итеративной, поэтому шум не будет накапливаться во что-то слышимое, так что не беспокойтесь об этом. С другой стороны, внутренняя обработка плагинов, то есть итеративная обработка переменных состояния, будет иметь более высокую точность и почти всегда выполняется с точностью до 64 бит, чтобы избежать проблем с шумом.
Очень все спорно. Битметр-такая штука, требующая побитового сравнения результата, а штилвелловский битметр (если не путаю, который на eel написан) при инициализации выражения уже работает(работает вроде правильно, но не совсем) с денормализованным значением теряя около 4 бит точности. В eel2 через одно место , вернее не полностью реализован тип int64. Также почему-то разговор идет о полном диапазоне в 320 dbfs. Само понятие микширование(сугубо мое видение на проблему) 64bit float подразумевает воздействие на фейдер громкости на каналах, те если говоря на языке реализации вст3, например: имеем значение тишины -96dbfs(нормализованное значение=0) и максимальное значение-->например в 0dbfs(нормализованное значение равное 1) все,(один шаг) что между 0 и 1 имеет точность в 64 бита, фильтрация денормализованных значений нужна для того, чтобы не произошло переполнение типа и следующего за этим непредсказуемого поведения при вычислениях,(ub)как-то так, все грубо и на пальцах и конечно же имха без всяких намёков на холивар. Интересно есть ли стандартизированное значение(не строковая замена inf/-00) тишины....
 
Мож, для начала максимально увеличить в длину эти два параллельных файла? И сравнить обе огибающие визуально.
 

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