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