Как я беспрепятственно связываю потоки MP3?

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

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

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

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

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

I approached a very similar problem, and after asking the right questions at various sources came up with the following...

Any worthy decoder will skip "bad" data until it hits a valid frame header. This is what ID3v2 relies upon to inject additional information into mp3 data. At the server, I'd go with analysis of source MP3 files to only serve valid MP3 frames. If you serve a few silent frames (about 7 should do it), the decoder should have time to settle before ramping up for the next load of (unassociated) MP3 data, avoiding the artefacts you (correctly) assume when concatenating frames from different encoding sessions.

More problematic is the possible switching of MP3 attributes (1/2 channels, output sample rate etc) between one frame to the next. Some decoders get quite upset when confronted with such a stream, resulting in 1/2 speed playback and the like. So, you need to ensure that all your source material is encoded to the same output attributes otherwise you may come unstuck.

You may have seen this already, but if not:

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

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

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

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

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