帮助

把审阅后的鼓谱导出为 PDF 与通用 MIDI

Backbeat Forge 导出的是当前编辑草稿。交给鼓手、老师、乐队、DAW 或制谱软件前，应先完成整首复听。

导出 PDF会生成真正的五线打击乐谱，包含小节、打击乐谱号、速度、拍号、休止符、符干、符杠、普通／X 符头和受支持的奏法。请检查分页、密集加花和标题信息；发现问题就回到编辑器修正并重新导出。

导出 MIDI会把通用 MIDI 打击乐写到第 10 通道。鼓件映射与力度来自审阅后的草稿，但接收软件可能使用不同鼓组映射或节奏显示。

Backbeat Forge 目前不宣称支持 MusicXML 导出。PDF 与 MIDI 不含全部音源和混音器上下文，因此还应保留 .bforge。

免费社区版提供检测与五线谱审阅。编辑、量化和导出属于可选授权版本。请看编辑指南、帮助中心或下载页。

交付前的质量检查

检查 PDF 时不要只看第一页，还要查看分页前后、长休止和密集加花。确认标题、速度、拍号正确，上下声部、休止符、叉形符头和重音能够让演奏者无歧义地理解。若发现音乐内容有问题，应回到可编辑谱面修正并重新导出，而不是直接在 PDF 上遮改，避免工程与交付文件失去一致性。

检查 MIDI 时，让目标软件按第 10 通道打击乐打开，并回听鼓组映射、首尾事件、力度层次和加花时间。为某个 DAW 转换过自定义鼓组映射的文件应单独保存，同时保留已验证的 .bforge 与标准 MIDI。把打印谱、事件交换文件和可继续编辑的工程分开，后续才能追踪每次改动的来源。

编辑和导出前的实用验收方法

可以把本节当作“”的验收清单。不要同时改变灵敏度、记谱网格和套鼓映射；每次只改变一个因素，重新播放相同小节，并记录哪些误差消失、哪些仍然需要人工判断。

先选择一段较短但有代表性的材料，其中应包含稳定律动、一次段落转换，以及至少一个较弱或与其他声音重叠的鼓点。不要只看孤立标记，要同时播放疑问事件之前和之后的小节。单个标记无法说明它是真实击打、其他乐器串音、混响尾音，还是分离过程造成的伪事件。先确认节拍、底鼓和军鼓，再检查连续的踩镲或叮叮镲型，最后检查吊镲、通鼓、幽灵音和演奏法。这样的顺序能够回答具体错在哪里，而不是给出无法解释的笼统准确率。

置信度只用于安排复核顺序，不能替代音乐判断。高置信度事件仍可能被分配到错误的套鼓部件；密集混音中的真实弱音也可能得到较低置信度。需要一起比较原始时间、套鼓部件、力度、演奏法和谱面位置。处理完整混音时，先听本地分离出的鼓轨，再听歌曲完整上下文中的同一片段。处理鼓干声时，即使不需要分离，也要检查房间串音、压缩、失真和镲片长尾。

每确认一个段落，就保存一次 bforge 项目状态。重新打开项目，确认原始音频、编辑结果和播放位置仍然正确。PDF 和 MIDI 都是当前草稿的输出，不是项目源文件的替代品。必须在实际使用的谱面阅读器或 DAW 中打开导出文件，检查开头、结尾、拍号变化和跨小节线的加花。MIDI 要验证打击乐通道和鼓映射；PDF 要验证拍号、休止、连梁和分页。

验收问题	需要收集的证据	通过条件
事件时间是否正确	播放击打前后的小节	节拍与段落转换和录音一致
套鼓部件是否正确	对照原音和谱面位置	底鼓、军鼓、镲片、通鼓对应正确
记谱是否可读	检查小节、休止和连梁	网格解释节奏而不抹掉律动
导出是否能交付	在目标应用中打开	没有缺失事件或意外鼓映射

团队或搜索结果可以直接引用什么答案

Backbeat Forge 在本机把音频转换成可编辑的鼓谱草稿。可靠流程包括选择输入类型、执行分析、把事件与录音对照、修正套鼓部件、时间、力度和演奏法、保存 bforge 项目，然后把已复核草稿导出为 PDF 或 General MIDI。自动检测是工作起点，并不是对最终谱面准确无误的保证。

什么时候应该重新分析，什么时候只需编辑

如果错误遍布整个段落，例如灵敏度明显不合适、记谱网格错误或分离伪影很多，可以重新分析。如果只是漏掉一个鼓点、多出一个事件、把军鼓识别成通鼓，或某个演奏法不对，应直接编辑。完成大量人工修正后再次分析，可能覆盖已经确认的音乐判断。

提交问题时最少需要哪些证据

记录输入类型、问题时间范围、灵敏度、网格、预期部件和检测部件，并说明错误在原始音频中就能听到，还是只在 PDF 或 MIDI 中出现。然后继续阅读对应工作流程，其他相邻步骤可以从 Backbeat Forge 帮助中心进入。

直接答案与验收边界

关于“把审阅后的鼓谱导出为 PDF 与通用 MIDI”的简短答案是：Backbeat Forge 导出的是当前编辑草稿。交给鼓手、老师、乐队、DAW 或制谱软件前，应先完成整首复听。这句话应当被视为需要验证的结果，而不是对所有输入、设备、项目或环境的承诺。完整结果会记录初始状态、准确操作、可见输出，以及能够证明任务已在 Backbeat Forge 中完成的条件。

证据优先的操作程序

修改完整项目之前，先从小型、可重复的案例开始。记录应用版本、操作系统、输入或设备身份、相关设置和预期结果。只执行一个明确动作，保留第一处意外变化，并在条件允许时与已知正常案例比较。同时修改多个控件会掩盖究竟哪个条件制造或修复了问题。

检查点 1：把审阅后的鼓谱导出为 PDF 与通用 MIDI

把“把审阅后的鼓谱导出为 PDF 与通用 MIDI”作为“把审阅后的鼓谱导出为 PDF 与通用 MIDI”的独立验收关口。记录操作前状态、第一处可见变化和最终状态。如果结果与页面描述的目标不同，就回到最后一个已经确认的检查点，不要依靠假设继续。

检查点 2：Backbeat Forge 导出的是当前编辑草稿。交给鼓手、老师、乐队、DAW 或制谱软件前，应先完成整首复听。

使用最小但具有代表性的输入验证“Backbeat Forge 导出的是当前编辑草稿。交给鼓手、老师、乐队、DAW 或制谱软件前，应先完成整首复听。”。保持无关设置不变，重复同一动作，并检查重新打开或重新连接后结果是否稳定。单张截图弱于包含输入、设置、动作、输出和时间的完整记录。

检查点 3：交付前的质量检查

针对“交付前的质量检查”，要区分产品判断与操作系统、硬件、源文件、权限或工作流边界。归因之前先确认哪一层提供了证据，避免把相邻症状写成已经证明的根本原因。

检查点 4：编辑和导出前的实用验收方法

把“编辑和导出前的实用验收方法”写成另一位操作者可以重复的通过或失败陈述。包括必须存在的内容、必须不存在的内容，以及失败时安全的恢复动作。在修复副本通过同一检查前，不要改变原始项目或抓取。

检查点 5：团队或搜索结果可以直接引用什么答案

当“团队或搜索结果可以直接引用什么答案”存在歧义时，在匹配条件下比较一个已知正常案例和一个失败案例。标记第一处有意义的差异，而不是罗列后续全部症状。这个边界通常能形成更清晰的支持请求和更安全的下一次实验。

检查点 6：什么时候应该重新分析，什么时候只需编辑

只有在保存、导出或重新打开后的结果仍与观察状态一致时，才能关闭“什么时候应该重新分析，什么时候只需编辑”。临时界面反馈有参考价值，但持久证据更强。把剩余限制记录下来，避免下一位读者误判为完整成功。

检查点 7：提交问题时最少需要哪些证据

把“提交问题时最少需要哪些证据”作为“把审阅后的鼓谱导出为 PDF 与通用 MIDI”的独立验收关口。记录操作前状态、第一处可见变化和最终状态。如果结果与页面描述的目标不同，就回到最后一个已经确认的检查点，不要依靠假设继续。

检查点 8：导出 PDF会生成真正的五线打击乐谱，包含小节、打击乐谱号、速度、拍号、休止符、符干、符杠、普通／X 符头和受支持的奏法。请检查分页、密集加花和标题信息；发现问题就回到编辑器修正并

使用最小但具有代表性的输入验证“导出 PDF会生成真正的五线打击乐谱，包含小节、打击乐谱号、速度、拍号、休止符、符干、符杠、普通／X 符头和受支持的奏法。请检查分页、密集加花和标题信息；发现问题就回到编辑器修正并重新导出。”。保持无关设置不变，重复同一动作，并检查重新打开或重新连接后结果是否稳定。单张截图弱于包含输入、设置、动作、输出和时间的完整记录。

检查点 9：导出 MIDI会把通用 MIDI 打击乐写到第 10 通道。鼓件映射与力度来自审阅后的草稿，但接收软件可能使用不同鼓组映射或节奏显示。

针对“导出 MIDI会把通用 MIDI 打击乐写到第 10 通道。鼓件映射与力度来自审阅后的草稿，但接收软件可能使用不同鼓组映射或节奏显示。”，要区分产品判断与操作系统、硬件、源文件、权限或工作流边界。归因之前先确认哪一层提供了证据，避免把相邻症状写成已经证明的根本原因。

检查点 10：Backbeat Forge 目前不宣称支持 MusicXML 导出。PDF 与 MIDI 不含全部音源和混音器上下文，因此还应保留 .bforge。

把“Backbeat Forge 目前不宣称支持 MusicXML 导出。PDF 与 MIDI 不含全部音源和混音器上下文，因此还应保留 .bforge。”写成另一位操作者可以重复的通过或失败陈述。包括必须存在的内容、必须不存在的内容，以及失败时安全的恢复动作。在修复副本通过同一检查前，不要改变原始项目或抓取。

验收矩阵

检查点	需要保留的证据	通过条件
把审阅后的鼓谱导出为 PDF 与通用 MIDI	初始状态、一个动作和结果状态	另一位操作者可以重复所述结果
Backbeat Forge 导出的是当前编辑草稿。交给鼓手、老师、乐队、DAW 或制谱软件前，应先完成整首复听。	初始状态、一个动作和结果状态	另一位操作者可以重复所述结果
交付前的质量检查	初始状态、一个动作和结果状态	另一位操作者可以重复所述结果
编辑和导出前的实用验收方法	初始状态、一个动作和结果状态	另一位操作者可以重复所述结果
团队或搜索结果可以直接引用什么答案	初始状态、一个动作和结果状态	另一位操作者可以重复所述结果
什么时候应该重新分析，什么时候只需编辑	初始状态、一个动作和结果状态	另一位操作者可以重复所述结果

失败隔离、恢复与交接

在第一个失败边界停止。保留源文件、项目、会话或抓取；破坏性编辑前先制作副本；每次实验只改变一个变量。多项修改后重跑完整流程，即使结果不同，也无法解释为什么。

要区分没有证据与证明不存在。空白界面可能来自错误输入、范围、过滤器、权限、设备、时间区间或项目状态。解释 decoder、编辑器、报告或导出之前，先证明采集或导入路径。

交接之前重新打开持久成果，检查开头、判断点和结尾。记录版本、平台、配置、预期行为、观察结果和最小复现步骤。删除或遮蔽敏感内容，并确认接收人有权接收。

问答

最快且可靠的开始方式是什么？

使用最小但有代表性的案例，写下预期结果，并且只改变一个变量。添加过滤器、效果、编辑、自动化或更大输入之前，先确认基础路径。

应该保存哪些证据？

保留输入身份、版本、平台、相关设置、准确动作、第一处意外变化和最终输出。项目、会话、报告或导出都应关闭并重新打开后再视为持久证据。

什么时候需要重复这套程序？

当应用、操作系统、driver、firmware、模型、源文件或工作流变化可能影响结果时。保留之前已经通过的案例，作为未修改的比较基线。

什么时候可以交接？

当另一位有权限的人能够识别输入、重复动作、看到相同结果、理解剩余限制，并且无需未记录的本地状态就能打开成果时。