olegsound, ну тогда вот позвольте вполне резонный вопрос, зачем тогда приводить, как это принято делать материал к максимальной разрядности - к 32, перед обработкой?
помощь в приведении фонограграмм к общему уровню! Вопросы по лимитированию и тп?
- Автор темы FLO
- Дата начала
Смотря кто в чем и какими плагинами обрабатывает. Ситуации бывают разные. Чтоб не было всяких транкейтов и прочей радости. И при чем тут Куб? Я думаю реставрацию и мастеринг никто в нем не делает? Впрочем у каждого свой вкус...
Я не знаю зачем, я так никогда не делаю.:yes: Перед деструктивной обработкой (напр. в Sound Forge) нужно переводить файл в 32 бита. А в Кубе/Нуендо при виртуальной обработке это не нужно. Если у меня файл 16 или 24 бита - просто импортирую в проект и работаю. Ну и понятно, что если после сведения у вас на мастере получается уровень -20, то лучше просто сделать мониторы потише.:biggrin:
FLO, представь что у тебя два бита - то есть громкость в каждой точке (каждого сэмпла) может быть только 25%, 50%, 75%, 100% (ну или -12dB, -6dB, -2.5dB, 0dB). А если три бита - то 12.5%, 25%, 37.5%, 50%, ... В децибелах это -18dB, -12dB, -8.5dB, -6dB, ... Следующая после нуля (самая тихая) точка будет в 2 раза меньше по звуковому давлению, то есть на 6dB меньше. Это вовсе не значит, что этот бит "кодирует" эти последние несчастные 6dB, важно, что он добавляет точки между уже имеющимися, повышая разрешение в 2 раза. Потеря одного бита (при нормализации), про что часто говорят - это исходный сигнал тише чем -6dB (то есть 50%), потеря двух бит: -12dB (то есть 25%), и т.д. Попробуй нормализовать любой 3х битный сигнал с пиком в -12dB, то есть принимающий значения -18dB/-12dB: умножаешь на 4 для приведения к нулю и получаешь -6dB/0dB - то есть 1-битный сигнал в чистом виде. Соответственно если ты понизишь в хосте громкость сигнала в два раза, а потом отправишь его в плагин, ты фактически потеряешь 1 бит, т.к. плагин "не знает" сигнал в исходном разрешении и будет сам его криво нормализовать. Отсюда и все вытекающие возможности и последствия. Вот подумай, например, какая разница, если ты у двухбитного сигнала поднимаешь гейн (например на 12.5%) в двухбитной среде или трехбитной? Много в какой обработке и синтах, кстати,используется оверсэмплинг - т.е. разрешение как раз завышается на время вычислений. По поводу транкейта: в примере если хост транкейтит обратно обработанный 3х-битный сигнал до 2 бит - тогда все точки типа 12.5%, 37.5% уедут либо вниз, либо вверх.
Кстати, 32 бит по сравнению с 16 - это как бы между каждыми двумя точками 16-битной сетки громкостей поместить еще по полной 16-битной сетке, то есть точность возрастает адски. 24 бита по сравнению с 16 - это 256 точек между каждыми двумя имеющимися.
Кстати, 32 бит по сравнению с 16 - это как бы между каждыми двумя точками 16-битной сетки громкостей поместить еще по полной 16-битной сетке, то есть точность возрастает адски. 24 бита по сравнению с 16 - это 256 точек между каждыми двумя имеющимися.
пипец приехали...
Потеря информации и, соответственно, качества ЦИФРОВОГО представления сигнала может происходить в процессе конвертации аналогового сигнала в цифровой, т.е. в АЦП. АЦП с малым значением выборки (16 или 8 бит) будет иметь проблемы при низких входных уровнях сигнала. Это связано прежде всего с физкой, а не математикой. Тут и корелляция с шумами квантования, и недостаточность градаций для отображения достаточного кол-ва точек амплитуд - все верно.
В данном случае мы же говорим об уже оцифрованном сигнале, имющим свой конечный уровень информативности. Загружая в хост любой 16 битный файл мы, грубо говоря, дорисовываем нули и ничего этим не улучшаем. (не путайте с ОБРАБОТКОЙ - это уже ИЗМЕНЕНИЕ информации, для этого и нужна повышенная точность, т.к. некоторые алгоритмы требуют большого кол-ва операций)
Понижение или повышение фейдера в программе НИКАК не может изменить кол-во информации в звуке, так и вызвать "перегруз"!!!!! Это бред!! Движок микшера в нуендо 80 битный и мы просто позиционируем 32 битные данные в этой сетке относительно друг друга - вот и все фейдера. Внутреннее представление данных в нуендо - ТОЛЬКО 32х битное и , какие бы файлы мы туда не загрузили - весь обмен данными внутри программы будет происходить только в 32 бит. (можно пересчитать файлы в 32 бита (нуендо спрашивает при загрузке) для сохранения в таком виде в пуле или не пересчитывать и нуенда будет это делать "на лету" - без разницы на результат работы)
Нормализовать или нет файлы - вопрос чисто удобства, чтобы потом на максимайзере не запутаться как ставить трешхолд, а то получится что на одной вещи с трешхолдном в -15 выхлоп будет звучать тише чем на другой с трешхолдом в -5.
Мой вам добрый совет - не париться. Если ваша задача - пакетная обработка множества готовых отдельных файлов - Daw-мультитрекер вам ни к чему. поставьте в вавлабе батч процесс на конвертацию в 32 флоат и нормализацию. Потом рассортируйте полученные файлы по харакрету на несколько типов звучания и подберите к ним пресеты на понравившимся максимайзере и потом прогоните все это дело. Это если файлов много и надо побыстренькому, а так лучше - к каждому свои настройки покрутить, время атаки там, подобрать разные плагины и тд . Удачи!!
Потеря информации и, соответственно, качества ЦИФРОВОГО представления сигнала может происходить в процессе конвертации аналогового сигнала в цифровой, т.е. в АЦП. АЦП с малым значением выборки (16 или 8 бит) будет иметь проблемы при низких входных уровнях сигнала. Это связано прежде всего с физкой, а не математикой. Тут и корелляция с шумами квантования, и недостаточность градаций для отображения достаточного кол-ва точек амплитуд - все верно.
В данном случае мы же говорим об уже оцифрованном сигнале, имющим свой конечный уровень информативности. Загружая в хост любой 16 битный файл мы, грубо говоря, дорисовываем нули и ничего этим не улучшаем. (не путайте с ОБРАБОТКОЙ - это уже ИЗМЕНЕНИЕ информации, для этого и нужна повышенная точность, т.к. некоторые алгоритмы требуют большого кол-ва операций)
Понижение или повышение фейдера в программе НИКАК не может изменить кол-во информации в звуке, так и вызвать "перегруз"!!!!! Это бред!! Движок микшера в нуендо 80 битный и мы просто позиционируем 32 битные данные в этой сетке относительно друг друга - вот и все фейдера. Внутреннее представление данных в нуендо - ТОЛЬКО 32х битное и , какие бы файлы мы туда не загрузили - весь обмен данными внутри программы будет происходить только в 32 бит. (можно пересчитать файлы в 32 бита (нуендо спрашивает при загрузке) для сохранения в таком виде в пуле или не пересчитывать и нуенда будет это делать "на лету" - без разницы на результат работы)
Нормализовать или нет файлы - вопрос чисто удобства, чтобы потом на максимайзере не запутаться как ставить трешхолд, а то получится что на одной вещи с трешхолдном в -15 выхлоп будет звучать тише чем на другой с трешхолдом в -5.
Мой вам добрый совет - не париться. Если ваша задача - пакетная обработка множества готовых отдельных файлов - Daw-мультитрекер вам ни к чему. поставьте в вавлабе батч процесс на конвертацию в 32 флоат и нормализацию. Потом рассортируйте полученные файлы по харакрету на несколько типов звучания и подберите к ним пресеты на понравившимся максимайзере и потом прогоните все это дело. Это если файлов много и надо побыстренькому, а так лучше - к каждому свои настройки покрутить, время атаки там, подобрать разные плагины и тд . Удачи!!
ппц.. звезда в шоке...
1) Clip Gain, Track Fader, Limiter Threshold - это 3 большие разницы. Оч сильно завсият от роутинга аудио в хосте. Обычно сначала идёт clip gain (pre-insert), потом уровень регулируется эффектами в инсёрте, потом уровень регулируется track fader'ом (post-insert).
2) Limiter Threshold устанавливает пороговое значения для срабатывания лимитера - начиная с какого уровня давить пики. Limiter Threshold не задаёт коэффциент усиления после лимитирования. Алгоритм Auto MakeUp Gain вообще говоря может отличаться от ручного Output gain. Поэтому threshold = -6 dB это совсем не то же самое, что увеличить громкость трэка на 6 дБ
Waves L-Series работает так. На примере Threshold = -6дБ:
- пытается срезать всё, что превосходит уровень в -6дБ в меру заложенного в него алгоритма лимитирования
- вычисляет коэффециент нормализации: Out Ceiling - Threshold
если Out Ceiling = 0 дБ, то коэффециент нормализации = 0дБ - (-6дБ) = 0дБ + 6дБ = +6дБ
если Out Ceiling = -3 дБ, то коэффециент нормализации = -3дБ - (-6дБ) = -3дБ + 6дБ = +3дБ
если Out Ceiling = -6 дБ, то коэффециент нормализации = -6дБ - (-6дБ) = -6дБ + 6дБ = 0дБ
если Out Ceiling = -12 дБ, то коэффециент нормализации = -12дБ - (-6дБ) = -12дБ + 6дБ = -6дБ
Только он на так и Out Ceiling что используется уже ПОСЛЕ лимитирования. Т.е. Threshold = -30dB, Out Ceiling = 0dB сначала уплющит сигнал до -30дБ, а потом просто сделает результат погромче на +30дБ
3) прежде чем пользоватсья плаг-ином, особенно когда ерчь идёт о мастеринге, неплохо было бы прочитать мануал. В них указаны все нюансы работы с уровнями сигнала, битностью сигнала, дизерингом, нойз шейпингом и т д.
4) хост работает обычно с фиксированной битностью. Например Нуенда работает в 32-bit float. Project Bit Depth означает битность ХРАНИМЫХ звуковых файлов, используемых в проекте. Но не более того.
Битность хоста и битность плаг-инов так же может различаться (возьмите тот же Waves L2!!!!).
так например, если Project Bit Depth = 16 bit, то вы имеете следующую картинку:
real-time:
16 бит целочисленные (исходный файл/Project Bit Depth) -> 32 бит с плавающей точкой (нуенда) -> 48 бит целочисленные (Waves L2) -> 32 бит с плавающей точкой (нуенда)
offline:
16 бит целочисленные (исходный файл/Project Bit Depth) -> 32 бит с плавающей точкой (нуенда) -> 48 бит целочисленные (Waves L2) -> 32 бит с плавающей точкой (нуенда) -> 16 бит целочисленные (Project Bit Depth)
ну и разумеется при прослушивании обоих вариантов на боле-менее адекватной карточке -> 24 бит целочисленные (sound card output)
при этом все эти переконвертации могут происходить оч неоднозначно. Где и сколько дизеринга при этом используется - тоже большой вопрос. В том числе и к вам, как к человеку, который обязан в этом разбираться.
Не разбираясь в этих нюансах советовать всякие нормализации и конвертации в 32 флоат как минимум некорректно.
5) Стандарты на измерение RMS оч разные и сильно зависят от настроек и алгоритма измерителя. Поэтому говорить, что мне нужен РМС = -20, вполне может означать -10 на другом измерителе и -30 на третьем.
Совсем не поняла фразу "все к значению строго не превышающем -9 по пикам" - не конечно требования разные бывают.. но о КАКИХ ПИКАХ идёт речь... пиках в РМС-измерениях???? или вообще.. о самых что ни на есть мгновенных знчениях сигнала??? Если последнее, то оч интересно для чего это нужно.. Если не последнее.. как-то по прочитаннному берут сомнения, что у многих написавших тут вообще есть понимание пиков при РМС-измерении...
6)
вариант а)
- 2 идентичных трэка с 2-мя идентичными клипами соответственно
- один клип обрабаотываем L1 оффлайн, так что теперь один из клипов приплюснутый лимитером (насколько сильно приплюснутый и с каким уровнем на выходе - вообще говоря загадка, как впрочем и исходный урвоень пиков в клипе)
- на второй клип Л1 в риал-тайме с тем же настройками
- после этого опускаем гейн на обоих клипах
результат а)
- клип1 обработан лимитером и после этого занижен уровень гейном
- клип2 сначала занижен гейн, потом обработан лимитером.
разумеется разница будет ощутима, особенно если занижение гейна существенно ниже порога срабатывания лимитера
вариант б)
- 2 идентичных трэка с 2-мя идентичными клипами соответственно
- опускаем гейн на обоих клипах
- один клип обрабатываем L1 оффлайн
- на второй клип Л1 в риал-тайме с тем же настройками
результат б)
- если битность проекта совпадает с битностью хоста (32 бита флоат скажем), то разница не будет вообще никакой
- если битность проекта меньше битности хоста (16 бит интеджер - проект; 32бит флоат - хост), то разница в том, что файл с оффлайновой обработкой будет оттранкейчен (может и с дизерингом - зависит от настроек хоста/плаг-ина) в 16 бит. В то же время приницпиальной разницы как в случае варианта а) всё равно не получится.
1) Clip Gain, Track Fader, Limiter Threshold - это 3 большие разницы. Оч сильно завсият от роутинга аудио в хосте. Обычно сначала идёт clip gain (pre-insert), потом уровень регулируется эффектами в инсёрте, потом уровень регулируется track fader'ом (post-insert).
2) Limiter Threshold устанавливает пороговое значения для срабатывания лимитера - начиная с какого уровня давить пики. Limiter Threshold не задаёт коэффциент усиления после лимитирования. Алгоритм Auto MakeUp Gain вообще говоря может отличаться от ручного Output gain. Поэтому threshold = -6 dB это совсем не то же самое, что увеличить громкость трэка на 6 дБ
Waves L-Series работает так. На примере Threshold = -6дБ:
- пытается срезать всё, что превосходит уровень в -6дБ в меру заложенного в него алгоритма лимитирования
- вычисляет коэффециент нормализации: Out Ceiling - Threshold
если Out Ceiling = 0 дБ, то коэффециент нормализации = 0дБ - (-6дБ) = 0дБ + 6дБ = +6дБ
если Out Ceiling = -3 дБ, то коэффециент нормализации = -3дБ - (-6дБ) = -3дБ + 6дБ = +3дБ
если Out Ceiling = -6 дБ, то коэффециент нормализации = -6дБ - (-6дБ) = -6дБ + 6дБ = 0дБ
если Out Ceiling = -12 дБ, то коэффециент нормализации = -12дБ - (-6дБ) = -12дБ + 6дБ = -6дБ
Только он на так и Out Ceiling что используется уже ПОСЛЕ лимитирования. Т.е. Threshold = -30dB, Out Ceiling = 0dB сначала уплющит сигнал до -30дБ, а потом просто сделает результат погромче на +30дБ
3) прежде чем пользоватсья плаг-ином, особенно когда ерчь идёт о мастеринге, неплохо было бы прочитать мануал. В них указаны все нюансы работы с уровнями сигнала, битностью сигнала, дизерингом, нойз шейпингом и т д.
4) хост работает обычно с фиксированной битностью. Например Нуенда работает в 32-bit float. Project Bit Depth означает битность ХРАНИМЫХ звуковых файлов, используемых в проекте. Но не более того.
Битность хоста и битность плаг-инов так же может различаться (возьмите тот же Waves L2!!!!).
так например, если Project Bit Depth = 16 bit, то вы имеете следующую картинку:
real-time:
16 бит целочисленные (исходный файл/Project Bit Depth) -> 32 бит с плавающей точкой (нуенда) -> 48 бит целочисленные (Waves L2) -> 32 бит с плавающей точкой (нуенда)
offline:
16 бит целочисленные (исходный файл/Project Bit Depth) -> 32 бит с плавающей точкой (нуенда) -> 48 бит целочисленные (Waves L2) -> 32 бит с плавающей точкой (нуенда) -> 16 бит целочисленные (Project Bit Depth)
ну и разумеется при прослушивании обоих вариантов на боле-менее адекватной карточке -> 24 бит целочисленные (sound card output)
при этом все эти переконвертации могут происходить оч неоднозначно. Где и сколько дизеринга при этом используется - тоже большой вопрос. В том числе и к вам, как к человеку, который обязан в этом разбираться.
Не разбираясь в этих нюансах советовать всякие нормализации и конвертации в 32 флоат как минимум некорректно.
5) Стандарты на измерение RMS оч разные и сильно зависят от настроек и алгоритма измерителя. Поэтому говорить, что мне нужен РМС = -20, вполне может означать -10 на другом измерителе и -30 на третьем.
Совсем не поняла фразу "все к значению строго не превышающем -9 по пикам" - не конечно требования разные бывают.. но о КАКИХ ПИКАХ идёт речь... пиках в РМС-измерениях???? или вообще.. о самых что ни на есть мгновенных знчениях сигнала??? Если последнее, то оч интересно для чего это нужно.. Если не последнее.. как-то по прочитаннному берут сомнения, что у многих написавших тут вообще есть понимание пиков при РМС-измерении...
6)
у меня если честно 2 варианта прочитанного:
вариант а)
- 2 идентичных трэка с 2-мя идентичными клипами соответственно
- один клип обрабаотываем L1 оффлайн, так что теперь один из клипов приплюснутый лимитером (насколько сильно приплюснутый и с каким уровнем на выходе - вообще говоря загадка, как впрочем и исходный урвоень пиков в клипе)
- на второй клип Л1 в риал-тайме с тем же настройками
- после этого опускаем гейн на обоих клипах
результат а)
- клип1 обработан лимитером и после этого занижен уровень гейном
- клип2 сначала занижен гейн, потом обработан лимитером.
разумеется разница будет ощутима, особенно если занижение гейна существенно ниже порога срабатывания лимитера
вариант б)
- 2 идентичных трэка с 2-мя идентичными клипами соответственно
- опускаем гейн на обоих клипах
- один клип обрабатываем L1 оффлайн
- на второй клип Л1 в риал-тайме с тем же настройками
результат б)
- если битность проекта совпадает с битностью хоста (32 бита флоат скажем), то разница не будет вообще никакой
- если битность проекта меньше битности хоста (16 бит интеджер - проект; 32бит флоат - хост), то разница в том, что файл с оффлайновой обработкой будет оттранкейчен (может и с дизерингом - зависит от настроек хоста/плаг-ина) в 16 бит. В то же время приницпиальной разницы как в случае варианта а) всё равно не получится.
Хз, если ты фейдером понизил на -12 нормальный аудиосигнал и потом прогнал его через максимайзер с потолком -15 - ты фактически потеряешь два бита разрешения на этом по сравнению с отправкой нормального сигнала (только если сигнал изначально имел пиковую громкость выше -6) на максимайзер с порогом -3. Это конечно ситуация нетипичная и бредовая, но смысл ясен.
Вот же скучный мы народ, на любом другом музфоруме топик бы уже давно скатился в проблему Cubase vs Logic как источник всех зол :big_boss:
Нет, ну это всё понятно, конечно, но всё-таки, при чём здесь нормалайз?!! Чем он поможет в 32 битном с плавающей запятой хосте, коими практически все являются? ДА и хосты с фиксированной точкой как-то эту проблему обходят. Ладно, утомляет меня это. Продолжайте без меня.
Я вообще не понимаю о чем это вы???
Человеку надо привести все к уровню "0", а потом если надо что-то еще обработать. Я так понимаю что для этого придуман нормалайз, вот отсюда и весь разговор. Применять вместо нормалайза максимайзер как минимум неудобно...
Человеку надо привести все к уровню "0", а потом если надо что-то еще обработать. Я так понимаю что для этого придуман нормалайз, вот отсюда и весь разговор. Применять вместо нормалайза максимайзер как минимум неудобно...
Aldanor написал(а):
Да нет же! Ребята, Вы что такое говорите?! Капец.. Такие топики - как омут. СЛожно из этого бреда выбраться. Ну ничего, у меня интернет сейчас ограничен. Это и спасёт
это очень спорное утверждение так как обычно фейдер регулирует уровень после fx insert (в нуенде надо уточнить - не помню)Aldanor написал(а):
более того, даже если фейдер включается до инсёртов, при обработке в 32 флоат ничего катастрофического он не потеряет. А в каком-то смысле даже приобретёт, так как уровни от -оо дБ до 0дБ преобразуются в значения от 0 до 1 при конвертации во флоат, и так как природа чисел с плавающей точкой увелчиивает количество промежуточных значений с приближением к 0)))
вообще человеку надо привести несколько тржков к одному уровню, а вот что он под этьим подразумевает и как к этому идти - зависит от его требований, от самого материла и используемого ПО.sunet написал(а):
счастливчик, а я на работу опаздываю)))))))))Rustami написал(а):
Elle:
"при этом все эти переконвертации могут происходить оч неоднозначно. Где и сколько дизеринга при этом используется - тоже большой вопрос. В том числе и к вам, как к человеку, который обязан в этом разбираться.
Не разбираясь в этих нюансах советовать всякие нормализации и конвертации в 32 флоат как минимум некорректно."
как понял это в мой адрес...:swoon:
уважаемая оппонентка, какой дизеринг? какие нюансы? вы оп чем? в нуендо никакого принудительного дизеренга непонятно где не происходит. Более того - автору топика ВООБЩЕ нуендо не нужна для его задач, как не нужны и никакие дизеренги, об чем я и сказал выше. Нормализовать файлы нужно тупо в любом wav editor-e для удобства работы с ними, а перевести в 32 флоат - чтобы обработка точнее работала. Все!!!
"при этом все эти переконвертации могут происходить оч неоднозначно. Где и сколько дизеринга при этом используется - тоже большой вопрос. В том числе и к вам, как к человеку, который обязан в этом разбираться.
Не разбираясь в этих нюансах советовать всякие нормализации и конвертации в 32 флоат как минимум некорректно."
как понял это в мой адрес...:swoon:
уважаемая оппонентка, какой дизеринг? какие нюансы? вы оп чем? в нуендо никакого принудительного дизеренга непонятно где не происходит. Более того - автору топика ВООБЩЕ нуендо не нужна для его задач, как не нужны и никакие дизеренги, об чем я и сказал выше. Нормализовать файлы нужно тупо в любом wav editor-e для удобства работы с ними, а перевести в 32 флоат - чтобы обработка точнее работала. Все!!!
я об этомИспанский ГалстоГ написал(а):
в частоности о нюансах в упомянутых выше 48 битах в Waves L2, о том как они раскладываются на диапазон уровней, какой происходит дизеринг и происходит ли на выходе из плаг-инаElle написал(а):
в нуендно может и не происходит, в другх редакторах вполне может происходить. Вполне понятный. И вполне настраиваемый в настройках программы. Только об этом надо знать и учитывать с каким материалом ты работаешь.Испанский ГалстоГ написал(а):
я с этим где-то спорила?Испанский ГалстоГ написал(а):
удобство - не значит нужно, тем более когда тупо. Нормализовать можно, но необязательно, так как удобство - понятие субъективное.Испанский ГалстоГ написал(а):
ага, можно перевести в 32 флоат, а обработка например будет происходить в 24 бит интеджер или в 64 флоат - зависит от обработки. Формат хренения файла разумно выставлять только для оффлайн обработки в несколько шагов. Чтобы промежуточные результаты между шагами не теряли битность, полученную при повышенной обработке.Испанский ГалстоГ написал(а):
Тем не менее имея файл 16 бит 44 кГц я не вижу НИКАКОЙ необходмости конвертировать его в 32 флоат независимо от исопльзуемого редактора, если в качестве обработки будет всё равно только один лимитер. На выходе вы ему всё равно выставите ограничение в 16 или 24 с соовтетствующим дизерингом/нойз шейпингом (в зависимости от типа носителя/формата на котором впоследствии будет рапсространятсья материал). Так зачем излишние действия в этом случае?
ЗЫшка:
то о чём говорю я, может совершенно не противоречить некоторым высказываниям в определённых ситуациях. Просто надо головой думать и отличать кажду ситуацию, чтоб правильнее провести необходимую обработку с минимальным количеством излишней обработки которая может приветси к потере качества.
Эхххх. не хочу с девушкой спорить........
но вы, девушко, довольно вредная оказались )))
я говоил что не НУЖНО нормальзовать обязательно, а нормализовать нужно не в мультитрекере, а в эдиторе. Разные вещи, да? Тупо - значит ПРОЩЕ, а не о блондинках. В 32 флоат потому и переводить, что большинство плагов согласно спецификации SDK ASIO заточены под этот формат, и еще чтобы четко весь процесс переводов и дитеренгов самому отслеживать, а не отдавать на откуп плагам.
вот вам месть,классная очепатка: )))
но вы, девушко, довольно вредная оказались )))
я говоил что не НУЖНО нормальзовать обязательно, а нормализовать нужно не в мультитрекере, а в эдиторе. Разные вещи, да? Тупо - значит ПРОЩЕ, а не о блондинках. В 32 флоат потому и переводить, что большинство плагов согласно спецификации SDK ASIO заточены под этот формат, и еще чтобы четко весь процесс переводов и дитеренгов самому отслеживать, а не отдавать на откуп плагам.
вот вам месть,классная очепатка: )))
Elle, спасибо вам что уделили внимание этому вопросу - вы говорите о загадке - что изначально? и на сколько приплюснсули? - по-моему это не принципеально, но не буду ничего утверждать, отвечу, что к примеру изначальный уровень пиков -0.2, "приплюснут" на -3, outceiling 0.
Также справедливости ради замечу, что последовательность как в "вариант а" и "вариант б" - дает одинаковый результат!, с той же разницей. Битность проекта 32float.
Я тоже первым делом - думал о роутинге.. вопщем пока ответ так и не нашел, хотя уверен что он конечно очевиден и на поверхности))
Я почему так к этому вопросу привязался, просто как уже говорил, раньше относился к этому как к вещам равноценным и даже читая вот эту тему
http://forum.rmmedia.ru/showthread.php?t=37333&highlight=gain , наряду со многими про себя посмеялся по поводу "мышки")) - сейчас уже эта тема так не веселит!
ну значит кубик при оффлайн процессинге игнорирует клип гейн вообще.FLO написал(а):
Т.е.роутинг следующий:
offline file processing -> clip gain -> insert fx -> track fader
что в общем-то вполне логично..
