Reaper рипперу: Как максимально сохранить 32int при использовании декликера

Здравствуйте, дорогие мальчики и девочки!
На заметку тем, у кого АЦП выдает 32 integer. Мне лень делать скриншоты — кто в теме, идею поймет.
Если ваш АЦП дает 32int, то записывая в 32fp-проект, вы, строго говоря, сами себя немного обкрадываете. 32int — постоянные тридцать два, а 32fp — двадцать четыре плюс мерцающий хвост. В этой заметке я не буду останавливаться на преимуществах одного перед другим, исходя из предпосылки, что если такая техническая возможность по факту уже есть и лежит перед вами в виде готового к работе железа, то, черт побери, почему бы ее не использовать — вне зависимости от того, насколько существенна эта математическая разница в вашей задаче.
Нельзя большее положить в меньшее, поэтому чтобы схватить все 32int, нужно записывать в 64fp-проект — например, в Reaper. Да, файл получится в два раза больше, наполовину заполненный нулями, но продизерив в 32 fixed point оффлайн, например и не ограничиваясь, Сараконом или на лету, например, HQPlayer'ом (который, кстати, работает не только с 64fp, но и с 64fp в RF64, если ваш wav-файл получился больше 4 Гб — опция не менее приятная кэш-бэка по карте Тинькофф, круто, да?), вы получаете размер тридцати двух — как если бы вы писали в 32fp — но с бенефитом интеджер.
Итак, вы перфекционист, который рипает винил с глубиной 64fp, чтобы не потерять 32int, которые дает железяка. Теперь надо бережно почистить рип от щелчков и т.п. мелкой грязьки. Проблема в том, что нет декликеров, работающих с 32int. Например, невозможно избежать того чтобы изотоповский декликер не сделал флоут из интеджер — даже несмотря на то, что Изотоп, естественно, умеет работать с интеджер. Просто такова техническая реализация конкретно декликера, и с этим ничего не поделать. Эта заметка написана для того, чтобы на примере двух разных последовательностей действий с изотоповским декликером показать, как лечить рип с минимальным ущербом для 32 интеджер.
Перед нами Reaper и 64fp-рип в первом треке. На FX трека сажаем VST изотоповского декликера и выключаем его, чтобы он не повлиял на поиск проблемного места в режиме реального времени. Обнаружили щелчок, ставим на него курсор, предварительно отключив snapping (есть кнопка на консоли трека, либо Alt+S). Ищем ближайший zero crossing (для краткости, ноль) до щелчка Shift+Z и режем по этому нулю S. Возвращем курсор на щелчок (или конец проблемной области), ищем ближайший ноль после щелчка и режем по нему: Z, S. Либо есть сочетание клавиш для резки по нулю сразу — поройтесь в Action List по ключевым словам. Для более удобного поиска дефектов можно включить режим вейвформа+спектрограмма: View/Peaks display settings.
Получили в треке три items: до проблемной области, проблемная область, после проблемной области. Курсор на проблемную область и рендерим ее с включенным декликером Ctrl+Alt+R в отдельный трек. Параметры рендеринга: Source=Selected media items; отключить нулевой хвост тишины; выбрать рабочую папку для сохранения патча; формат, ЧД и глубина — родные от вашего проекта и обязательно поставить галку Add rendered items to new tracks in project. Патч прорендерился в новый, второй, трек и аккурат под проблемную область — т. е. на то же место на шкале времени — круто, да! Включаем режим Solo у второго трека с патчем и слушаем — убеждаемся, что ремонт нас устраивает. Далее курсор на проблемную область в первом, основном, треке и удаляем ее. Либо можно перетащить патч из трека в трек, предварительно поставив опцию замещения айтемов при наложении в генеральных настройках проекта. В простейшем случае, с ремонтом одной области, мы получили нетронутые начало и конец в первом треке и патч во втором. Если областей ремонта много, то каждый новый патч будет рендериться в отдельный трек. Далее рендерим весь мастер — по принципу единства шкалы времени в секвенсоре все патчи, условно, встроятся на свои места в первый, нетронутый, трек. Не проверял, но есть предположение, что резать проблемную область не обязательно именно по нулям — у Reaper 64-битный внутренний процессинг — думаю, он сможет гладко склеить вейвформу и не на нуле. И если это так, то процедура еще упрощается: не режем, а выделяем область мышью и рендерим не айтем, а time selection.
В чем крутота этого метода в контексте сохранения 32int? В том, что декликеру позволили сделать флоут только из патчей, коих, из самой жесткой моей практики, до полупроцента от рипа, а нетронутые области прорендерятся из проекта с оригинальной глубиной: девственные 32int в оболочке 64fp. Проверяется это бит-мониторингом — например, в MusicScope. Технология проста. Рендерим тестовый трек ABC, в котором склеенные области A и С — нетронутые, B — патч. Запоминаем, с каких отсечек времени начинаются B и C. На битограмме A будет весь интеджер. При переходе в B обновим битограмму — флоут, обновим при переходе в C — снова интеджер. Шикардос. То есть, вывод, рендеринг из Reaper позволяет компилировать куски с разной глубиной: глубина рендеринга не влияет и не уравнивает реальную глубину отдельных айтемов.
Второй же, более ущербный, метод с изотоповским декликером — в составе RX. Вот у нас есть 32int в оболочке 64fp, хотим отремонтировать в RX — операционно это, конечно, намного удобнее первого метода с VST. Изотопчик не работает с глубиной 64, поэтому дизерим исходник до 32int. В главном окне RX вы увидете 32-bit — без floating point. Первое же использование декликера добавит floating point. Сделали ремонт. Экспортируем из RX в 32int и надеемся, что такой же трюк с дифференцированной глубиной прокатит и в этот раз — что только области выделения под декликер станут флоут. Увы, нет. На битограмме весь трек, от начала до конца, по факту будет флоут, несмотря на выгрузку в 32int. Т.е. декликер какбе заражает флоутом весь проект, в то время как, как я сказал выше, ремонту подвергается (сумма чистого времени патчей) до полупроцента рипа, а 99,5 обедняются с интеджер до флоут просто так, бессмысленно.

Важная поправка по техпроцессу.
На краях айтемов декликер ведет себя непредсказуемо, поэтому лучше сделать так:
Обособляем проблемную область маркерами, расставленными по нулям. При включенном snapping выделяем шкалу времени между маркерами. Рендерим мастер по time selection в новый трек, автоматически добавляемый в проект. Перетаскиваем патч из трека в трек с включенной опцией замещения при наложении в генеральных настройках проекта - со снеппингом промахнуться невозможно. Вспомогательный трек, образовавшийся при рендеринге, из проекта можно удалить.
На горячих клавишах делается влет.

UPD. x2 click между маркерами на шкале времени. Num8 или настраиваем удобную гор. клавишу в Action list.