Waves плагины. Дела проблемные - разбираемся, пытаемся решить
- Автор темы pse
- Дата начала
Да вобще, сначала надо узнать какого характера этот треск. Мож внатуре ресурсов не хватает. А мы тут: релиз, уровень....
А может это глюк с Waves? треск то после повторного открытия секвенсора
или сразу же, как повесил?
или сразу же, как повесил?
На входе максимайзера сигнал должен быть меньше нуля. Например в Нюендо если ставить максимайзер на мастер, то обязательно в один из старших инсертов (те что после фэйдера). И если сумма превосходит ноль, то следует опустить фэйдер так, чтоб сигнал имел запас хоть 0.5 дБ и тогда треска не будет.
Сейчас игрался с компрессором от waves - RComp и обнаружил такую вещь: при экстремально малых значениях атаки и релиза сигнал начинает сжиматься компрессором ещё до превышения им(сигналом) порога. Сам этот момент предкомпрессии состовляет ~1 ms. Сравнивал с другими компрессорами: С1, SSL Comp, SSL Channel, Sonitus - Compressor, Sonalksis - Compressor, Sony - Wave Hammer. Такая же реакция только у Вейв хаммера, но у него всегда, как я понял, работает look-ahead, разница только в длительности этого предвидения. Тестил на сигнале: синус 4300.00 Hz -24 dB, в середине вавки увеличил амплитуду на 18 dB. Настройки RComp ставил в положение: Tresh -22.6 dB , Attack 0.5 ms, Release 5 ms, Ratio 50, лампы: Manual, Electro, Smooth. В других компрессорах ставил так же, если было возможно. Я так понимаю что RComp использует функцию look-ahead?, но в мануале об этом нигде не написанно... (если написанно ткните меня носом 
), иначе я никак не могу объяснить, такое поведение компрессора.
P.S. Можете мне объяснить функцию PDR в компрессоре Waves - C1, никак не могу понять что она делает. Кто то помню на форуме давно писал, но я так и не разобрался.
((
), иначе я никак не могу объяснить, такое поведение компрессора. P.S. Можете мне объяснить функцию PDR в компрессоре Waves - C1, никак не могу понять что она делает. Кто то помню на форуме давно писал, но я так и не разобрался.
((
Теоретически она должна уменьшать release во время транзиентов. Практического же эффекта от нее я как-то не наблюдал.
а зачем?
Что касается PDR - это Program Dependent Release, он отвечает за автоматическое уменьшения времени восстановления компрессора (Release Time) для взрывных коротких сигналов (плюхнулся у тя крэшик, уровень резко поднялся, компрессор сработал, подавил, крэш кончился, а время восстановления достаточно большое и компрессор ещё работает, в итоге за крэшем на сигнале образуется провал по уровню), сохраняя установленное значение Release для боле-менее стабильных по уровню (а подчас и увеличивая, зависит от алгоритма). Всё это позволяет снизить искажения вносимые компрессором.
Какие там значения что означают - надо посмотреть в мануале, но возможно там устанавливается более короткий Release, который будет использоваться при включении PDR. Примерно так
Ну и про look-ahead - возможно это просто режим Smooth так работает.
Я где-то читал что PDR в С-1 то-же самое что ARC в RComp. Только почему-то названия разные у них. Auto Release Compensation. А вот на счёт задержки, не знал.... А где можно найти таблицу с задержками от Waves?
возможно благодаря функции look ahead soft-knee компрессор начинает работать чуть раньше порога срабатывания и когда сигнал достигает порога срабатывания, то примерно в этот момент достигается желаемое компрессионное отношение.
NEUTRi, ты точно уверен что только при малых значениях атаки и релиза у RComp такое поведение?
rainbowmystery Сигнал начинает понижаться примерно за 1 ms до того как превысит порог срабатывания. В первом посте я написал все настройки с которыми тестировал плаг, можете проверить сами
Elle Да мне собственно интересно потому, что это моя рабочая лошадка, я его постоянно использую. Я был удивлён такому поведению компрессора, т.к. всегда думал что плаг в реальном времени работает, без задержек и предосмотра. Это и не плохо и не хорошо, видимо так плаг работает, он от этого хуже не становится
Хотел прикрепить картинку, куда можно быстро залить без регистрации?
Elle Да мне собственно интересно потому, что это моя рабочая лошадка, я его постоянно использую. Я был удивлён такому поведению компрессора, т.к. всегда думал что плаг в реальном времени работает, без задержек и предосмотра. Это и не плохо и не хорошо, видимо так плаг работает, он от этого хуже не становится
Хотел прикрепить картинку, куда можно быстро залить без регистрации?
А если сделать такой-же тест, но только в других режимах. Opto и Smooth. Насчёт второго я не уверен, вроде-бы он скорее всего влияет на тембр или окрас звука. А вот Opto-Electro возможно влияет на переходную х-ку. Попробуй, какие там результаты будут....
Если честно, то я вобще не могу понять, какая связь между алгоритмом look ahead и тем что компрессор начинает работать до превышения сигнала порога. Он ведь должен только давать задержку, в зависимости от того, на сколько далеко он "глядит". Т.е сколько времени ему нужно для того, чтобы переключить все параметры в нужное положение.
вообще я не знаю точно как работает look-ahead, но могу сделать может и глупое но предположение, что продетектровав буфер вперёд, рассчитаный Пик получился чуть раньше, чем он есть с точки зрения посэмпловой амплитуды (помните что Peak - это не значение сигнала в каждом сэмпле). Т.е. в окно (буфер) look-ahead попал маленький кусочек синусоиды с амплитудой ниже Threshold и большой кусок с амплитудой превышающей порог. Вычисленный Peak Level в этом окне оказался больше чем Threshold и компрессор начал сжимать сигнал, хотя по времени до "реального" пика он ещё не добрался. И чем ближе окно приближается к "реальному" всплеску, тем вычисляемое в нём (окне) значение Peak Level больше и потому усиливается компрессия.
Хотя может я и не права
Хотя может я и не права