Оптимизация треков: почему подготовить файл — умнее, чем транскодировать на лету

Представьте: в эфире играет спокойная джазовая композиция, а следом — энергичный рок-трек. У слушателя в наушниках сначала тишина, потом — бабах! Разница в громкости бьет по ушам. Это классическая проблема любого радио, которое крутит файлы из разных источников.

Многие решают её на лету — прямо в потоке, когда трек уже играет. Но есть нюанс: выравнивание громкости и транскодинг в реальном времени жрут процессор и память. Особенно если у вас несколько потоков, несколько битрейтов и сотни слушателей.

Мы пошли другим путем. В админке нашего решения есть функция оптимизации треков. Вы запускаете её один раз — и все файлы в библиотеке приводятся к единому стандарту. Громкость выравнивается, битрейт оптимизируется под настройки вашего эфира. И всё это — до того, как трек попадет в ротацию. Эфир становится стабильным, а нагрузка на сервер — минимальной.

Почему выравнивание на лету — это плохо

В классическом стеке Icecast + Liquidsoap часто используют встроенные фильтры для нормализации громкости. Liquidsoap умеет применять normalize или amplify прямо к потоку. Выглядит это примерно так:

s = playlist("/music")
s = normalize(s, target=0.1)
output.icecast(%mp3, s)

Кажется удобно. Но что происходит под капотом?

1. Каждый трек обрабатывается в момент воспроизведения: Liquidsoap загружает файл, декодирует его, анализирует громкость, применяет усиление, кодирует обратно. Это всё — в реальном времени, пока слушатели уже подключены.
2. Нагрузка на CPU растет с каждым слушателем: Если у вас один источник, обрабатывающий поток, нагрузка ложится на него. Но если у вас 5 маунтов, каждый со своим Liquidsoap, и каждый крутит треки с нормализацией на лету — процессор начинает задыхаться. Особенно если файлы в FLAC или высоком битрейте.
3. Транскодинг на лету усугубляет ситуацию: Если вы еще и транскодируете на лету (например, из FLAC в MP3 320 kbps), каждый трек обрабатывается дважды: сначала декодирование + нормализация, потом кодирование в целевой битрейт. Это двойная нагрузка.
4. Проблемы с буферизацией: Если сервер не справляется, начинаются задержки. Треки могут «заикаться», поток прерываться. Слушатели думают, что у них плохой интернет, а проблема — на вашей стороне.

Наш подход: оптимизация до эфира

Мы решили перенести всю «тяжелую» работу на этап подготовки библиотеки. В админке есть функция оптимизации треков, которая делает всё один раз — когда файл попадает в систему или когда вы меняете настройки битрейта.

Что делает оптимизация

1. Выравнивание громкости (ReplayGain): Система анализирует каждый трек, измеряет его реальную громкость (не по пикам, а по восприятию) и добавляет метаданные с коэффициентом усиления. В эфире трек будет звучать ровно на том же уровне, что и остальные.
2. Предварительный транскодинг: Если вы вещаете в MP3 192 kbps, а исходный файл — FLAC или WAV, система может заранее сконвертировать его в целевой формат. В эфире файл просто читается и отдается, без декодирования и перекодирования.
3. Оптимизация под битрейт: Для каждого маунта (с его настройками битрейта) можно создать оптимизированную копию. Тогда во время эфира приложение просто отдает готовый файл, не тратя CPU на транскодинг.

Что дает оптимизация

1. Экономия CPU и памяти

Это главное. Когда трек уже оптимизирован, в эфире приложение просто читает готовый файл и отдает его в поток. Никакого декодирования, анализа, перекодирования. Обычный чтение с диска + отправка по сети. Нагрузка на процессор минимальна, даже если у вас десятки слушателей и несколько маунтов.

2. Стабильный эфир

Выравненная громкость — это комфорт для слушателя. Никто не дергается к регулятору громкости, когда меняется трек. Это профессионально. А для радио — это репутация.

3. Меньше прерываний

Без транскодинга на лету нет риска, что процессор не справится и поток «заикнется». Эфир становится предсказуемым и надежным.

4. Экономия на железе

Вы можете запускать радио на более скромном сервере. Если не нужно гонять транскодинг 24/7, хватит и VPS с 1-2 ядрами. Тяжелая работа (оптимизация) происходит разово, в фоне, и не влияет на качество эфира.

5. Мгновенное переключение маунтов

Если у вас несколько битрейтов, и вы оптимизировали библиотеку под каждый из них, переключение между маунтами происходит моментально. Приложение не ждет, пока транскодируется первый трек нового плейлиста — он уже готов.

Как это выглядит в админке

В интерфейсе администратора есть отдельный раздел «Оптимизация треков». Он показывает:

• Список треков с указанием статуса: «не оптимизирован», «оптимизирован».
• Прогресс-бар для батч-операций.
• Вы можете запустить оптимизацию для всего раздела «rock» одним кликом.

Реальный сценарий

Вы только что установили радио, залили 500 треков в папку /data/rock/tracks. Все файлы — в FLAC, качество отличное. Настройки эфира — MP3 320 kbps.

Что вы делаете: заходите в админку, выбираете «Оптимизировать всё для маунта /rock», нажимаете «Старт». Система уходит в фон, обрабатывает файлы.

Через час: все 500 треков оптимизированы. Громкость выровнена. Вы запускаете эфир.

Результат: сервер читает готовые MP3-файлы с диска и отдает слушателям. CPU простаивает на 95%. Треки звучат на одном уровне. Слушатели довольны.

Итог: готовь сани летом, а треки — до эфира

Оптимизация треков — это философия «prepare once, play many». Вместо того чтобы нагружать сервер каждый раз, когда трек играет, вы делаете всю работу один раз. Потом эфир работает легко и стабильно.

• Выравнивание громкости — до эфира, не на лету.
• Транскодинг — до эфира, не при каждом воспроизведении.
• Батч-режим — обработал всю библиотеку и забыл.
• Индивидуальная оптимизация — для новых треков или проблемных файлов.

В результате сервер тратит ресурсы только на одно: стабильную раздачу потока. А вы тратите время только на одно: подбор музыки, а не на борьбу с просадками CPU и скачками громкости.

Подготовленные треки = стабильный эфир. А стабильный эфир = счастливые слушатели.