Истинный пик, dBTP и проблема межотсчётного пика

Опубликовано: 2026-06-06 · Время чтения: 17 мин · Автор: Николай Сапунов, CEO Фора Софт

Коротко

Peak-метр в вашем редакторе измеряет самый громкий цифровой отсчёт, но реальная волна, доходящая до ушей слушателя, поднимается между этими отсчётами, и этот скрытый максимум-в-промежутке – и есть истинный пик, измеряемый в dBTP. Файл, который читается безопасными −0,1 dBFS на сэмпловом метре, может достичь +0,7 dBTP после того, как устройство воспроизведения восстановит волну, и клиппировать телефон, ЦАП ноутбука или пару AirPods, которых студийные мониторы так и не показали. Кодеки с потерями вроде AAC и Opus делают хуже: они добавляют собственные выбросы, поэтому истинный пик у слушателя может превысить уровень, измеренный до кодирования, на децибел и больше. Решение – true-peak-метр, который передискретизирует сигнал так, как описывает стандарт ITU-R BS.1770-5, плюс потолок доставки −1 dBTP (и ниже для низкобитрейтных потоков), чтобы у восстановления был запас.

Почему это важно

Если вы отгружаете звук для стримингового сервиса, конференц-продукта или любой видеоплатформы, это та статья, что объясняет, почему «в студии звучало нормально» и «на телефоне пользователя клиппирует» – правда одновременно. Продакт-менеджер, утверждающий мастер на 0 dBFS, операционный лид, задающий потолок кодера, и инженер, выбирающий лимитер, – все трогают одну скрытую переменную, и ошибка здесь рождает искажение, которое проявляется только на самом дешёвом и самом распространённом оборудовании ваших пользователей. Эта статья точно определяет истинный пик, показывает арифметику на реальных числах и даёт потолки доставки, которых вещательные и стриминговые стандарты действительно требуют в 2026 году.

Ложь, которую говорит ваш peak-метр

Откройте любой аудиоредактор – и увидите peak-метр. Он загорается, показывая самый громкий момент файла, а у цифрового звука есть жёсткая стена под названием full scale, записываемая как 0 dBFS, которую сигнал пересекать не должен. Пересечёте – отсчёты насыщаются, рождая резкий треск, который все узнают как цифровой клиппинг. Так что правило кажется простым: держите метр ниже 0 dBFS – и вы в безопасности.

Правило неверно, и причина – важнейшая идея этой статьи. Числа в аудиофайле – это не звук. Это измерения звука, взятые в фиксированные мгновения – 48 000 раз в секунду для типичного звука к видео. Сам звук – гладкая непрерывная волна, и файл лишь записывает, где эта волна сидела на каждом тике дискретизирующих часов. (Если идея превращения волны в числа для вас нова, начните с что такое цифровой звук и спутника о том, почему 48 кГц победила в видео.)

Метр на экране, называемый сэмпловым peak-метром, сообщает наибольшее из этих сохранённых чисел. Но устройство воспроизведения не играет числа. Оно восстанавливает гладкую волну, прошедшую через них, фильтром реконструкции, встроенным в каждый цифро-аналоговый преобразователь. И вот ловушка: восстановленная волна может подняться выше между двумя отсчётами, чем любой из них. Пик, который вам важен, – тот, что реально покидает динамик, – живёт в промежутках, которые метр так и не измерил.

Международный стандарт говорит об этом прямо. ITU-R BS.1770-5 отмечает, что «значение истинного пика может возникать между отсчётами» и что существующие сэмпловые метры «не отражают уровень истинного пика, содержащийся в цифровом сигнале». Истинный пик определён как «максимальное (положительное или отрицательное) значение волны сигнала в непрерывной временной области», и стандарт явно указывает, что «это значение может быть выше наибольшего значения отсчёта в дискретизированной по времени области».

Нажмите, чтобы увеличить

Межотсчётные пики, одной картинкой

У пиков, прячущихся между отсчётами, есть имя: межотсчётные пики. Это не баг и не ошибка округления. Это неизбежное следствие того, как работает дискретизация, и немного арифметики показывает ровно, насколько большими они могут стать.

Представьте чистый тон, чья частота лежит высоко в слышимом диапазоне, близко к четверти частоты дискретизации. Дискретизирующие часы ловят эту волну в двух точках, что случайно сидят по обе стороны её гребня – одна чуть до пика, другая чуть после, и ни одна не попадает на сам пик. Оба сохранённых отсчёта ниже full scale. Истинный гребень, сидящий в промежутке, – выше.

Насколько выше? Собственный анализ наихудшего случая из стандарта даёт формулу того, насколько сэмпловый метр недооценивает тон:

недооценка (dB) = 20 · log10( cos( π · f_norm / n ) )

Здесь f_norm – частота тона как доля частоты дискретизации, а n – коэффициент передискретизации метра. Стандарт приводит остаточную ошибку в таблице: метр с 4-кратной передискретизацией всё ещё недооценивает до 0,688 dB для тона около половины частоты дискретизации, а метр без передискретизации – хуже. На практике реальный материал с горячими высокими частотами рутинно прячет 0,5–1,5 dB истинного пика над сэмпловым пиком, а патологические тестовые тоны прячут куда больше. Стандарт отмечает, что для тона ровно на половине частоты дискретизации недооценка «может быть почти бесконечной», хотя реальные сигналы редко концентрируют энергию там.

Единица для этого реального максимума-между-отсчётами – dBTP, децибелы относительно full scale, true-peak. Показание 0 dBTP означает, что восстановленная волна едва касается full scale. Показание +0,7 dBTP означает, что она выходит за край на 0,7 dB, и у преобразователя слушателя нет места над full scale, чтобы её отрисовать – значит, клиппинг.

Как true-peak-метр на самом деле его измеряет

Нельзя измерить пик, сидящий между вашими отсчётами, не заполнив сначала промежуток. Именно это и делает true-peak-метр, и метод точно прописан в Приложении 2 к ITU-R BS.1770-5, чтобы каждый совместимый метр давал одно и то же.

Метр восстанавливает версию сигнала более высокого разрешения – ту же операцию выполняет ЦАП воспроизведения – а затем читает сэмпловый пик уже её. Стандарт перечисляет четыре стадии обработки:

1. Аттенюация на 12,04 dB. Это сдвиг на 2 бита, дающий запас для последующей математики, чтобы выброс выше full scale сам не переполнил арифметику метра. В конце он отменяется. (В реализациях с плавающей точкой этот шаг не нужен.)
2. Передискретизация 4×. Частота дискретизации сигнала поднимается с 48 кГц до 192 кГц вставкой интерполированных точек между исходными. Стандарт задаёт конкретный 48-отводный 4-фазный FIR-фильтр интерполяции для этой задачи. Сигнал на этой высокой частоте «точнее указывает реальную волну, представленную аудиоотсчётами».
3. Фильтр нижних частот, чтобы интерполяция оставалась честной, исключая частоты, которых там быть не должно.
4. Взять абсолютное значение, затем перевести в dBTP, вычислив 20·log10 результата и добавив обратно 12,04 dB, снятые на первом шаге.

Коэффициент 4× (48 кГц → 192 кГц) – минимум стандарта; он явно говорит, что «более высокие частоты дискретизации и коэффициенты передискретизации предпочтительны». Сигналу уже на 96 кГц нужна лишь 2-кратная передискретизация до 192 кГц. Причина, по которой 192 кГц – цель, в том, что этого достаточно, чтобы сделать остаточную недооценку пренебрежимой для нормального материала – таблица наихудшего случая показывает, что 4× сводит ошибку существенно ниже децибела, а этого хватает для метра, чьё значение управляет числом, а не громкоговорителем.

Практический вывод для всякого, кто читает метр: если ваш метр говорит «TP» или «dBTP» и совместим с BS.1770, он делает эту передискретизацию внутри. Если он говорит лишь «Peak» или «dBFS», это сэмпловый метр, и он лжёт вам на децибел и более.

Нажмите, чтобы увеличить

Почему кодеки с потерями делают хуже

Всё сказанное предполагает, что файл доходит до слушателя неизменным. Так почти не бывает. Стриминговые сервисы и конференц-системы перекодируют ваш звук кодеком с потерями – AAC, Opus или подобным – и этот шаг кодирования добавляет собственный выброс истинного пика.

Причина встроена в принцип работы этих кодеков. Кодек с потерями не хранит ваши отсчёты; он хранит частотную аппроксимацию звука и восстанавливает новые отсчёты при декодировании. (Механика разобрана в как работает сжатие звука.) Эти восстановленные отсчёты близки к исходным, но не идентичны, и малые различия могут подтолкнуть истинный пик декодированной волны выше, чем сидел исходный. Стриминговая рекомендация AES, технический документ AES TD1008, прямо говорит о следствии: «выброс пика растёт по мере снижения битрейта». Файл AAC 320 кбит/с выбрасывает меньше, чем 64 кбит/с. Ниже битрейт – больше выброс.

Поэтому тот же документ рекомендует измерять и лимитировать истинный пик на входе кодека: «Для всего контента рекомендуется, чтобы максимальный уровень истинного пика не превышал −1 dBTP на входе кодека потоков с потерями». −1 dBTP не произволен. Это один децибел запаса, зарезервированный, чтобы собственный выброс кодера, добавленный сверху, всё ещё лёг ниже full scale у преобразователя слушателя. Для низкобитрейтных потоков тот же документ предупреждает, что порог «может потребоваться снизить ниже рекомендованного −1».

Выбросы складываются. AES TD1008 отмечает, что выбросы кодека и любого нисходящего пересчёта частоты «могут быть аддитивны», и что на стороне декодирования отсутствие запаса «может дать до 3 dB снижения усиления в декодирующем пиковом лимитере» в некоторых операционных системах – то есть слушатель слышит ваш громкий момент приглушённым на 3 dB, а не просто клиппнутым. Мастер, игнорирующий истинный пик, не только искажается; его могут тихо прикрутить так, как вы никогда не разрешали.

Разобранный пример: мастер, который клиппирует на AirPods

Подставим числа, потому что числа – это и есть весь аргумент.

Вы свели трек, и сэмпловый peak-метр редактора читает −0,1 dBFS. Выглядит безопасно – вы оставили десятую децибела запаса. Но в мастере яркий, горячий высокочастотный материал (тарелки, сибилянты, синтезаторный лид), и true-peak-метр на том же файле читает +0,6 dBTP. Межотсчётные пики сидят на 0,7 dB выше вашего сэмплового пика. На студийных мониторах, питаемых качественным интерфейсом с щедрым запасом, ничего слышимо не ломается, и вы отгружаете.

Теперь проследим файл до слушателя:

Сэмпловый пик мастера:     −0,1 dBFS   (что показал ваш метр)
Истинный пик мастера:      +0,6 dBTP   (уже за full scale)
+ выброс AAC 128 кбит/с:   +0,4 dB     (кодер добавляет свой)
= истинный пик у декодера: +1,0 dBTP   (на 1 dB за стеной)

У ЦАП телефона, преобразователя ноутбука и крошечного усилителя AirPods нет запаса над 0 dBFS. Они клиппируют сигнал +1,0 dBTP на каждом ярком транзиенте. Слушатель слышит треск ровно на дешёвом, повсеместном оборудовании, которым пользуется большая часть вашей аудитории, тогда как ваша студийная цепь – единственное, у чего был запас, – прятала проблему от вас всё это время.

Запустим исправление, и арифметика сходится. Поставьте true-peak-лимитер на −1 dBTP перед кодированием:

Истинный пик мастера после лимитера:  −1,0 dBTP
+ выброс AAC 128 кбит/с:               +0,4 dB
= истинный пик у декодера:             −0,6 dBTP   (безопасно под стеной)

Один зарезервированный децибел запаса поглощает выброс кодера, и сигнал ложится ниже full scale везде. Слышимая громкость не изменилась заметно – нормализация громкости платформы всё равно задаёт уровень воспроизведения – но искажение ушло.

Потолки доставки, которые вам реально нужны в 2026

Истинный пик – одно из двух чисел, которые несёт каждая спецификация доставки; второе – цель по интегральной громкости в LUFS, разобранная в статье о целях по платформам. Вот потолки истинного пика, которых требуют стандарты и крупные платформы. Значения – максимальный истинный пик; ниже – безопаснее.

Закономерность: −1 dBTP – потолок по умолчанию почти везде, а адресаты, требующие −2 dBTP, делают это именно потому, что ждут тяжёлого кодирования с потерями ниже по потоку и хотят больше запаса под выброс. В сомнении −1 dBTP безопасен для высокобитрейтной доставки, а −2 dBTP безопасен для всего; вы не теряете ничего слышимого, будучи консервативным, потому что нормализация управляет громкостью, которую слышит слушатель, а не потолком пика. Полный набор стандартов за этими числами – EBU R128, ITU-R BS.1770, ATSC A/85 – разобран в статье о нормализации громкости.

Частая ошибка: лимитировать сэмпловый пик вместо истинного

Самый частый провал – использовать обычный пиковый лимитер, тот, что следит за сэмпловыми пиками, и довериться ему в защите истинного пика. Он не может. Сэмпловый лимитер спокойно пропускает файл, чьи отсчёты все сидят на −1,0 dBFS, но чья восстановленная волна достигает +0,2 dBTP, потому что лимитер никогда не смотрит между отсчётами. Вы ставите потолок −1 и всё равно отгружаете межотсчётные превышения.

Исправление – true-peak-лимитер: тот, что передискретизирует внутри (та же операция BS.1770) и лимитирует восстановленный пик. AES TD1008 конкретен: когда лимитирование нужно, следует «использовать true-peak-лимитер, который предвидит и контролирует уровень пика после цифро-аналогового преобразователя и фильтра реконструкции устройства воспроизведения». Каждый серьёзный плагин-лимитер, выпущенный примерно с 2012 года, предлагает true-peak-режим; иногда он выключен по умолчанию. Включите его и задайте потолок в dBTP, а не в dBFS.

Вторая, тоньше, ловушка: true-peak-лимитирование до пересчёта частоты не защищает от выброса, который вносит сам пересчёт. AES TD1008 отмечает, что нисходящий пересчёт «может убрать энергию программы и тем самым вызвать выброс», и что «размещение true-peak-лимитера после пересчёта – единственный способ надёжно предотвратить выброс пика». Если ваш конвейер понижает частоту – скажем, мастера 96 кГц до доставки 48 кГц – измеряйте и лимитируйте истинный пик после этого шага, а не до.

Где здесь Фора Софт

В OTT- и Internet-TV-конвейерах, которые мы строим, true-peak-лимитирование живёт на шаге транскодирования и упаковки, а не в загрузке. Единый мезонин-мастер измеряется по истинному пику один раз, затем каждая рендиция с потерями получает потолок лимитера, выбранный под её битрейт – жёстче для низкобитрейтных мобильных профилей, мягче для высокобитрейтных, – чтобы ни один профиль не клиппировал на телефоне. В продуктах видеоконференций и телемедицины, которые мы поставляем, та же дисциплина применяется к real-time-пути Opus, где клиппнутые пики на дешёвых наушниках врача или ученика – не косметика, а провал основной задачи продукта. Встроить контроль истинного пика в упаковку, по профилям, – это разница между каталогом, что играет чисто на оборудовании, которое есть у людей, и тем, что генерирует жалобы на искажение от устройств, которые вы не можете протестировать.

Главное

• Сэмпловые метры читают сохранённые отсчёты; истинный пик – волна между ними.
• Истинный пик в dBTP может превышать сэмпловый на 0,5–1,5 dB на ярком материале.
• ITU-R BS.1770-5 измеряет его передискретизацией 4× (48→192 кГц) и чтением пика.
• Кодеки с потерями добавляют выброс; он растёт при падении битрейта (AES TD1008).
• Доставляйте на −1 dBTP (−2 dBTP для низкого битрейта или строгих платформ).
• Используйте true-peak-лимитер, не сэмпловый; лимитируйте после понижения частоты.

Что читать дальше

• LUFS: целевые значения по платформам в 2026 – число громкости, идущее рядом с потолком dBTP.
• Нормализация громкости: EBU R128, ITU-R BS.1770, ATSC A/85 – стандарты, задающие потолок −1 dBTP.
• Громкость на практике: dialnorm, нормализация, replay gain – почему подъём может вытолкнуть тихий мастер за потолок.