同一个 MP3，系统自带播放器显示 3 分 42 秒，剪辑软件读出来 3 分 45 秒，浏览器里拖到最后发现进度条还剩一小截却已经没声音了。文件没动过，MD5 一模一样，三个程序给出三个答案。你按 3 分 42 秒去对字幕、去切片，结果整段后移了两秒多。
很多人以为时长是文件里写好的一个数字，其实不是
这里有个几乎人人都有的误解：以为音频文件头部有一个"总时长"字段，播放器打开读一下就完了，读出不同值只能是某个程序有 bug。
实际上，绝大多数有损音频格式根本不存储时长 。MP3 的设计目标是流式传输------要支持从广播流里任意位置切进来就能播，所以格式本身是一串可独立解码的帧（Frame）连续排列，没有全局文件头，也没有"我一共多长"的声明。时长是播放器推算出来的结果。既然是推算，不同实现用不同策略，给出不同答案就是必然的。
WAV 很少出现这个问题，是因为它的 `data` 块头部明确写了字节数，除以字节率就是精确时长。而 MP3、AAC(ADTS)、部分 OGG 流都属于"自己数"的阵营。
底层原理：时长是拿总量除以速率算出来的
播放器算 MP3 时长最常见的三种策略，精度依次递增：
第一种，整文件估算：`时长 = (文件字节数 - 标签字节数) × 8 / 码率`。快，O(1)，但依赖"码率恒定"这个前提。
第二种，读 Xing/VBRI 头：如果编码器在第一帧里写了帧总数，那么 `时长 = 帧数 × 每帧采样数 / 采样率`。MPEG-1 Layer III 每帧固定 1152 个采样点，44.1kHz 下每帧 26.12ms，这个算法精度可以到毫秒级。
第三种，全文件扫帧：从头到尾解析每一个帧头，数出真实帧数。最准，但对一个 100MB 的文件意味着几百毫秒到几秒的 I/O，播放器为了秒开通常不这么干。
细节一：帧头解析------播放器从第几个字节开始数
MP3 帧头是 4 个字节，以 11 个 bit 的同步字 `0xFFE` 开头，后面依次是 MPEG 版本、Layer、CRC 标志、码率索引、采样率索引、声道模式。播放器要做的第一件事是"找同步字"。
问题出在文件开头往往不是音频数据。ID3v2 标签挂在最前面，里面可能塞着几百 KB 的专辑封面；有些下载来的文件前面还带着垃圾字节。播放器如果不解析 ID3v2 的长度字段（第 6-9 字节，注意是 syncsafe 编码，每字节只用 7 位），就只能扫同步字硬找。而封面 JPEG 的二进制里出现 `0xFF 0xE0` 这种字节组合的概率相当高------于是把封面中间某个位置误判为第一帧，从这里开始按码率估算，时长自然偏了。
反过来，文件尾部的 ID3v1 标签固定 128 字节、APE 标签更长，不减掉这部分估算值也会偏大。一个 128kbps 文件多算 300KB 标签就等于虚增约 19 秒。
细节二：VBR 与 Xing 头------缺了它播放器只能猜
变码率（VBR）文件里，安静段可能只用 32kbps，密集段飙到 320kbps。此时"码率"这个概念只对单帧成立，整体只有平均码率。
编码器本该在第一个（静音）帧里写入 Xing 头（LAME、ffmpeg 默认写）或 VBRI 头（Fraunhofer 编码器用），内容包括帧总数、文件字节数、100 点 TOC 查找表。有它，时长和 seek 都准确。但这个头很容易丢：
• 用 `cat a.mp3 b.mp3 > c.mp3` 字节拼接，第二个文件的头被当成音频数据，总帧数字段仍是 a 的
• 某些"无损剪切"工具切掉开头几帧后没重写 Xing 头
• 转码链路中间某一环用了不写 Xing 头的老编码器
一旦 Xing 头缺失，播放器退回策略一：拿第一帧读到的码率当全文件码率。假设文件平均码率 160kbps，而恰好第一帧是安静段的 96kbps，估算时长就会被放大到实际的 1.67 倍------这就是"进度条走到 60% 就没声了"的典型成因。
细节三：索引与 seek------为什么拖动一次时长就变了
第三个细节是很多人观察到但没往这个方向想的：时长数字在你拖动进度条之后变了。
原因是不少播放器采用两阶段策略：打开时用估算值让 UI 立刻有个数，后台再慢慢扫帧或者在你 seek 时顺便修正。当用户拖到接近末尾，播放器发现真实数据早就结束了，就把时长改写为实测值------表现出来就是"时长自己跳了一下"。
带 TOC 表的 VBR 文件，seek 按 100 个百分位插值定位------一个 60 分钟的播客每点间隔 36 秒，插值误差在秒级完全正常。没有 TOC 的 VBR 文件更糟，播放器只能按字节比例线性跳转，落点和目标时间能差出十几秒。M4A/MP4 是另一套逻辑：`stts`/`stsz` 表精确记录每个采样的时长与大小，`moov` 盒子若因下载不完整而缺失，文件会直接打不开而不是时长不准。
顺带一提：裁剪 VBR 文件为什么更容易错位
按时间点切片时，这套索引机制会放大误差：切点落在最近帧边界上的偏差最多半帧（约 13ms），可忽略；但工具若依赖不准确的 TOC 插值，偏差就是秒级。稳妥做法是先统一成 CBR 再切，或者用支持在线音频分段的工具在波形上按可视位置对齐，而不是盲输时间码。
能力边界：重封装能修什么，修不了什么
必须说清楚做不到的部分，否则容易误判：
能修：Xing/VBRI 头缺失、标签污染导致的起始帧误判、TOC 表不准、容器层时间戳（PTS）跳变。这些都是索引层问题，音频帧本身完好。
修不了：帧数据本身损坏或缺失。下载中断丢了中间 200KB，那 200KB 的声音不存在了，任何工具都只能选择跳过或用静音填补，时长会因此永久性短于原始素材。
修不了：MP4 的 `moov` 盒子丢失时的完整恢复。理论上可靠扫描 `mdat` 重建索引，但采样时长表是估算的，音画同步会有偏移。
也修不了："让时长变准顺便让音质变好"。索引修复和音质是两件事，帧里是什么就还是什么。
收尾：时长不是事实，是一次计算
三个程序给出三个答案，没有谁在撒谎，它们只是用不同精度的算法回答同一个问题。真正该改变的认知是：面对流式设计的格式，任何"看起来像属性"的数字，都可能是一次现场计算的结果。码率、声道数乃至采样率同理，都可能是从某一帧头推断的。要严谨对齐就别信 UI 上那个数，去拿全量解析的实测值------多花几百毫秒扫一遍文件，比事后返工重切一整期节目便宜得多。