MIDI 鼓型导出后为什么变声、变速或合并轨道？跨 DAW 回导测试

先定交付边界：SMF 是事件容器，不是鼓声音频或 DAW 工程

MIDI Association 对 Standard MIDI File 的定位是：在软件之间交换带时间戳的 MIDI 数据。SMF 可以容纳一个或多个 MIDI 流，并支持速度、拍号、轨道名称等结构；但 MIDI 文件不必存储真实声音，而是让接收端的声音引擎按事件生成声音。因此，Note 36 在两台机器上都存在，只证明两边看到了同一个音符编号，不证明它们加载了同一个 Kick 采样、相同力度层、Round-robin、包络、效果或总线。

这也解释了三个常见误会。“变声”往往是目标端换了声音引擎或映射；“合并轨道”可能只是收到 Format 0；“变速”则需要继续区分文件里的 tempo meta event、目标端的导入方式，以及鼓型本身的音乐位置是否改变。不要用一种修复同时改三层。

N0 · 在导出前冻结原生基线、事件账本与音频参考

N0 回答“源工程此刻到底是什么”。如果只保留导出的 .mid，导入后看到差异时就没有独立参照：不知道原来的 ghost note 是力度 38 还是 58，不知道第 4 小节是否有拍号变化，也不知道军鼓变 Tom 是事件编号改变还是目标音源映射不同。

1. 另存不可改基线：复制源工程并写明 DAW、版本、日期、工程速度模式和导出范围；后续物化与接合只在工作副本进行。
2. 选一个诊断段：至少覆盖核心 Kick、Snare、闭／开 Hat、一次同时击打、一个弱击、一个小节边界；若工程有速度或拍号变化，范围必须跨过其中一次变化。
3. 导出音频参考：从同一起点生成一份无损立体声参考，保留源音源和处理。它用于确认“原来听起来怎样”，但不拿来证明 MIDI 事件正确。
4. 保存原生 MIDI 副本：保留未接合、未永久量化、未转写宿主参数的版本；N0 必须能回退，M1 才能解释每次转换。
5. 填事件账本：记录每个声部的数字音符编号、通道、事件数、首末起音、最小／最大力度、Note Off 或长度、关键 CC／Program，以及速度／拍号事件位置。

账本应优先写数字音符编号，不只写 C1、C2。不同软件可能用不同八度标签显示同一数字音符；这属于界面命名差异，不应被误记为移调。若源工程已经无法稳定复播，或每次播放会随机生成不同 MIDI，请先固定可复现的事件版本，再进入 M1。

M1 · 把必要的宿主播放状态变成实际 MIDI 事件

许多 DAW 参数在播放时会改变结果，却未必已经是片段里的 Note、CC、Bank 或 Program 事件。Apple 要求 Logic Pro 导出前永久应用 MIDI 片段参数和量化、把替身转为拷贝、把循环转成片段、按轨道接合，并把乐器 MIDI 设置插入为事件。Steinberg 说明 Cubase 的 MIDI Inspector 参数会实时影响播放；其 MIDI 导出只按 Export Options 写入指定设置，其他差异需要用 Merge MIDI in Loop 转成真实 MIDI 事件。M1 的目标不是“把所有东西烘焙”，而是只把接收端必须重现的变化物化，并保留 N0 以便回退。

物化会改变编辑状态，因此一定在副本执行。若某个宿主专有处理无法可靠转换成标准 Note／CC／Program 等事件，就把它列为 X1 例外，并同时交付 N0 音频参考；不要用“听起来像”冒充文件确实携带了该处理。

X1 · 先写 SMF Format 0/1 合同，再发送文件

Format 0 与 Format 1 都是 Standard MIDI File。Apple 的说明很直接：Format 0 把所有数据放在一条轨道里；Format 1 可以包含多条各自独立的数据轨。Ableton 的说明进一步指出，SMF0 的数据只靠 MIDI 通道区分，导入 Live 后会显示在一条轨道；SMF1 可在不同轨道呈现。于是，“导入后轨道合并”可能完全符合所选格式，并不等于 Note 事件消失。

结构示意：真实文件是否按通道或轨道分开，取决于发送端事件和导出实现。Format 1 保留多轨容器也不保证轨道内的音色、插件或路由会一并转移。

X1 不能只写“这是 MIDI”。至少声明以下字段，让接收端知道怎样判定成功：

1. 文件身份：文件名、导出时间、大小，以及可选的校验摘要；若重导，改版本名，不覆盖唯一通过版。
2. 格式与分辨率：SMF0 或 SMF1、PPQ、源 DAW 与版本。若来自 Live，明确写 SMF0 / 96 PPQ，不要暗示它保留源多轨。
3. 音乐范围：第一小节／拍点、总小节数、是否有 pickup、速度与拍号事件位置；说明目标端应该导入 tempo map 还是保留自身速度。
4. 轨道与通道：预期轨道数、每轨名称、MIDI 通道和事件数。Format 0 仍要列通道与鼓件，方便目标端再拆分。
5. 映射合同：数字音符编号到鼓件角色的表，以及 CC、Bank／Program 的预期含义；GM 或 GM 派生映射只写成兼容起点，不写成声音身份保证。
6. 声音后备：N0 音频参考、所用音源／kit 的文字说明，以及哪些宿主专有处理没有进入 SMF。

General MIDI 的价值是为兼容设备定义一组最低能力与常见映射，但它不携带原采样的波形或插件 preset。Ableton 也明确说明 Live 不会按 GM 自动分配声音。MIDI Association 的 Default Drum Note Map Profile 则把特定鼓类映射到音符编号；只有双方实际支持并启用相应约定时，它才构成明确的语义合同。对普通跨 DAW 文件，最稳妥的做法仍是附上自己的数字音符表，并在 V1 中逐项验证。

V1 · 在目标 DAW 的空工程回导：先看事件，再选声音

V1 必须在没有源工程路由和预加载鼓架的空工程里进行。这样可以区分“SMF 自己带来的数据”和“目标模板碰巧补上的设置”。第一次回导先不要为了好听而移动音符、量化或改 Tempo；任何自动导入选项都写进记录卡。

1. 建立空工程：记录目标 DAW、版本、初始 BPM／拍号和 MIDI 导入偏好；不要从发送端模板或已有鼓工程开始。
2. 只导入一次：选择是“打开为新项目”还是“导入当前工程”，并写清是否接受文件里的 Tempo／Meter。若软件询问导入选项，先截图或抄录再选择。
3. 先查结构：在没有修改前记录实际轨道数、每轨通道、事件数、首末起音与文件总长度。SMF0 成为一轨时，继续核对通道和 Note，不立即判失败。
4. 再查时间：核对 Tempo／Meter 事件位置、pickup、第一拍和小节边界；用事件列表或 piano roll 比较 M1，而不只看目标工程顶部显示的一个 BPM 数字。
5. 再查表达：比较数字音符、力度、Note Off／长度、CC、Bank／Program。若源数据超出目标端支持范围，把它记为接收能力差异，不偷偷删除。
6. 最后分配测试音源：先用已知映射的简洁鼓组逐声部试听，再按 X1 重建目标 kit。声音不同但事件一致时，结论应是“事件通过、音源未同一”，不是 MIDI 节奏失败。
7. 用未改原文件重复：把同一个 X1 文件再次导入第二个空工程，或交给实际接收端复测；确认通过不依赖第一个 V1 工程里临时保存的映射、拆轨或修复。

第一处差异在哪一层，就修哪一层

以下任一情况都应停止放行：N0 没有可复现的源基线；M1 同时做了量化、移调和映射却没有逐步账本；不知道文件是 Format 0 还是 1；只靠轨道名猜通道；目标端为了“听起来正确”先移动了音符；把 GM 当成原采样身份；或 V1 只能证明文件能发声，不能证明 Note、Tempo、Meter 与结构对应。停止不等于文件无用，只表示它还没有达到已声明的跨 DAW 合同。

MIDI 鼓型跨 DAW 导出常见问题

Format 0 会把所有鼓音符变成同一个声音吗？

不会必然如此。Format 0 把数据放在一条轨道中，但不同 MIDI 通道和不同数字音符仍可存在。变成一个声音通常还涉及目标端的音源或映射。先核对 Note 与通道，再决定是否需要拆轨。

Format 1 是否一定保留源工程的所有鼓轨？

它支持多轨数据，但不会保存 DAW 的全部轨道类型、文件夹、插件链、路由或专有设备。还要看发送端选择了哪些片段和导出选项。用 X1 的“预期轨道／通道／事件数”验收，不以格式名称单独放行。

为什么 Live 导出的 MIDI 微时序和原 Clip 不完全一样？

Ableton 官方说明 Live 以 96 PPQ 导出，并把 MIDI 事件移到该网格，因此比这个网格更细的原位置可能改变。把这个限制写进 X1，并用导出后回读坐标判断是否在任务可接受范围；不要虚构一个通用毫秒容差。

只交一个 MIDI 文件，能让对方听到同一套鼓吗？

不能保证。MIDI 文件不存储原采样音频；即使有 Bank／Program 或 GM 映射，接收端的声音引擎、kit、力度层、包络和效果仍可能不同。若声音身份重要，同时交付 N0 音频参考与合法的音源／kit 说明。

GM 鼓映射是不是跨软件的万能标准？

不是。GM 提供有用的兼容基线，但并非所有软件都会自动按 GM 分配声音，自定义鼓架也可以使用其他映射。MIDI Association 的默认鼓音符 Profile 需要双方支持并启用才形成明确约定。X1 仍应列数字音符到鼓件角色的实际表。

跨 DAW 后速度不对，是否应该把所有音符整体拉伸？

先不要。先看文件是否含正确 Tempo／Meter、目标端是否导入了速度图、起点是否插在同一音乐位置。只有证明事件相对网格本身确实缩放错误，才在副本中修音符；否则会把导入策略问题写死进数据。

为什么本文还要音频参考？这不是 MIDI 测试吗？

音频参考提供“源工程实际听起来怎样”的独立证据，能区分事件通过但音源不同，以及事件本身已经改变。它不是拿来替代事件账本，也不意味着 MIDI 文件包含音频。

这和工程移交、MIDI 映射或 Swing 参数迁移有什么区别？

工程移交保留的是完整宿主项目与依赖；Note 映射排查关注控制器到音源的单次地址；Swing 审计比较不同设备的时序语义。本文只验证 Standard MIDI File 是否把已物化的事件、时间与结构按合同送进另一个空工程，范围更窄。