Рендеринг аудио что это
Рендеринг (просчёт) треков
Окно Рендеринг выбранного позволяет вам настроить параметры рендеринга треков.
Доступны следующие параметры:
Как отдельные фрагменты
Будет создан один или несколько треков. Они будут содержать отдельные события или партии, которые будут сохранены как отдельные аудио файлы.
Будет создан один или несколько треков. Они будут содержать смежные события или партии, объединённые в блоки. Каждый блок будет сохранён как отдельный аудио файл.
Будет создан один или несколько треков. Они будут содержать события/партии, которые будут скомбинированы в одно событие/партию. Каждая комбинация будет сохранена как отдельный аудио файл.
Если активирован этот пункт, все эффекты и регулятор панорамы копируются в новые аудио треки. Полученные аудио треки останутся в формате исходных треков. Например, из моно трека получится моно трек.
Если активирован этот пункт, при рендеринге в новые аудио файлы используются все эффекты. Сюда входят эффекты в инсертах, параметры ячейки канала, группового канала и посылов канала на эффекты. Параметры регулятора панорамы также учитываются при создании новых аудио треков. Полученные аудио треки останутся в формате исходных треков. Например, результатом рендеринга моно трека будет моно трек.
Полный путь прохождения сигнала
Если активирован этот пункт, при рендеринге в новые аудио файлы учитывается полный путь прохождения сигнала, включая все параметры канала, группового канала, посылов канала на эффекты, а также параметры регулятора панорамы. На новом созданном аудио треке не будет загруженных плагинов эффектов. Параметры регулятора панорамы будут активированы. Формат полученных аудио файлов определяется конфигурацией выходного канала исходного трека. Результатом рендеринга моно трека, выход которого скоммутирован на стерео шину, будет стерео аудио файл.
Полный путь прохождения сигнала + Мастер FX
Если активирован этот пункт, при рендеринге в новые аудио файлы используются все эффекты и параметры мастер-шины. Сюда входят все параметры ячейки канала, параметры группового канала, посылов канала на эффекты, а также параметры регулятора панорамы. Формат полученных аудио файлов определяется конфигурацией выходного канала исходного трека. Результатом рендеринга моно трека, выход которого скоммутирован на стерео шину, будет стерео аудио файл.
Просчитать микс в один трек
Позволяет вам установить для просчитываемых файлов длительность затухания в секундах или тактах и долях. Это добавляет время к концу просчитанного файла, чтобы позволить хвосту реверберации и задержки полностью утихнуть.
Позволяет вам установить разрешение (битность) для получаемого в результате материала, равное одному из значений: 16 бит, 24 бит, 32 бит, 32 бита с плавающей точкой или 64 бита с плавающей точкой.
Позволяет вам ввести название для просчитанных файлов. Чтобы это сделать, разблокируйте эту опцию, нажав на изображение замка.
Оставить треки-источники без изменений
Если выбран этот пункт, исходные треки остаются нетронутыми.
Если выбран этот пункт, исходные треки автоматически мьютируются.
Если выбран этот пункт, исходные треки удаляются из списка треков.
Если выбран этот пункт, исходные треки после рендеринга скрываются. Чтобы треки заново отображались, выберите вкладку Показать в окне Проект и выберите трек, который необходимо отобразить.
Стоит ли разгонять ПК для работы в DAW
Содержание
Содержание
Эффективность разгона процессора почти никогда не проверяется в цифровых аудиоредакторах (digital audio workstation или DAW). Потому ли это, что оверклокинг не прибавляет существенной производительности в программах для работы с аудио? Или их незаслуженно обходят стороной? Есть только один способ узнать — проверить самостоятельно, чем мы и займемся в этом блоге.
Методы тестирования
Поскольку какой-то общепринятой методики тестирования разгона в DAW не существует, придется придумать ее самостоятельно. Производительность будет измеряться тремя способами:
1. Время рендеринга аудиофайла. Оно зависит от производительности компьютера. К счастью, в отличие от рендеринга видео и 3D-графики, рендеринг аудио не занимает часы — обычно несколько минут. С другой стороны, в DAW процессор не может ждать помощи от видеокарты в своем нелегком деле. К тому же, если проект объемный, а на всех плагинах выставлен максимальный оверсэмплинг, тогда рендеринг может занимать уже десятки минут, особенно на не самых производительных процессорах. Цель теста — смоделировать такую ситуацию и выяснить, сократит ли разгон время ожидания.
2. Количество VST-плагинов. Оно сильно зависит от трех вещей: буфера аудиокарты, частоты дискретизации и производительности процессора. Буфер в данном случае будет равен 128 сэмплам (это означает около 3 мс задержки между сигналом на входе и выходе аудиокарты, как если сидеть от динамика в одном метре). Такая задержка не ощущается при записи, на ней комфортно работать. Частота дискретизации будет равна студийному стандарту — 48 кГц. Смысл теста в том, чтобы проверить, сколько плагинов выдержит проект до появления хрипов и заиканий аудио из-за недостатка производительности процессора до и после разгона (как они звучат, можно услышать в видео ниже).
3. Скорость загрузки сэмплов в сэмплер NI Kontakt. Да, теоретически она будет ограничена скоростью жесткого диска, ведь скорость чтения SSD (все сэмплы будут размещены на Samsung 860 EVO) в десятки раз меньше скорости записи в оперативную память. Но все же интересно проверить на практике, будет ли какой-либо профит от поднятия частот подсистемы памяти. Для теста будет создан пресет весом 8 Гб — сэмплы различных инструментов.
Для объективности все тесты будут выполнены в трех самых «народных» DAW:
Тестовая конфигурация
В главной роли будет AMD FX 8350 — динозавр из 2012 года с дефолтной частотой 4 Ггц. Энтузиасты разгоняют его и до 5 Ггц, но установка рекордов не является целью этих тестов.
К тому же для таких частот нужна более серьезная материнская плата, а не Asus M5A97 с 4+2 фазами питания.
Впрочем, среднестатистический хоум-продюсер скорее потратит лишние деньги не на топовую материнку, а на звуковую карту или миди-клавиатуру, так что тестовую конфигурацию можно назвать достаточно релевантной. Задача в том, чтобы проверить, есть ли вообще смысл в оверклокинге ПК для нужд звукорежиссеров и музыкантов в домашних студиях, сколько выгоды это даст и перевесят ли плюсы.
Оверклокинг
Стоит отметить, что дефолтные настройки БИОСа позволяют процессору разгоняться на 5 % до 4.2 ГГц. Однако производительность AMD серии FX также сильно зависит от частоты подсистемы памяти.
К сожалению, материнская плата не позволила просто увеличить частоту самой оперативки на один шаг до 2133 Мгц даже при поднятии напряжения. Поэтому был выполнен разгон подсистемы памяти по шине на 5 % с дополнительным увеличением на 5 % множителя процессора. Также были отключены все функции энергосбережения и увеличено напряжение процессора в режиме смещения на 0.2 В. Так система загрузилась и работала стабильно. Итоговый разгон относительно дефолтных настроек составил 10 %.
Чтобы избежать троттлинга из-за высоких температур, тесты выполнялись в корпусе без крышки, а на северный мост и радиатор над мосфетами были направлены дополнительные вентиляторы. В итоге при загрузке плагинов и рендеринге в DAW процессор не грелся выше 65 градусов.
Разумеется, стоит лишний предупредить:
Выгода от разгона процессора
Cubase 11. Со временем рендеринга поначалу случились удивительные вещи — оно выросло почти в два раза — с 10 до 18,5 минут! Троттлинг исключен — температура процессора не превышала 65 градусов, северный мост и мосфеты не грелись выше 50 градусов. Кроме того, мониторинг в программе HWiNFO64 выявил, что все ядра стабильно работали на своей частоте. Проблема решилась включением виртуализации в БИОСе (SVN: Enabled). Трудно сказать, как это связано с производительностью в DAW, но после этого время рендеринга сократилось до 492 секунд.
Копирование дополнительной аудиодорожки с 5 плагинами все так же приводит к хрипам. Однако если удалить самый требовательный плагин (гитарный ампсим), тогда получается разместить в проект четыре дополнительных дорожки с четырьмя плагинами. Иными словами, разгон позволил добавить 16 не самых требовательных плагинов.
Reaper. Здесь время рендеринга тоже сократилось — с 312 до 290 секунд, то есть ровно на
10 %. Также удалось добавить четыре дорожки без ампсима (16 плагинов) до появления заиканий.
FL Studio. Профит от разгона при рендеринге трека составил около 40 секунд. Однако по части плагинов все осталось практически без изменений. В загруженном проекте аудио воспроизводится гладко, но добавление даже четырех лишних плагинов создает хрип и заикания. Удалось добавить всего две штуки.
Стоит отметить, что рендеринг в DAW загружает процессор не полностью, а где-то на 50–70 %. Поэтому температура не превышала 65 градусов, хотя при рендеринге видео в Adobe Premiere доходила до 75 градусов (выше этого значения этот процессор начинает троттлить, что лишний раз заставляет задуматься об охлаждении).
Выгода от разгона памяти
Осталось лишь посмотреть, какие результаты даст оверклокинг памяти при разгрузке сэмплов весом 8 Гб в «ВКонтакте».
Cubase. Пачка сэмплов загрузилась за 167 секунд — на 21 секунду меньше, чем на исходных настройках, время ожидания сократилось на 12,5 %.
Reaper. А здесь, наоборот, сэмплы грузились на пять секунд дольше.
FL Studio. Тут сэмплы грузились на две секунды меньше.
Выходит, разгон памяти дал свои плоды только в одном DAW. Может быть, стоит поковыряться в таймингах? Есть мнение, что более низкие основные тайминги позволяют получить больше выгоды от оверклокинга памяти. Конфигурация 10-11-10-30 позволила без проблем загрузить компьютер. В результате в каждом DAW сэмплы стали грузиться на две секунды быстрее. Довольно скромный результат, который вряд ли будет ощутим при работе
с программой.
Сравнение с рендером видео и графики
Посчитав в процентах каждую разницу в показателях до и после разгона, можно вывести средний процент и взять его за основу для сравнения с другими программами и бенчмарками. В среднем, прирост в Cubase составил почти 20 %, в Reaper — 11 %, в FL Studio — 7 %.
Cubase позволяет получить больше профита от прироста производительности системы. Этот DAW выдерживает больше всего плагинов, но вместе с тем хуже остальных справляется
с рендерингом.
Рендеринг видеофайла в разрешении 1920х1080 в Adobe Premiere на одном только процессоре после разгона занял почти на минуту меньше времени, чем до него. Синтетические тесты, а также рендеринг 3D-графики в Cinebench R15 и в бенчмарке Blender показали прирост производительности в районе 7–12 %. Это сопоставимо с приростом в DAW.
Итоги
Судя по всему получаемая выгода от оверклокинга сильно зависит от DAW. Небольшой разгон процессора и памяти позволяет загрузить в проект больше VST-плагинов и сократит время ожидания при рендеринге, а иногда и при загрузке сэмплов, хотя последнее вряд ли будет ощущаться. Если есть подходящая для оверклокинга материнская плата и водяное охлаждение, то можно добиться и более серьезных результатов без потери стабильности системы. Поэтому при работе с громоздкими проектами на пределе возможностей системы разгон может спасти, особенно, если проекту не хватает буквально пары десятков плагинов или нескольких VST-инструментов.
Однако радикального прироста производительности ждать не стоит. Для сравнения, оверклокинг того же FX 8350 даже до 8 Ггц все равно не позволил сравниться ему даже с Ryzen 5 2600X на штатных частотах. Производительность процессоров и скорость оперативной памяти существенно выросли за последние пять лет, поэтому апгрейд старого железа на новое позволит получить намного больше выгоды.
Как не надо разрабатывать звуковые движки
Программируя звук в приложениях и в играх, мне часто приходилось переписывать всю кодовую базу звуковых модулей, так как многие из них обладали либо слишком запутанной архитектурой, либо наоборот ничего не умели кроме простого проигрывания звуков.
Со звуковыми движками хорошо подходит аналогия с рендером изображения в играх: Если у тебя слишком простой pipeline с большим кол-вом абстракций, то ты вряд ли сможешь адекватно программировать что-то сложнее чем куб с шестеренками. С другой стороны, если у тебя весь код состоит из прямых OpenGL или D3D вызовов, то ты не сможешь без боли масштабировать свой спагетти-код.
Насколько уместно сравнение с графическим рендером?
В рендере звука происходят те же процессы, что и в рендере графики: Обновления ресурсов из игровой логики, обработка данных в удобоваримый вид, пост-обработка, вывод конечного результата. Все это может занимать довольно большой промежуток времени, поэтому для показательности я использую свою аудио библиотеку для теста производительности рендера.
Помимо чтения файла из SSD диска, декодирования Opus файла и записывания его даты в микшерный буфер, библиотека создает имитацию объемного звука, обрабатывает сигнал с помощью DSP модулей (компрессор, эквалайзер), а также ресемплирует сигнал. Конфиг машины, на которой проводился тест: Inte Core i9 9900 4.5GHz, 32GB RAM, SSD 480GB SATA. Ресемплинг принимал на вход сигнал с частотой дискретизации 48000Гц и выдавал с 44100Гц.
Если добавить уже несколько элементов, то время рендера будет сопоставимо с графическими рендером движком, с единственным отличием в том, что это все происходит в одном потоке. Если же это все попробовать распараллелить на систему задач, сделать более оптимальные алгоритмы микширования, то время рендера с большим количеством уникальных звуков может уменьшиться в несколько раз.
Каким стоит делать звуковой рендер для игр?
Чтобы ответить на этот вопрос, нужно уточнить ваши первоначальные данные. Если вы — инди-разработчик, и вы не обладая знаниями в звуке решили разрабатывать игру на C++, то вам подойдут простые библиотеки вроде SoLoud или OpenAL. Они сочетают в себе удобство более продвинутых систем и относительно неплохим функционалом, но при этом обладают важнейшим недостатком — плохая переносимость. Так как у всех этих библиотек API элементарный и монолитный, то сложно представить себе портирование с OpenAL на тот же Wwise.
Как выглядит сейчас этот звуковой движок
По этой причине, Core часть звукового движка проблематично портировать как на высокоуровневые фреймворки (FMOD либо Wwise), так и на низкоуровневые прослойки над системным API (PortAudio).
А как бы он мог выглядеть, если из него вырезать ненужные компоненты
Основные архитектуры звуковых движков
Как говорилось ранее, движок должен состоять из двух частей — низкоуровневой (hardware) и высокоуровневой (mixer). Низкоуровневая часть отвечает либо за вывод звука напрямую в динамик, либо за вывод звука через дополнительную прослойку, облегчающую работу с системным API. Высокоуровневая часть отвечает за микширование и управление звуками.
Такая архитектура позволяет очень легко поменять реализацию одних из модулей на что-то более продвинутое с точки зрения технологий. Тот же AudioHardware я могу написать как через прослойку PortAudio, так и напрямую через Windows Audio Session API. Также и с SoundManager — он может быть переписан с использованием библиотек FMOD или Wwise. В этом случае работу модуля AudioHardware принимает на себя именно фреймворк, и вам даже не придется думать о реализации вывода звука.
Высокоуровневая часть звукового движка может быть реализована с помощью разных архитектур: routing и emitters-source систем. Первая в основном используется в DAW, и представляет из себя звуковые дорожки, которые связаны между собой с помощью систем маршрутизаций. Это позволяет посылать сигнал из одного канала в другой, делать side-chain из одного канала в другой, а также использовать сразу несколько звуков на одной дорожке. Данный функционал подходит для рабочего софта, но никак не подходит для игровых движков из-за сложности в реализации а также высоких требований к железу.
Как выглядит современная звуковая система
Пример реализации emitters-source системы можно посмотреть на этом репозитории. Здесь я воспользовался библиотекой miniaudio, поэтому проблем с реализацией вывода звука у меня не было.
Рендеринг и предпросмотр эпизодов
В этой справочной статье описаны особенности рендеринга, предпросмотра и воспроизведения эпизодов в Premiere Pro.
Premiere Pro пытается воспроизвести все эпизоды в режиме реального времени с полной частотой кадров. В Premiere Pro такой подход, как правило, применяется для всех разделов, которым не требуется рендеринг или для которых Premiere Pro уже выполнил рендеринг файлов предпросмотра. Тем не менее, в режиме реального времени воспроизведение составных разделов с полной частотой кадров не всегда возможно без файлов предпросмотра: разделы, для которых не выполнен рендеринг.
Для воспроизведения составных разделов в режиме реального времени с полной частотой кадров может потребоваться предварительный рендеринг файлов предпросмотра для этих разделов. Premiere Pro помечает разделы в эпизоде, для которых не выполнен рендеринг, цветной полосой рендеринга. Полоса рендеринга красного цвета на линейке времени эпизода указывает на раздел, для которого рендеринг не выполнен, но выполнить его желательно для воспроизведения в режиме реального времени и с полной частотой кадров. Полоса рендеринга желтого цвета указывает на раздел, для которого рендеринг не выполнен и которому он не требуется для воспроизведения в режиме реального времени и с полной частотой кадров. Независимо от качества предпросмотра, для разделов, помеченных полосой рендеринга красного или желтого цвета, необходимо выполнить рендеринг перед экспортом на пленку. Полоса рендеринга зеленого цвета указывает на раздел, для которого уже выполнен рендеринг файлов предпросмотра, связанных с ним.
Эпизоды ссылаются на файлы предпросмотра примерно так же, как и на исходные медиаданные. При перемещении или удалении файлов предпросмотра из обозревателя файлов Windows или Mac, а не с панели «Проект», при следующем открытии проекта вам будет предложено выполнить поиск или пропустить файлы предпросмотра.
Чтобы разрешить предпросмотр 10-битного или 8-битного материала без сжатия, можно настроить шаблон настроек эпизода. Дополнительные сведения см. в разделе Создание эпизода с воспроизведением видео без сжатия.
В этом сборнике часто задаваемых вопросов на форумах Adobe описано, что может означать в эпизоде красная или желтая полоса.
FL Studio Сохраняемые и экспортируемые форматы файлов
Данная статья является частью цикла статей «Fl Studio»
Содержание
Диалоговое окно экспорта проекта (*.wav; *.mp3, *.ogg, *.flac, *.mid) [ править ]
Чаще всего вы будете экспортировать свой проект в *.wav или *.mp3 звуковые файлы, которые будут проигрываться в медиа-плеере, стерео или Hi-Fi системах. Финальный микс экспортируется из FL Studio с помощью опции Export из меню File, процесс проходит не в режиме реального времени, и называется рендерингом. Время будет зависеть от настроек экспорта и сложности проекта. Рендерируемый звук лучшего качества, чем живой звук из FL Studio.
Запись внешнего оборудования
Чтобы включить звук от внешнего оборудования, такого как синтезатор, драм машина или сэмплер в финальный рендеринг:
Project type (тип проекта) [ править ]
Output format (выходящий формат) [ править ]
Выберите выходящий формат(ы) для рендеринга проекта. Чтобы сохранить более чем в одном формате, просто выберите в этой панели несколько вариантов.
Quality (качество) [ править ]
Miscellaneous (разное) [ править ]
Кнопки рендеринга [ править ]
Параметры экспорта командной строки [ править ]
См. здесь несколько способов запуска командной строки в Windows. Это позволяет вам пакетно обрабатывать проектные и MIDI-файлы.
Файл проекта FL Studio (*.flp) [ править ]
Это родной формат проектов FL Studio. Он сохраняет все данные, относящиеся к проекту, но учтите он не включает в себя сэмплы (если в проекте нет звуков загруженных в редактор Edison), пресеты DrumSynth и SimSynth, которые включены в проект. Чтобы экспортировать пакет, который включает в себя сэмплы, используемые в проекте, вместо этого сохраните в Zip.
Архивный файл проекта (*.zip) [ править ]
Проекты могут быть сохранены в стандартные ZIP файлы. Этот формат будет сохранять файл проекта FL Studio и все сэмплы/пресеты используемые в проекте. FL Studio также может открывать непосредственно ZIP файлы (см. «Архивный файл проекта» в форматах файлов открытия/импорта).