Интернет-радио

Internet radio

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

Такое определение соединяет два признака: доставку звука по сети и общую последовательность программы. Документация Icecast описывает передачу потока от источника слушателям, а британский обзор Digital radio and audio review различает радио и аудио по запросу, включая подкасты [1, 2]. Слово «линейный» обозначает здесь именно порядок программы, заданный её создателем, а не слушателем.

Кратко

  • Интернет-радио описывает способ доставки и организации программы, а не конкретный формат аудиофайла [1, 2].
  • Источник программы, сервер и плеер выполняют разные задачи; работоспособность одного звена ещё не проверяет остальные [2].
  • Для доставки существуют разные технические решения; HTTP Live Streaming — один из них [2, 3].
  • Подключения к потоку, слышимое воспроизведение и аудитория — разные предметы измерения; различие разобрано в учебном примере ниже.

Происхождение и история термина

Понятие связывает радиопрограмму с интернет-доставкой. Один из документированных ранних эпизодов — запуск интернет-трансляции студенческой станции WXYC Университета Северной Каролины 7 ноября 1994 года. Университет описывает участие Пола Джонса и Майкла Шоффнера в этом проекте [4]. Это конкретное событие в истории сетевого радио; дата начала этого интернет-потока не является датой основания WXYC и не устанавливает первое употребление самого термина.

Со временем интернет-доставка стала соседствовать с другими способами слушания. Британский обзор, обновлённый в 2022 году, описывает сочетание радио, аудио по запросу и подключённых устройств [1]. Это важное изменение самого сервиса: у одной программы могут появиться текущий поток и архив, но действия слушателя в них различаются. Данные обзора здесь служат историческим контекстом, а не описанием сегодняшних долей рынка.

Параллельно развивались способы передачи непрерывного медиапотока. В августе 2017 года опубликован документ RFC 8216, описывающий HTTP Live Streaming, сокращённо HLS. Его введение относит первую публикацию проекта протокола к 2009 году [3]. Протокол — правила обмена данными между отправителем и получателем; появление отдельного протокола нельзя отождествлять с появлением интернет-радио.

RFC 8216 имеет информационный статус: он описывает протокол, но не относится к ветви интернет-стандартов [3]. Это различие категорий технических документов. На 2 ноября 2026 года второе издание HLS ещё проходит редакционную подготовку как проект (draft-pantos-hls-rfc8216bis-22), а не опубликованная замена RFC [5]. Поэтому базовая схема ниже объясняется по RFC 8216; требования к конкретному плееру зависят от его реализации.

Суть и механизм

Путь звука удобно разобрать на учебной станции «Городской разговор». Утром ведущая читает новости, затем программа воспроизведения включает заранее подготовленное интервью. Оба материала входят в одну последовательность. Слушатель, подключившийся в середине интервью, попадает в текущую программу. Если рядом на сайте есть кнопка «Слушать интервью с начала», она предлагает другой способ потребления того же материала — по запросу. Этот пример поясняет различие радио и архива, а не описывает реальную станцию. Записанное вчера интервью не перестаёт быть частью текущей программы: линейность относится к порядку слушания, а прямое выступление — к тому, когда создаётся материал.

Техническую основу можно увидеть в документации Icecast: программа-источник передаёт данные серверу, а слушатели подключаются к выбранному потоку. Сервер распределяет полученный материал, но сам по себе не заменяет программу-источник [2]. В учебной схеме перед отправкой звук кодируется — преобразуется в цифровое представление, которое сможет прочитать плеер. Кодек выполняет кодирование и обратное преобразование аудио [10]; MP3 — пример поддерживаемого Icecast аудиоформата [2].

Следующее звено — сервер, то есть программа, принимающая подключения и выдающая данные. Плеер на устройстве слушателя получает аудио и воспроизводит его. В Icecast отдельный поток имеет собственное имя, или mountpoint: в учебном примере — /talk.mp3. Похожее на файл имя не обещает, что передача хранится целиком и её можно перемотать к началу. На одном сервере могут находиться разные программы либо варианты одной программы с разным битрейтом [2]. Битрейт показывает, сколько бит аудиоданных приходится на секунду [10]; связь этого показателя с объёмом трафика разобрана ниже.

В HLS поток доставляется частями — медиасегментами. Плеер сначала получает плейлист: текстовый список адресов этих частей. Затем загружает и последовательно воспроизводит сегменты, обновляя список для получения новых [3]. Здесь плейлист — технический документ, а не музыкальная подборка редактора. Зная это различие, проще понять ситуацию, когда список доступен, а указанные в нём аудиофрагменты получить не удалось.

Работу сервера легко спутать с работой всей станции. В нашем примере источник отправляет тишину, хотя соединение с сервером сохраняется. Плеер исправно получает и воспроизводит эти данные. Проверка «адрес открывается» пройдёт успешно, но слушатель новостей не услышит. Поэтому редакции полезно заранее решить, какой результат считается нормальным: доступность адреса, наличие любого звука или воспроизведение именно запланированной передачи. Эти критерии отвечают на разные вопросы.

Виды и классификации

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

Другое основание деления — организация доставки. В одном учебном проекте команда сама обслуживает сервер, в другом поручает это подрядчику. Различие важно прежде всего для ответственности: кто замечает отказ, кому доступен журнал ошибок и кто восстанавливает поток. Из самого способа обслуживания не следует, что система дешевле или надёжнее. Такой вывод потребовал бы сравнения стоимости и работы конкретных проектов при одинаковых условиях.

Наконец, линейная программа и архив могут соседствовать в одном интерфейсе. Британский обзор описывает объединение радио, музыки и подкастов в цифровых сервисах [1]. Поэтому надпись «радио» на главной странице ещё не объясняет режим каждой кнопки. В учебном интерфейсе достаточно двух понятных действий: «Слушать текущую программу» и «Выбрать запись». Архивная передача и отдельный выпуск подкаста могут оба относиться ко второму действию; это не взаимоисключающие технические категории. Такая подпись объясняет, присоединится ли человек к текущему разговору или начнёт выбранный материал.

Как применяется на практике

Исторический пример WXYC показывает сетевое распространение программы существующей станции [4]. В британском обзоре другой акцент: цифровой сервис объединяет разные способы слушания и устройства [1]. Эти примеры помогают сформулировать задачу проекта без предположения, что всем станциям нужна одинаковая архитектура. Одной редакции достаточно дополнительного пути к эфиру, другой требуется самостоятельная программа с собственным расписанием.

Продолжим учебный пример в российском городе. Редакция «Городского разговора» хочет передавать утреннее интервью через сайт. Она задаёт три проверяемых результата: посетитель находит кнопку запуска; после нажатия слышит текущую программу; дежурный редактор узнаёт о прекращении передачи. Первый результат относится к интерфейсу, второй — ко всему пути звука, третий — к организации контроля. Установка сервера решает только часть этой задачи.

При первом посещении страницы браузер может запретить автоматический запуск звука. MDN связывает такие ограничения, в частности, с отсутствием взаимодействия пользователя с сайтом; точные правила различаются между браузерами [6]. Поэтому в учебном проекте предусмотрена явная кнопка воспроизведения. При проверке редактор отдельно записывает, появился ли звук после нажатия. Формулировка «автозапуск заблокирован» точнее, чем «радио сломалось», если ручной запуск работает.

Российский контекст касается и оценки результата. Mediascope описывает Radio Index как исследование аудитории с опросом о радиослушании предыдущего дня — методикой Day-After-Recall [7]. Это другой способ получения сведений, чем чтение серверного журнала. Наличие сетевого потока само по себе не сообщает, сколько дополнительных людей услышали программу. Для ответа требуется заранее выбрать показатель и способ его получения.

Как измерить или проверить

Ниже приведены учебные расчёты редакции, а не данные реальной станции и не нормативные показатели качества. Первый расчёт отвечает на вопрос о трафике. Пусть постоянный битрейт равен 128 килобитам в секунду, а соединение длится один час без разрывов. В десятичной системе килобит содержит тысячу бит, мегабайт — миллион байтов; в одном байте восемь бит. Поэтому для перехода от бит к байтам нужно делить на восемь.

Объём получают умножением скорости данных на время [10]. Для наших единиц формула имеет вид:

V=b×1000×t/(8×1 000 000).V = b \times 1000 \times t / (8 \times 1\,000\,000).

Здесь V — объём в мегабайтах, b — битрейт в килобитах в секунду, t — продолжительность в секундах. За час получится 128 × 1000 × 3600 / 8 = 57 600 000 байтов, то есть 57,6 мегабайта. Это объём самого аудио при заданных допущениях. В расчёт намеренно не включены служебные данные передачи и повторные загрузки; их необходимо учитывать отдельно при сравнении с показаниями счётчика трафика.

Теперь допустим, что сто соединений непрерывно получают этот поток в течение часа. Суммарный расчётный объём аудио составит 5760 мегабайт, или 5,76 гигабайта. Скорость выдачи аудиоданных всем соединениям вместе — 12,8 мегабита в секунду. Оба результата относятся к явно заданной модели прямой раздачи. Число сто здесь означает одновременно обслуживаемые соединения, а не сто разных людей и не сто посетителей сайта за сутки.

Второй расчёт описывает контрольные проверки. Редакция назначила сто запусков теста за сутки. Успехом считается получение и слышимое воспроизведение правильной программы в выбранном плеере. Успешны девяносто семь запусков. Долю успешных проверок получают делением их числа на число всех выполненных проверок и умножением на сто процентов. В примере результат равен 97%. Знаменатель включает и три неудачных запуска: если их исключить, показатель утратит смысл. Если тест не состоялся, его отмечают как пропуск наблюдения, а не как исправное или неисправное воспроизведение. При отсутствии выполненных проверок доля не определяется: делить на ноль нельзя.

Из этого результата нельзя вычислить длительность простоя. Между двумя тестами поток мог отключиться и восстановиться; разные проверки могли охватывать разные сети. Для оценки времени нарушения нужны сведения о его начале и окончании. Если вместо контроля правильной программы проверять лишь ответ сервера, получится другой показатель, даже при том же расписании тестов. Поэтому название метрики должно сохранять критерий успеха.

Третий пример показывает различие соединений и аудитории. Один человек слушает с телефона, теряет связь и подключается снова. Второй включает поток на одном устройстве для двух коллег. В условном журнале получатся три соединения, а в комнате и с телефоном могут находиться четыре слушателя. Этот сценарий не оценивает частоту такого поведения, но доказывает, почему простое равенство «соединение = человек» не работает. Для оценки аудитории нужна отдельная методика, подобно тому как Radio Index задаёт собственный способ опроса [7].

Ошибки, ограничения и спорные вопросы

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

Допустим, контрольная фраза прозвучала в студии в 10:00:00 и в плеере в 10:00:12: наблюдаемая задержка составляет двенадцать секунд. Кнопка нажата в 10:00:09, а первый звук — окончание предыдущей реплики — появился в 10:00:10. Запуск занял одну секунду, хотя фразу пришлось ждать три. Эти разные интервалы нельзя подписывать одним словом «задержка». Если ведущая объявляет конкурс, именно момент, когда участник услышал приглашение, помогает понять практическое значение отставания.

Другая ошибка — делать вывод о всех слушателях по одному исправному устройству. В учебном испытании можно проверить домашнее подключение и мобильную сеть, несколько браузеров и повторный запуск после обрыва. Это расширит набор наблюдений, но не превратит выборочную проверку в сплошной контроль. Особенно полезно записывать разные симптомы: плеер не запускается, звук прерывается, звучит резервная запись, программа отстаёт от контрольного источника.

Наконец, восстановление соединения и восстановление нужной программы могут произойти в разное время. Допустим, после сбоя сервер сначала выдаёт резервную запись, а интервью возвращается позднее. Для технической службы важна первая отметка, для редактора передачи — вторая. Если объединить их одной записью «работа восстановлена», отчёт скроет часть нарушения. Раздельный журнал позволяет объяснить, что именно услышал контрольный слушатель и чего проверка не установила.

Правовой аспект

Для российского проекта техническая возможность передавать звук не означает разрешения использовать произведение. Пункты 1 и 2 статьи 1270 ГК РФ закрепляют исключительное право и относят перечисленные способы использования к использованию произведения независимо от получения прибыли [8]. Следовательно, бесплатный доступ к станции сам по себе не снимает вопроса о правах. Юридическая квалификация конкретной передачи и состав разрешений требуют отдельного рассмотрения; это не инструкция по оформлению вещания.

Для персональных данных — информации об определённом или определяемом человеке — статья 5 закона № 152-ФЗ требует соотносить обработку с её целями, ограничивать состав данных и сроки хранения [9]. Срок хранения в форме, позволяющей определить человека, связан с целями обработки; часть 7 предусматривает исключения для срока, установленного законом или соответствующим договором, и правила уничтожения либо обезличивания после достижения целей [9]. Применительно к учебной станции это повод отдельно рассмотреть сведения из регистрации и аналитики, а не считать любую полезную статистику автоматически допустимой. Какие данные являются персональными в конкретной системе, определяется с учётом возможности установить человека [9].

Правовые ссылки приведены на 2 ноября 2026 года: часть четвёртая ГК РФ — редакция от 23 июля 2025 года, действующая с 4 января 2026 года; закон № 152-ФЗ — редакция от 26 июля 2026 года, действующая с этой даты [8, 9]. Проверка правового статуса и договоров конкретной станции выходит за пределы справочного определения.

Частые вопросы

Чем интернет-радио отличается от подкаста?

Прежде всего способом выбора момента прослушивания: текущая радиопрограмма идёт по своей последовательности, а выпуск по запросу выбирает слушатель. Один сервис может объединять оба режима [1]. В учебном примере это кнопки текущего потока и записи интервью с начала.

Обязательно ли использовать HLS?

Нет. HLS описывает конкретную сегментную доставку, а документация Icecast показывает серверную раздачу аудиопотока [2, 3]. Выбор технологии не меняет редакционный вопрос: какую программу слушатель должен получить сейчас?

Почему сервер доступен, а звук не запускается?

Сначала стоит различить автоматический и ручной запуск: браузер может ограничивать первый [6]. Затем в учебной диагностике проверяют само аудио и выбранный плеер. Ответ сервера подтверждает только тот участок, который действительно проверили.

Можно ли назвать подключения числом слушателей?

Без методики, связывающей эти события с людьми, такое переименование некорректно. Пример с переподключением и совместным прослушиванием показывает расхождение. Результат серверного наблюдения следует называть соединениями, а исследование аудитории описывать отдельно [7].

Связанные термины

Источники

  1. Department for Digital, Culture, Media & Sport. (2022, April 28). Digital radio and audio review. Executive Summary, §§ 0.1, 0.8–0.9; § 1.10. https://www.gov.uk/government/publications/digital-radio-and-audio-review/digital-radio-and-audio-review (дата обращения: 02.11.2026). ↑ а б в г д е
  2. Xiph.Org Foundation. (n.d.). Icecast 2.4.1 documentation: Introduction; Basic setup. https://icecast.org/docs/icecast-latest/ ; https://icecast.org/docs/icecast-latest/basic_setup/ (дата обращения: 02.11.2026). Прочитана документация с указанным заголовком версии, не утверждение о последнем выпуске программы. ↑ а б в г д е ж з
  3. Pantos, R., & May, W. (2017). HTTP Live Streaming (RFC 8216). RFC Editor. https://www.rfc-editor.org/info/rfc8216/ (дата обращения: 02.11.2026). Status of This Memo; §§ 1–2; статус публикации. ↑ а б в г д
  4. University Communications. (2019, November 6). Well Said: WXYC and the first internet simulcast. The University of North Carolina at Chapel Hill. https://www.unc.edu/discover/well-said-wxyc-and-the-first-internet-simulcast/ (дата обращения: 02.11.2026). ↑ а б
  5. 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). Карточка статуса и Status of This Memo. ↑
  6. MDN contributors. (n.d.). Autoplay guide for media and Web Audio APIs. MDN Web Docs. https://developer.mozilla.org/en-US/docs/Web/Media/Guides/Autoplay (дата обращения: 02.11.2026). Autoplay and autoplay blocking; Autoplay availability. ↑ а б
  7. Медиаскоп. Радио: Radio Index : описание проекта [Электронный ресурс]. URL: https://mediascope.net/services/media/media-audience/radio/radio-index/description/ (дата обращения: 02.11.2026). ↑ а б в
  8. Российская Федерация. Гражданский кодекс Российской Федерации (часть четвёртая) : от 18.12.2006 № 230-ФЗ : ред. от 23.07.2025, с изм. и доп., вступ. в силу с 04.01.2026. Ст. 1270, п. 1; вводная часть п. 2 [Электронный ресурс] // КонсультантПлюс. URL: https://www.consultant.ru/document/cons_doc_LAW_64629/dffcf0b87b80ff38f430dc822a0074e76ccd41a0/ (дата обращения: 02.11.2026). ↑ а б
  9. Российская Федерация. О персональных данных : Федеральный закон от 27.07.2006 № 152-ФЗ : ред. от 26.07.2026. Ст. 3, п. 1; ст. 5, ч. 1–7 [Электронный ресурс] // Контур.Экстерн. URL: https://www.kontur-extern.ru/info/normativ/document/1/507366-federalnyy-zakon-ot-27-07-2006-n-152-fz (дата обращения: 02.11.2026). ↑ а б в г
  10. MDN contributors. (n.d.). Web audio codec guide; Digital audio concepts. MDN Web Docs. https://developer.mozilla.org/en-US/docs/Web/Media/Guides/Formats/Audio_codecs ; https://developer.mozilla.org/en-US/docs/Web/Media/Guides/Formats/Audio_concepts (дата обращения: 02.11.2026). Введение; Audio file size and network bandwidth; Lossy encoder parameters: Bit rate. ↑ а б в

Служебный блок

Версия
3.0
Факты проверены
Подготовка
Редакция Медиатрона
Публикация
утверждена владельцем издания 4 ноября 2026 г.

Редакция Медиатрона. Факты сверены с первоисточниками на дату проверки, публикация утверждена владельцем издания.

Нашли ошибку? info@mediatrone.ru