Логирование эфира
Broadcast logging
Логирование эфира — ведение журнала событий вещания с указанием времени и источника данных. Такой журнал помогает найти передачу, рекламный ролик или технический сбой и связать событие с записью либо с сообщением системы, которая его зафиксировала.
Это рабочее определение объединяет две задачи: описать событие и сохранить путь к его проверке. Их техническую основу показывают список файлов с временными границами в документации FFmpeg — программы обработки аудио и видео — и привязка фрагмента потока к календарному времени в техническом документе RFC 8216. В рекомендации профессиональной организации SMPTE журнал исполненных событий содержит фактические время, длительность и статус выхода. Российский закон о СМИ отдельно рассматривает журнал передач и сохраняемые материалы: таблица событий и сама запись выполняют разные функции. [1, 3, 4, 9]
Кратко
- Расписание показывает план; журнал запуска — действие программы; запись приёмника — полученный им звук. В учебной модели ниже эти сведения сопоставляются, но не заменяют друг друга.
- Для поиска по времени нужны дата, часовой пояс, начало записи и положение события внутри файла.
- Отсутствие найденного ролика и отсутствие самого ролика — разные выводы, если запись неполная или поиск ошибается.
- Требования к регистрационному журналу определяет статья 34 закона о СМИ; произвольный технический лог может не содержать всех нужных сведений. [4]
Происхождение и история термина
У практики регистрации эфира есть организационная и техническая стороны. Российская правовая линия представлена законом о СМИ от 27 декабря 1991 года. Его действующая статья 34 связывает сохранение материалов и ведение журнала с обеспечением доказательств при разрешении споров. Это документируемый ориентир истории регулирования, а не дата появления английского выражения broadcast logging. [4]
К 2017 году регистрация исполненных событий получила подробное описание в рекомендации SMPTE RP 2021-9 о формате обмена вещательными данными BXF. В ней журнал as-run связывает событие с фактическим временем, длительностью и результатом исполнения; сообщения о таких событиях обычно поступают от системы автоматизации после выхода. Это документированная веха развития электронных журналов, а не дата изобретения логирования. [9]
Другой ориентир — опубликованное в августе 2017 года описание HTTP Live Streaming, или HLS: способа доставки аудио и видео через интернет последовательностью фрагментов. RFC 8216 описывает версию 7 протокола и содержит правило связи фрагмента с календарным временем. Документ имеет информационный статус, а не статус интернет-стандарта. На дату проверки его предполагаемый преемник, HTTP Live Streaming 2nd Edition, представлен проектом; это ещё не опубликованная замена RFC. [3, 6]
Эти направления дополняют друг друга: регистрационный журнал описывает передачу, журнал автоматизации — исполнение событий, а временные метки помогают найти соответствующее содержание в цифровой записи. Единственного автора широкого термина эти документы не устанавливают. [3, 4, 9]
Суть и механизм
Представим учебную радиостанцию «Город». В расписании на восемь утра стоит рекламный ролик. Программа воспроизведения сообщает, что запустила его. Отдельный приёмник записывает радиосигнал. Это три разных ответа на вопрос «вышел ли ролик»: его запланировали, его начали воспроизводить, его услышали в выбранной точке приёма. Если передатчик в это время не работал, исправный журнал программы не устраняет разрыв между вторым и третьим ответами.
Такое разделение имеет техническую основу и в интернет-вещании. В документации Icecast 2.4.1 различаются клиент-источник, который поставляет содержание, и сервер, который передаёт его слушателям. Здесь используется историческое описание архитектуры, а не перечень возможностей текущего выпуска программы. Из наблюдения за одним звеном нельзя автоматически вывести состояние всех остальных: запись интернет-потока, например, сама по себе ничего не сообщает о звуке на конкретном FM-приёмнике. [2]
Чтобы журнал помогал проверке, одной строки «ролик вышел» недостаточно. В предлагаемой учебной схеме строка содержит название станции, тип источника, дату, часовой пояс, время начала, длительность, идентификатор события и ссылку на участок записи. Идентификатор — постоянное обозначение строки, например event-017. Он позволяет исправить ошибочное название рекламодателя, сохранив связь с тем же событием.
Запись при этом отвечает на вопрос «что звучало», а журнал — «где это искать и что о событии известно». В журнале можно указать рекламодателя, но это указание остаётся результатом распознавания или ручной проверки. Если исходный звук утрачен, название не превращается в самостоятельную копию содержания. Полезность такой схемы особенно заметна при споре: другой сотрудник открывает тот же участок и может проверить вывод.
Как связать событие с файлом
В учебном примере файл начинается 2 ноября 2026 года в 08:00:00 по времени Барнаула (UTC+7), а ролик — через 127 секунд. Значит, его начало соответствует 08:02:07. При длительности ролика 20 секунд его участок занимает позиции от 127-й до 147-й секунды файла. Поиск становится воспроизводимым, если в строке сохранены и имя файла, и эти границы. Само название утро.mp3 такой возможности не даёт.
Для длинного архива запись можно разделить на сегменты — отдельные последовательные файлы. Документация FFmpeg описывает создание списка сегментов, в том числе CSV: текстовой таблицы, где для каждого файла указаны имя, начало и конец в секундах. Параметр segment_time задаёт длительность разбиения, а segment_atclocktime позволяет ориентировать разбиение на регулярные интервалы часов. Заданные границы и фактические границы не следует считать тождественными: документация отдельно предупреждает об ограничениях точного разбиения видео. Новый сегмент начинается с ключевого кадра — кадра, который даёт точку начала декодирования, то есть восстановления изображения из сжатых данных. Если подходящий кадр расположен позднее заданной границы, туда смещается и начало сегмента. Это объясняет, почему в журнале нужны фактические границы файлов. [1, 3]
Поэтому в нашей схеме ссылка на событие строится по проверенным границам записи. Если ролик пересёк стык двух файлов, строка ссылается на оба участка. Иначе проверяющий услышит только начало или только конец и может ошибочно решить, что ролик был оборван в эфире. Это требование учебной модели поиска, а не обещание функции любой программы записи.
Виды и классификации
Для практического разбора удобно классифицировать журналы по тому, откуда получены сведения. Ниже — редакционная классификация, а не обязательный отраслевой стандарт. Она нужна, чтобы одинаково выглядящие строки не воспринимались как одинаковые доказательства.
| Вид журнала | Что записано | Как проверяется строка |
|---|---|---|
| Журнал запуска | Сообщение программы о воспроизведении материала | По данным программы и выбранному материалу |
| Журнал принятого эфира | Событие, связанное с записью конкретного сигнала | Прослушиванием указанного участка |
| Журнал распознавания | Вывод алгоритма о содержании | Сопоставлением результата с исходным звуком |
| Журнал оператора | Отметка сотрудника о событии или проверке | По основанию отметки и сохранённой записи |
Расписание в этой классификации остаётся планом, с которым сравнивают результаты. Один проект может хранить все четыре журнала. Например, программа сообщает о запуске ролика, алгоритм находит похожий звук, а сотрудник подтверждает рекламодателя. Эти записи связаны, но у них разные авторы и основания. Если распознавание позже исправили, сообщение о запуске и исходный звук от этого не меняются.
Ещё одно различие — охват наблюдения. В учебной задаче журнал только рекламных событий не описывает музыку, новости и паузы между ними. Непрерывная запись также не гарантирует непрерывного распознавания. Поэтому характеристику «полный» нужно раскрывать: полный по времени записи, по выбранным событиям или по заполнению обязательных полей. Без этого два сотрудника могут оценить один архив противоположным образом.
Как применяется на практике
Основная прикладная задача — перейти от спорного утверждения к конкретному участку звука. В учебной проверке рекламного заказа редактор сначала называет станцию, дату и проверяемый интервал. Затем сопоставляет план с журналом запуска и приёмной записью. Если ролик найден, указывает его границы. Если не найден, сначала выясняет, весь ли интервал доступен и проверен ли он прослушиванием, а не только автоматическим поиском.
В другом учебном случае слушатель жалуется на слова ведущего «в утренней передаче». Сотрудник уточняет дату и выпуск, открывает соответствующий файл, выделяет спорную фразу вместе с соседними репликами. Контекст нужен, чтобы не принять цитирование чужого высказывания за собственное утверждение ведущего. Журнал помогает найти материал, но содержание и смысл проверяются по самой записи.
В российском вещании к техническим задачам добавляется установленный законом регистрационный журнал. В международном техническом примере HLS задача иная: связать фрагмент доставки с временем. Это не альтернативные формы одного документа. Юридический журнал описывает передачи и их участников, а техническая метка может описывать начало фрагмента продолжительностью несколько секунд. [3, 4]
Почему важны часы
Продолжим учебный пример: журнал запуска показывает 08:00:00, а приёмная запись — 08:00:07. Разность составляет семь секунд, но причины ещё неизвестны. Допустим, проверка часов установила, что часы приёмного устройства спешат на две секунды. После этой поправки начало записи соответствует 08:00:05 по общей шкале. Остаток составляет пять секунд; он требует отдельного объяснения, например проверки задержки передачи. Из одной разницы нельзя выбрать причину.
В рабочей таблице такого примера сохраняются исходная отметка, поправка и результат. Бесследная замена 08:00:07 на 08:00:05 скрыла бы, какие данные действительно получены от устройства. При повторном разборе важно также знать, на каком интервале проверяли часы: измерение в начале дня само по себе не описывает их состояние после перезапуска.
В HLS метка EXT-X-PROGRAM-DATE-TIME связывает первый отсчёт следующего медиасегмента с абсолютной датой и временем. Здесь первый отсчёт означает начальный элемент звукового или видеосодержимого сегмента: метка относится к началу содержания, а не к моменту загрузки файла. RFC рекомендует указывать часовой пояс и доли секунды. Это привязка содержания, а не свидетельство одновременного прослушивания всеми людьми. Она также не превращает имя файла в точную метку времени. [3]
Как измерить или проверить
В предлагаемой редакционной проверке сначала определяется период и смысл показателя. Для полноты записи знаменатель — вся длительность проверяемого периода. Числитель — время, для которого нужная запись действительно доступна. Пробел означает участок без проверяемого материала; простая тишина не объявляется пробелом автоматически, поскольку тишина могла быть частью передачи.
Учебный расчёт: проверяем час, то есть 3600 секунд. В нём два непересекающихся пробела по 30 секунд. Доступны 3540 секунд. Доля доступной записи равна доступной длительности, делённой на длительность периода и умноженной на сто: 3540 / 3600 × 100 ≈ 98,33%. Это ответ только о покрытии времени. Он не оценивает разборчивость речи, правильность названий рекламодателей или исполнение договора.
Если пробелы пересекаются, сначала считают их общую неповторяющуюся длительность. Допустим, первый занимает время с 08:10:00 до 08:10:30, второй — с 08:10:20 до 08:10:50. Каждый длится 30 секунд, но вместе они закрывают 50, а не 60 секунд. Для того же часа доступная доля составит 3550 / 3600 × 100 ≈ 98,61%. При нулевой длительности проверяемого периода показатель не определён: делить на ноль нельзя.
Для автоматического поиска полезно отдельно оценивать пропуски и ложные находки. Полнота поиска показывает долю найденных событий среди всех действительных, а точность находок — долю верных среди всех результатов системы; такие знаменатели используются в оценке классификации. [8] В учебной выборке человек подтвердил 20 рекламных выходов. Алгоритм нашёл 18 из них и дополнительно ошибочно отметил два других участка. Полнота поиска равна 18 / 20 = 90%: знаменатель здесь — все подтверждённые выходы. Точность находок также равна 18 / 20 = 90%, но её знаменатель другой — все 20 результатов алгоритма. Совпадение процентов случайно для выбранных чисел, а не обязательно для этих показателей.
Эти расчёты описывают только условную выборку. Прежде чем сравнивать результаты двух проверок, нужно одинаково определить событие: считается ли повтор одного ролика отдельным выходом, какое отклонение времени допустимо, как учитывается обрезанный ролик. Иначе различие процентов может отражать разные правила подсчёта. Здесь никаких испытаний RadioMon или другого продукта не проводилось.
Ошибки, ограничения и спорные вопросы
Самая опасная ошибка — уверенное отрицание по неполным данным. Если запись отсутствует с 08:15:00 до 08:16:00, фраза «ролик за час не выходил» сильнее имеющихся оснований. Корректный результат учебной проверки: на доступных участках ролик не найден, а минутный пробел проверить невозможно. Это сохраняет полезный результат поиска, не маскируя неизвестное.
Другая ошибка возникает при передаче архива. Таблица может содержать правильный путь к файлу, доступному только на компьютере составителя. Для второго сотрудника такая ссылка не работает. Поэтому в учебной процедуре передачи проверяется открытие файлов с его разрешённым уровнем доступа. Недоступность архива конкретному сотруднику не доказывает отсутствия звука в архиве или события в эфире.
Наконец, количество выходов нельзя превращать в число слушателей. В рассматриваемой модели журнал содержит сведения о материалах и времени, но не данные о людях, которые слушали передачу. Десять подтверждённых повторов ролика дают десять событий, а не десять человек и не показатель охвата. Для вывода об аудитории потребовались бы другие исходные данные и метод измерения.
Правовой аспект
На 2 ноября 2026 года применяется редакция закона о СМИ от 26 июня 2026 года, действующая с 1 сентября 2026 года. Статья 34 разграничивает материалы собственных передач, вышедших в записи, и регистрационный журнал вышедших передач. Для материалов предусмотрен минимум один месяц от выхода в эфир; для журнала — минимум год от последней записи. В журнал включаются сведения о дате и времени выхода, теме, авторе, ведущем и участниках. Дата 1 сентября относится к действию сводной редакции закона: поправка 215-ФЗ изменила статью 4, а не ввела заново перечисленные требования статьи 34. [4, 10]
Для записей программ с предвыборной агитацией или агитацией по вопросам референдума та же статья устанавливает хранение вещательной организацией не менее 12 месяцев от выхода. Копии предоставляются бесплатно по требованию соответствующих комиссий. Поэтому общего правила «любой архив хранится месяц» из этой нормы не следует. [4]
Хранение и открытая публикация — также разные правовые вопросы. Статья 1270 ГК РФ относит запись произведения на электронный носитель к воспроизведению, а доступ любого лица из любого места в выбранное им время — к доведению до всеобщего сведения. Наличие контрольной записи само по себе не предоставляет разрешения опубликовать чужие произведения. Использована редакция части четвёртой ГК РФ от 23 июля 2025 года с изменениями, действующими с 4 января 2026 года; закон 296-ФЗ вступит в силу 1 января 2027 года и изменит другие статьи части IV, но не статью 1270. Конкретные основания записи и доступа требуют юридической оценки. [5, 7]
Частые вопросы
Лог и аудиозапись — одно и то же?
Нет. Журнал описывает события и помогает их найти, а аудиозапись сохраняет звук. В учебной схеме их связывают именем файла и границами участка.
Достаточно ли собственного плейлиста для подтверждения выхода?
Если это расписание, оно подтверждает план. Если это журнал воспроизведения, нужно установить, какое действие он фиксирует. Для проверки принятого сигнала требуется соответствующая запись или другое наблюдение в названной точке.
Почему метки времени в двух журналах различаются?
Причину устанавливают отдельно: проверяют часы, часовой пояс и путь сигнала. В учебном примере поправка часов объяснила две секунды из семи; оставшиеся пять нельзя автоматически считать опозданием запуска.
Заменяет ли автоматический лог обязательный журнал?
Это зависит от его содержания и применимых требований. Один список файлов не содержит всех сведений о передачах и участниках, предусмотренных статьёй 34 закона о СМИ. [4]
Решить с помощью сервиса
По справке владельца RadioMon работает в Барнауле: записывает эфир региональных радиостанций и с помощью ИИ разбирает рекламные выходы — рекламодателя, время и частоту. Эти данные относятся к задаче проверки рекламных событий в записанном эфире. Сервис не измеряет аудиторию и рейтинги.
Связанные термины
Источники
- FFmpeg Developers. (n.d.). FFmpeg formats documentation: Segment, stream_segment, ssegment. Retrieved November 2, 2026, from https://ffmpeg.org/ffmpeg-formats.html#segment_002c-stream_005fsegment_002c-ssegment ; описание программы: https://www.ffmpeg.org/ffmpeg.html#Description ↑ а б
- Xiph.Org Foundation. (n.d.). Icecast 2.4.1 documentation. Historical version. Retrieved November 2, 2026, from https://icecast.org/docs/icecast-latest/ ↑
- Pantos, R., & May, W. (2017, August). HTTP Live Streaming (RFC 8216, Informational). RFC Editor. https://www.rfc-editor.org/info/rfc8216/ (дата обращения: 02.11.2026). ↑ а б в г д е
- Российская Федерация. О средствах массовой информации : Закон РФ от 27.12.1991 № 2124-1 : ред. от 26.06.2026, действует с 01.09.2026 : ст. 34 // КонсультантПлюс. URL: https://www.consultant.ru/document/cons_doc_LAW_1511/4e8268743fc43899dc3c3e536f4136b0a6780977/ (дата обращения: 02.11.2026). ↑ а б в г д е ж з
- Российская Федерация. Гражданский кодекс Российской Федерации (часть четвёртая) : от 18.12.2006 № 230-ФЗ : ред. от 23.07.2025, с изм. и доп., вступ. в силу с 04.01.2026 : ст. 1270, п. 1, п. 2, подп. 1, 11 // КонсультантПлюс. URL: https://www.consultant.ru/document/cons_doc_LAW_64629/dffcf0b87b80ff38f430dc822a0074e76ccd41a0/ (дата обращения: 02.11.2026). ↑
- Pantos, R. (2026, May 1). HTTP Live Streaming 2nd edition (draft-pantos-hls-rfc8216bis-22). Internet-Draft, work in progress. IETF Datatracker. https://datatracker.ietf.org/doc/draft-pantos-hls-rfc8216bis/ (дата обращения: 02.11.2026). ↑
- Российская Федерация. О внесении изменений в часть четвертую Гражданского кодекса Российской Федерации : Федеральный закон от 04.08.2026 № 296-ФЗ : ст. 1–2, вступает в силу с 01.01.2027 // Гарант. URL: https://www.garant.ru/products/ipo/prime/doc/414600605/ (дата обращения: 02.11.2026). ↑
- Google. (2026, January 12). Classification: Accuracy, recall, precision, and related metrics. Machine Learning Crash Course. Разделы Recall, Precision, What does NaN mean in the metrics? https://developers.google.com/machine-learning/crash-course/classification/accuracy-precision-recall (дата обращения: 02.11.2026). ↑
- Society of Motion Picture and Television Engineers. (2017). Implementing Broadcast Exchange Format (BXF) (SMPTE RP 2021-9:2017), § 13.5, pp. 68–69. Approved June 27, 2017. https://pub.smpte.org/pub/rp2021-9/rp2021-9-2017.pdf (дата обращения: 02.11.2026). ↑ а б в
- Российская Федерация. О внесении изменений в отдельные законодательные акты Российской Федерации : Федеральный закон от 26.06.2026 № 215-ФЗ. Ст. 2, 6 // Контур.Экстерн. URL: https://www.kontur-extern.ru/info/normativ/document/1/506819-federalnyy-zakon-ot-26-06-2026-n-215-fz (дата обращения: 02.11.2026). ↑
Служебный блок
- Версия
- 3.0
- Факты проверены
- Подготовка
- Редакция Медиатрона
- Публикация
- утверждена владельцем издания 4 ноября 2026 г.
Редакция Медиатрона. Факты сверены с первоисточниками на дату проверки, публикация утверждена владельцем издания.
Нашли ошибку? info@mediatrone.ru