2

What we want to do is to add a kind of MP3 preroll to an other MP3 file in real time. That means we have two physical MP3 files on the server which are not merged into one yet, because ffmpeg & Co. take too much time. It has to be in real time to not loose time when someone starts the (web)player. The practical case is to add prerolls to podcast files. What we already did (described below) works, except displaying the correct file duration in audio players.

One of my co-workers did this, so I try to describe as good as possible.

What my coworker already did is telling the header that two files are coming in a row by reading both files and echoing them via PHP. HTTP/1.1 206 Partial Content is used for delivering the "merged" content.

The problem is, that there are still two ID3 Tags from both files and most audio players only read the first one, which occurs wrong duration displays. The only case it works 100% is in VLC after downloading the whole thing. No webplayer, no iTunes etc. can manage the "merged" file duration.

Any idea how to create a "virtual ID3 Tag" in real time and how to remove the existing ones without touching the original files?

neownd
  • 41
  • 4
  • I hope my answer below puts you in the right direction. On another note, I've built a solution for this exact use case in the past. If you're interested in hiring me for consulting and/or coding this up for you (or samples that you can drop-in your application), please feel free to contact brad@audiopump.co. – Brad Jun 17 '19 at 19:33

1 Answers1

0

There are a lot of inaccurate conclusions you've come to, so let me start by correcting those, which may help you solve the problem.

because ffmpeg & Co. take too much time

FFmpeg can merge these audio streams faster than you can stream to clients for sure. If you're using -codec copy (which you should be in this case), it will handle all the demuxing/muxing for you. And, keep in mind that you can stream directly out of FFmpeg. No need for an intermediary file.

The practical case is to add prerolls to podcast files.

The FFmpeg route is what you want.

What my coworker already did is telling the header that two files are coming in a row by reading both files and echoing them via PHP. HTTP/1.1 206 Partial Content is used for delivering the "merged" content.

That's a bit of a wonky way to do this. You could instead just merge the data and send it directly in a single response.

The problem is, that there are still two ID3 Tags from both files and most audio players only read the first one, which occurs wrong duration displays.

No, the usual ID3 tags don't indicate duration. (There is an extension which does, but this is rarely used.) There is nothing in the bare MP3 stream that indicates duration either. Clients estimate this based on file size and bitrate. The bitrate can change mid-stream, so they usually estimate based on the bitrate of the first couple frames.

Undoubtedly, the problem in your case is incorrect length headers due to the way you're handling this merging, and/or a mismatch of bitrate which causes the length estimate from the player to be wrong.

Any idea how to create a "virtual ID3 Tag" in real time and how to remove the existing ones without touching the original files?

I would absolutely use FFmpeg for this work. If anything, because not all podcasts use MP3. There are plenty of AAC in MP4 podcasts, and a handful of Opus in WebM as well.

Brad
  • 159,648
  • 54
  • 349
  • 530