我们要做的是将一种MP3预卷实时添加到另一个MP3文件中。这意味着我们在服务器上有两个物理MP3文件，它们尚未合并到一起，因为ffmpeg＆Co.需要花费太多时间。当某人启动（web）播放器时，必须实时而不松懈。实际情况是将预卷添加到播客文件中。除了在音频播放器中显示正确的文件持续时间外，我们已经做过的工作（如下所述）。
我的一位同事做到了这一点，所以我尝试描述得尽可能好。
我的同事已经做了什么，就是通过读取两个文件并通过PHP回显它们，来告诉标头两个文件连续出现。 HTTP / 1.1 206部分内容用于传递“合并的”内容。
问题是，两个文件中仍然有两个ID3标签，并且大多数音频播放器仅读取第一个，这会显示错误的持续时间。下载全部内容后，在VLC中唯一可行的情况是100％。没有网络播放器，没有iTunes等都可以管理“合并”文件的持续时间。
有没有想法如何实时创建“虚拟ID3标签”以及如何在不接触原始文件的情况下删除现有的ID3标签？
答案 0 :(得分：0)
您得出的结论有很多不正确，所以让我从更正这些结论开始，这可能会帮助您解决问题。
因为ffmpeg＆Co.花了太多时间
FFmpeg合并这些音频流的速度肯定比将其传输到客户端的速度快。如果您使用的是-codec copy（在这种情况下应该使用），它将为您处理所有的解复用/复用。而且，请记住，您可以直接从FFmpeg流式传输。不需要中间文件。
实际情况是将预播添加到播客文件中。
您想要的是FFmpeg路线。
我的同事已经做了什么，就是通过读取两个文件并通过PHP回显它们，来告诉标头两个文件连续出现。 HTTP / 1.1 206部分内容用于传递“合并的”内容。
这有点奇怪。相反，您可以只合并数据并直接在单个响应中发送它。
问题在于，两个文件中仍然有两个ID3标签，并且大多数音频播放器仅读取第一个，这会显示错误的持续时间。
否，通常的ID3标签不表示持续时间。 （有一个扩展名可以使用，但是很少使用。）裸MP3流中也没有任何内容指示持续时间。客户端根据文件大小和比特率进行估算。比特率可以在中游时改变，因此通常会根据前几个帧的比特率进行估算。
毫无疑问，您遇到的问题是由于您处理此合并的方式而导致的长度报头不正确，和/或比特率不匹配，导致播放器的长度估计错误。
有没有想法如何实时创建“虚拟ID3标签”以及如何在不接触原始文件的情况下删除现有的ID3标签？
我绝对会使用FFmpeg进行这项工作。如果有的话，因为并非所有播客都使用MP3。 MP4播客中有很多AAC，WebM中也有少量Opus。