同一MKV导出时选错音轨，怎样分清-map 0:2与0:a:1

-map 0:2选择第一个输入中的绝对流索引二，-map 0:a:1选择其中第二条音频流，二者只有在特定流排列下才指向同一对象。不能把媒体类型内部序号当作整份容器的绝对编号，也不能从播放器菜单顺序猜测命令索引。

这组文件怎样比较

本例故意按音频、视频、音频顺序生成MKV，两个声音分别为原创合成音。绝对索引二与第二音轨在此文件中相同，但第一条视频的绝对索引是一。样例排除了常见的“视频总是零号流”假设，用真实流列表展示身份。

按原始结构逐项检查

1. 先运行show_streams保存index、codec_type和codec_name，再按文件内顺序列出。所有索引从零开始计，第二条音频的类型序号为一，不是二；建立清单时应把“第几条”的自然语言和命令数字并列，减少人工转写错误。

2. 分别用绝对索引与类型序号导出MKA，显式指定流复制。检查每份输出只有一条音频流，再将它解码为PCM并计算内容摘要。输出流会重新从零编号，因此不能因为结果index变成零就认定选错了输入，必须按映射关系追踪。

3. 比较两条导出音频的解码摘要相同，证明本例两种选法指向相同声音内容。原文件仍完整解码，避免只验证导出短文件却漏掉源片结构问题；文件SHA与PCM摘要用途不同，容器标签变化也可能导致前者不同。

容易误读的地方

反例是把0:1当成所有文件的第二音轨。当输入顺序变化或增加封面、字幕时，它可能变成视频或第一音轨。对于批处理，应先探测并按明确条件选流，不要从上一份文件记住一个整数就无条件用于下一份。

下载与本地读回

absolute.mka、by-type.mka、generation.json、mixed-order.mkv、observed.csv、observed.json。

下载全部附件到同一个独立目录，用 python verify.py 运行本题独立核验脚本。依赖为Python 3.12.4、PATH中的FFmpeg及ffprobe 8.0.1；程序不联网、不连接设备，读取本题文件并在终端输出检查结果。本地实际执行回执保存实际命令、退出码和完整输出。

公开核验实际读到音频、视频、音频三种排列，两份导出均为单音轨且PCM摘要一致。这里没有做声道下混或音频路由，也没有判断合成音的语言；它只证明文件身份和映射结果能被本地复核。

命令已在原创短片上实际执行并读回文件。官方文档为滚动版本，本文所列选项已用本地8.0.1确认；未测试目标硬解、网络起播或现场实时性能。

把结果带回交付

交接表至少保存输入文件摘要、输入绝对索引、类型序号及输出索引。若换了制作版本，应重新探测；同名文件不保证流顺序不变。把map参数和读回列表一起交给接收方，比只写“已删多余音轨”更能解释留下的是哪一条。

相关背景见展厅视频编码与封装怎么选（H.264 / H.265 / HAP），还可从多媒体播放专题继续查找文件处理方法。需要核对实际工程的接收条件时，可携带本题文件与读回结果进行工程对接咨询。

一级依据

• 流说明符可按绝对索引或媒体类型内序号匹配，-map指定输入流到输出。

来源核对日期：2026-10-24。引用支持文件机制；原创输入的本地结果不代表客户素材或现场系统已经通过验收。