从一段 47 分钟的直播录像里把音轨提出来，流程很顺：选文件、等进度条走完、导出 MP3。播放器一打开就觉得不对，总时长显示 46:57，比原片少了 3 秒多。拖到尾部，最后一句"今天就到这里"被切掉了半截。可视频播放器里那句话明明完整。
换一个工具再提一次，结果还是短，只是短的长度从 3 秒变成 2.4 秒。这就说明问题不在某一次导出失手，而在"时长"这个概念本身------提取工具算出来的时长，和播放器展示的时长，用的根本不是同一把尺子。
误解：短掉的那几秒，多半不是被"截断"了
最常见的第一反应是工具处理到尾部时崩了，或者缓存没写完，于是反复重导、换格式、换参数。方向上就错了。
提取音轨这件事，在成功的情况下也只是把容器里已有的音频包按顺序搬出来，再重新封装 。除非显式要求重编码，采样点一个都不会被重新计算。也就是说，音频数据本身大概率是完整的，出错的是记录这段数据有多长的元数据 ，以及从哪个时间点开始算。
另一种误判更隐蔽：拿视频播放器的进度条当基准。播放器的显示时长来自容器的 `duration` 字段，那个字段是编码器写进去的估算值，不是逐包累加出来的真值。两个都不可靠的数一相减，差额就出现了。
真正要查的，是容器里的时间基准（time base）、流的起点时间（start time），以及时长到底是按包数算还是按帧数算。
底层原理：时长是"单位数 × 时间基"乘出来的
容器里每个流都有自己的时间基（time base），是一个分数，表示一个时间单位等于多少秒。MP4 里视频流常见 `1/90000`，音频流常见 `1/48000`。每个包的时间戳都是一个整数，单位数乘以时间基才是秒。
时长就是这么来的：
duration_seconds = duration_units × time_base
只要时间基换算不能整除，就必然产生舍入。90kHz 和 44.1kHz 之间没有整数倍关系，48kHz 与 90kHz 的比值是 1600:3，同样不是处处整除。一个包舍掉不到一个单位，误差只有几微秒；但一条 47 分钟、四万多个音频包的轨，误差会沿着时间轴累积，尾部的边界判断再被放大一次，最终呈现出来的就是"短了几秒"。
另一条路径是反推：有些工具不解容器里的 `duration`，而是数"有多少帧、每帧多少采样点"，再除以采样率。这个算法在恒定帧率下没问题，一旦帧率可变，或者末帧是残帧，反推值就和真实时长分道扬镳。
三个偏差源：换算、起点、帧统计
偏差源一：时间基换算的累计舍入
是什么：把 90kHz 时间基下的整数时间戳换算成秒，或者换算成另一个采样率下的采样点序号时，每一次换算都会丢一点点精度。
为什么：90kHz 最早是为视频帧间隔挑的，能同时整除 24/25/30/60 帧，但对 44.1kHz 音频很不友好：44100 与 90000 的最小公倍数是 4,410,000，中间必然出现小数。MP4 的音频轨通常用 `1/48000` 或采样率本身作时间基来规避，但转封装工具若沿用视频时间基给音频打时间戳，舍入就进来了。
怎么应对：优先用 `ffmpeg -c copy` 直接转封装、不重编码，让时间基保持原样；必须在两种时间基之间转换时，只做一次换算，不要"先转成毫秒再转回采样点"这种二次取整。核对时看 `nb_frames × 每帧采样点 / 采样率` 与 `duration` 的差值，超过一帧就说明换算有问题。
偏差源二：流的起点不是 0
是什么：音频流的 `start_time` 常常不是 0。MP4 里 AAC 会带编码器预滚（encoder delay）的 1024 个采样点，约 21ms；有些录像设备的音频比视频晚启动几十毫秒，起点甚至是负数。
为什么：预滚的采样点是编码器的填充数据，解码器要靠它恢复滤波器状态，本身不该被播放。规范做法是在容器里用编辑列表（edit list，`elst`）声明"从第 N 个采样点开始才算正片"。但很多工具不读编辑列表，直接从第一个包开始搬，头部填充被当成正文留下、尾部对齐又被切掉一截。47 分钟里短 3 秒，往往不是一个原因：起点偏移几十毫秒，加尾部按帧对齐丢一到两帧，再加换算误差，叠起来就到秒级。
怎么应对：`ffprobe` 里看 `start_time`，只要不是 0，就该怀疑起点被处理过。需要精确保留时，转封装时打开 `-copyts` 保留原始时间戳，再用 `-ss`/`-to` 显式裁掉预滚段，而不是让工具默认对齐。
偏差源三：可变帧率下的帧数统计
是什么：手机录屏、直播推流、监控回放这类素材，视频帧率是浮动的。按"总帧数 ÷ 平均帧率"算时长，误差随录制时长线性放大。
为什么：可变帧率（VFR）录像在画面静止时可能每秒只写 5 帧，运动时补到 60 帧。容器里的 `avg_frame_rate` 只是平均值，真值要靠每个包的时间戳差分。按平均值反推，静态段落多的素材会被算短。提取音频本身不走视频帧，但若工具拿视频轨时长去截断音频、或填音频轨的元数据，误差就传导过来了。
怎么应对：让音频轨自己说话，不要用视频轨的时长给音频收尾。核对时分别取两条流的 `duration`，差值超过 50ms 就该警觉------那是人耳判断音画不同步的常见阈值。在线视频提取音频，导入本地视频或者短视频后，默认导出提取为mp3，导出音频到本地。
收尾
"短了几秒"这个现象，大部分时候不是工具失手，而是我们把三个不同来源的时间当成了同一个时间：容器声明的、工具换算的、播放器展示的。先把三个数分开摆再动手，比换五个工具重导十遍有效。工具能把搬运做干净，做不了替源文件补上它从未拥有过的那几秒。