为什么剥离元数据会使 MP3 文件的持续时间减少 0.03 秒？

Question

我有一个文件 input.mp3，在其上运行 ffprobe 会给出以下结果：

[mp3 @ 0x559431400a00] Estimating duration from bitrate, this may be inaccurate
Input #0, mp3, from '../backup/1.mp3':
  Metadata:
    album           : DW01-The Colour Of Magic
    artist          : Terry Pratchett
    album_artist    : Terry Pratchett
    comment         : Read By Nigel Planer
    composer        : Nigel Planer
    genre           : Discworld
    publisher       : Polygram
    title           : Colour Of Magic 1 of 6
    track           : 1
    date            : 1983
    id3v2_priv.WM/Provider: A\x00M\x00G\x00\x00\x00
    id3v2_priv.WM/WMCollectionGroupID: \xe4\xbba\xf0\xf2\xcd.D\xab\x92b\xeb{\x8b\x9a\xce
    id3v2_priv.WM/WMCollectionID: \xe4\xbba\xf0\xf2\xcd.D\xab\x92b\xeb{\x8b\x9a\xce
    id3v2_priv.WM/UniqueFileIdentifier: A\x00M\x00G\x00a\x00_\x00i\x00d\x00=\x00R\x00 \x00 \x00 \x002\x007\x007\x008\x004\x003\x00;\x00A\x00M\x00G\x00p\x00_\x00i\x00d\x00=\x00P\x00 \x00 \x00 \x00 \x00 \x00 \x003\x003\x007\x00;\x00A\x00M\x00G\x00t\x00_\x00i\x00d\x00=\x00T\x00 \x00 \x001\x005\x00
    id3v2_priv.WM/WMContentID: h\x86H@^\xe6qF\x95T\x04m\x01P\x90\x7f
    id3v2_priv.WM/MediaClassSecondaryID: \x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00
    id3v2_priv.WM/MediaClassPrimaryID: \xbc}`\xd1#\xe3\xe2K\x86\xa1H\xa4*(D\x1e
    id3v2_priv.ZuneCollectionID: \x1d\xcb\xdf\xf3X89D\x81\xd1\xd0s#P\x00\xf8
  Duration: 01:08:19.30, start: 0.000000, bitrate: 32 kb/s
    Stream #0:0: Audio: mp3, 44100 Hz, stereo, fltp, 32 kb/s
    Stream #0:1: Video: mjpeg (Baseline), yuvj420p(pc, bt470bg/unknown/unknown), 274x417, 90k tbr, 90k tbn, 90k tbc (attached pic)
    Metadata:
      comment         : Cover (front)

我想对该文件执行多种操作，例如将其与其他文件连接，然后将其分割成小段。但现在，我只考虑删除元数据的简单情况，因为这本身会产生与我在其他操作中遇到的问题类似的问题。当我对上述文件运行以下命令时：

ffmpeg -i input.mp3 -map 0:a -c:a copy -map_metadata -1 output.mp3

然后我在 output.mp3 上运行 ffprobe

Input #0, mp3, from 'output.mp3':
  Metadata:
    encoder         : Lavf58.29.100
  Duration: 01:08:19.27, start: 0.011995, bitrate: 32 kb/s
    Stream #0:0: Audio: mp3, 44100 Hz, stereo, fltp, 32 kb/s
    Metadata:
      encoder         : Lavf

为什么持续时间减少了0.03秒？为什么开始时间不再是0？另外，为什么当我在 vlc 中打开这个文件时，似乎无法计算出持续时间？有了原始文件，它立刻就知道了时长。但对于新文件，它似乎在尝试估计它，随着我播放它的时间的推移，它慢慢地接近。

vlc 中的编解码器信息（两个文件相同）

Stream 0
    Codec: MPEG Audio layer 1/2 (mpga)
    Type: Audio
    Channels: Stereo
    Sample rate: 44100 Hz
    Bits per sample: 32
    Bitrate: 32 kb/s

Answer 1

MP3 文件不具有与 MP4 或 MKV 文件相同的内部结构 \xe2\x80\x93 “普通”MP3 只是一系列原始的音频帧，并且不会将其持续时间存储在任何地方。对于恒定比特率 MP3 文件，持续时间可以根据文件的长度来计算，而对于 VBR，则只能通过逐帧评估整个文件来确定。

\n

也就是说，除非编码器将持续时间和 VBR 信息存储在“ LAME INFO 标签”（又名“Xing VBR 标签”）中。现在几乎所有编码器和播放器都支持此标签，并且大多数 MP3 文件都有它。

\n

从 ffprobe 输出看来，您的原始文件没有这样的标签，而新文件有（“encoder: Lavf”是其中的一部分，由 FFmpeg 添加）。所以我期望相反的结果 \xe2\x80\x93 新文件的持续时间应该是已知的，但原始 \xe2\x80\x93 的持续时间应该不知道，也就是说，除非 FFmpeg 添加了不准确的信息。

\n\n

事实上，普通 MP3 文件甚至不为元数据保留任何空间 \xe2\x80\x93 Xing 和 ID3 标签实际上伪装成大多数解码器都知道忽略 \xe2\x80\x93 的特殊音频帧，这也意味着MP3 文件的估计持续时间可能取决于它包含或曾经包含多少元数据。如果文件中存在删除 ID3v2 标记后留下的漏洞，则简单的估计（例如“size\xc3\xb7bitrate”）将是错误的。

\n

您可以使用Mp3Diags查看文件的结构。（它还可以用于修复不准确的 Xing 标签，这些标签会让玩家认为轨道比实际长度更长或更短。）

\n