Как без проблем объединить потоки MP3?

Question

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

Сервер будет работать аналогично Icecast, то есть он будет считывать поток по сети из какого-либо генератора потока и передавать его каждому слушателю. Когда пришло время транслировать рекламу, сервер прекращает извлекать поток из генератора, читает объявления из файлов и вставляет их в буфер каждого слушателя, передает их и возобновляет ретрансляцию потока из генератора.

Когда сервер переключается с ретрансляционного потока на широковещательную рекламу, он должен объединить два потока MP3 (мы транслируем в формате MP3). Меня беспокоит то, что простое добавление одного фрагмента данных за другим может привести к появлению некоторых слышимых артефактов. Это можно сделать без проблем?

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

Но меня беспокоит, как работает MDCT. Слушатели не имеют ни малейшего представления о том, что будет делать мой сервер, поэтому их MP3-декодеры могут создавать некоторые артефакты, поскольку некорректные данные MDCT будут помещаться один за другим в поток, который они загружают. Будет ли это дополнять нулями в начале файла с объявлением?

Знаете ли вы какие-либо библиотеки / инструменты (если возможно, с открытым исходным кодом), которые могут беспрепятственно объединять два файла MP3, не распаковывая их?

Можете ли вы указать какие-либо хорошие ресурсы, описывающие формат MP3? Я много искал в Интернете, находил много информации, но все еще скучаю по общей картине.

Может быть, вы знаете, что было бы проще, если бы я использовал другой кодек, такой как OGG / Vorbis, AAC?

PS. Этот вопрос не является дубликатом Каков наилучший способ объединения mp3-файлов? . Для меня не подходят mp3wrap и инструменты.

Answer 1

Вы должны иметь возможность объединять mp3-файлы в форматах CBR и VBR. Файлы MP3 не имеют основного заголовка (без учета ID3 и Xing). Аудиоданные хранятся в виде фрагментов, где каждый блок содержит свой собственный заголовок. Заголовок содержит необходимую информацию (битрейт, частоту дискретизации, стерео и т. Д.) Для декодирования аудиоданных в этом фрагменте.

Это одна из причин, по которой трудно определить длительность mp3-файла.

Другой способ посмотреть на это, если вы объедините файл CBR MP3 с файлом VBR, конечный результат будет таким же, как один длинный файл VBR с первым разделом Audio с постоянной скоростью передачи битов.

Проблема в том, что некоторые MP3-плееры могут быть строгими и ожидать Xing-заголовка для файла VBR MP3. Это, однако, никогда не было спецификацией для формата MP3, но теперь предполагается, что это правда.

Answer 2

Я считаю, что MP3 можно объединить, просто объединяя файлы. В некоторых быстрых тестах (cat file1.mp3 file2.mp3 > merged.mp3; mplayer merged.mp3) это работает, как и ожидалось. Потоковая передача с веб-сервера, вероятно, будет работать так же хорошо.

Как вы собираетесь обрабатывать переключение текущего входного файла? Вы можете просто рассматривать рекламные объявления как короткие треки для воспроизведения.

Answer 3

Я не понимаю, почему вы хотите объединить файлы. Почему бы вам не использовать какую-то систему списков воспроизведения и просто изменить файл, который вы отправляете. Я бы подумал, что это обеспечит большую гибкость в долгосрочной перспективе, и вы не получите большие файлы MP3.

Answer 4

Я подошел к очень похожей проблеме, и, задавая правильные вопросы из разных источников, придумал следующее ...

Любой достойный декодер пропускает «плохие» данные, пока не достигнет действительного заголовка кадра. Это то, на что полагается ID3v2 для добавления дополнительной информации в данные mp3. На сервере я бы пошел с анализом исходных файлов MP3, чтобы обслуживать только допустимые кадры MP3. Если вы обслуживаете несколько бесшумных кадров (около 7 должно это сделать), у декодера должно быть время для установки перед тем, как приступить к следующей загрузке (неассоциированных) данных MP3, избегая артефактов, которые вы (правильно) допускаете при объединении кадров из другой кодировки сессий.

Более проблематичным является возможное переключение атрибутов MP3 (1/2 канала, выходной частоты дискретизации и т. Д.) Между кадрами. Некоторые декодеры очень расстраиваются, когда сталкиваются с таким потоком, что приводит к 1/2 скорости воспроизведения и тому подобному. Таким образом, вы должны убедиться, что весь ваш исходный материал закодирован с одинаковыми выходными атрибутами, иначе вы можете открепиться.

Возможно, вы уже видели это, но если нет:

http://www.devhood.com/tutorials/tutorial_details.aspx?tutorial_id=79&printer=t

Answer 5

Если вы работаете в Windows, Microsoft DirectShow API может быть подходящим вариантом. Вы должны обнаружить, что он способен работать со звуком и видео как статически, так и с потоковой передачей, в различных форматах (вам нужны только необходимые кодеки, и интерфейс практически одинаков для всех).

Скажем так, DirectShow, к сожалению, разработан ужасно запутанным способом и имеет крутую кривую обучения, но мощность, которую он предлагает, не имеет себе равных, если вы собираетесь делать аудио / видео манипуляции в Windows. Тем не менее, существует огромное количество примеров и учебных пособий о том, как его использовать, так что в конечном итоге это может быть не так больно. Кроме того, если вы используете .NET Framework, существует управляемая оболочка с именем DirectShow.NET . Это не будет легкой задачей, что бы вы ни делали, если только не будет чего-то, чего я не знаю. В любом случае, удачи вам!