我们要做的是将一种MP3预卷实时添加到其他MP3文件中。这意味着我们在服务器上有两个物理MP3文件，它们还没有合并成一个，因为ffmpeg&Co.需要太多时间。它必须是实时的，以便在有人启动(网络)播放器时不会浪费时间。实际案例是将预卷添加到播客文件。我们已经执行的操作(如下所述)有效，除了在音频播放器中显示正确的文件持续时间。
我的一位同事这样做了，所以我试图尽可能好地描述。
我的同事已经做的是通过读取两个文件并通过 PHP 回显它们来告诉标头两个文件正在连续出现。HTTP/1.1 206 部分内容用于传递"合并"内容。
问题是，两个文件中仍然有两个ID3标签，大多数音频播放器只读取第一个标签，这发生在错误的持续时间显示中。它 100% 工作的唯一情况是在下载整个内容后在 VLC 中。没有网络播放器，iTunes等可以管理"合并"文件持续时间。
知道如何实时创建"虚拟ID3标签"以及如何在不接触原始文件的情况下删除现有标签吗？
你得出了很多不准确的结论，所以让我先纠正这些结论，这可能有助于你解决问题。
因为ffmpeg&Co.花费了太多时间
FFmpeg 可以比您流式传输到客户端的速度更快地合并这些音频流。 如果您使用的是-codec copy(在这种情况下您应该使用)，它将为您处理所有解复用/多路复用。 而且，请记住，您可以直接从 FFmpeg 流式传输出去。 不需要中间文件。
实际案例是将预卷添加到播客文件。
FFmpeg 路由是您想要的。
我的同事已经做的是通过读取两个文件并通过 PHP 回显它们来告诉标头两个文件正在连续出现。HTTP/1.1 206 部分内容用于传递"合并"内容。
这是一种有点不稳定的方法。 相反，您可以合并数据并直接在单个响应中发送数据。
问题是，两个文件中仍然有两个ID3标签，大多数音频播放器只读取第一个标签，这发生在错误的持续时间显示中。
不，通常的 ID3 标签不指示持续时间。 (有一个扩展可以这样做，但很少使用。 裸 MP3 流中也没有指示持续时间的内容。 客户端根据文件大小和比特率估计这一点。 比特率可能会在中途更改，因此他们通常根据前几帧的比特率进行估计。
毫无疑问，您在这种情况下的问题是由于您处理此合并的方式而导致的长度标头不正确，和/或比特率不匹配导致播放器的长度估计错误。
知道如何实时创建"虚拟ID3标签"以及如何在不接触原始文件的情况下删除现有标签吗？
我绝对会使用 FFmpeg 来完成这项工作。 如果有的话，因为并非所有播客都使用 MP3。 MP4 播客中有很多 AAC，WebM 中也有一些 Opus。