帮助

音频、工程、播放与导出故障排查

先确认失败发生在哪个阶段，并保留原始音频与 .bforge。

音频打不开时，确认是本地 WAV、MP3、FLAC、OGG、M4A 或 AAC。怀疑容器损坏时，可先转一段短 PCM WAV。打击乐 MIDI 应走导入 MIDI。

分离失败时，请重新安装包含 HTDemucs 与 ONNX Runtime 的完整发行包。如果应用警告后直接分析未分离混音，这份草稿需要更严格的复听。

谱面为空：逐步提高灵敏度，或换用鼓分轨。误检太多：降低灵敏度，并检查贝斯、吉他、节拍器与母带限幅造成的瞬态。

没有声音：检查系统输出、总增益、静音和独奏。源文件警告表示录音被移动、删除或更改；鼓谱仍受指纹机制保护。

免费社区版提供检测和审阅；编辑与导出需要可选授权。已有有效授权仍失败时，检查目标目录写入权限。

返回快速上手、工程恢复或下载页。

制作可以重复的问题样本

长歌曲出现失败时，应先保留原文件，再把包含问题的短片段另存为 PCM WAV。使用相同的输入命令、灵敏度和书写网格确认能否复现，并依次检查是否误把完整混音当成鼓分轨、安装包是否包含模型与运行库。一次只改变一个条件，否则即使偶然恢复，也无法知道真正原因。

为了后续排查，记录操作系统、应用版本、输入格式、所选命令、完整警告文字和最短复现步骤。即使音源不能分享，文件时长、采样率、声道数与问题发生位置也有诊断价值。故障期间不要删除原音和 .bforge；同时把导出目录权限、音频解码、分离检测和工程恢复作为不同阶段分别验证。

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

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

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

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

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

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

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

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

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

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

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

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

直接答案与验收边界

关于“音频、工程、播放与导出故障排查”的简短答案是：先确认失败发生在哪个阶段，并保留原始音频与 .bforge。这句话应当被视为需要验证的结果，而不是对所有输入、设备、项目或环境的承诺。完整结果会记录初始状态、准确操作、可见输出，以及能够证明任务已在 Backbeat Forge 中完成的条件。

证据优先的操作程序

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

检查点 1：音频、工程、播放与导出故障排查

把“音频、工程、播放与导出故障排查”作为“音频、工程、播放与导出故障排查”的独立验收关口。记录操作前状态、第一处可见变化和最终状态。如果结果与页面描述的目标不同，就回到最后一个已经确认的检查点，不要依靠假设继续。

检查点 2：先确认失败发生在哪个阶段，并保留原始音频与 .bforge。

使用最小但具有代表性的输入验证“先确认失败发生在哪个阶段，并保留原始音频与 .bforge。”。保持无关设置不变，重复同一动作，并检查重新打开或重新连接后结果是否稳定。单张截图弱于包含输入、设置、动作、输出和时间的完整记录。

检查点 3：制作可以重复的问题样本

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

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

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

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

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

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

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

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

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

检查点 8：音频打不开时，确认是本地 WAV、MP3、FLAC、OGG、M4A 或 AAC。怀疑容器损坏时，可先转一段短 PCM WAV。打击乐 MIDI 应走导入 MIDI。

使用最小但具有代表性的输入验证“音频打不开时，确认是本地 WAV、MP3、FLAC、OGG、M4A 或 AAC。怀疑容器损坏时，可先转一段短 PCM WAV。打击乐 MIDI 应走导入 MIDI。”。保持无关设置不变，重复同一动作，并检查重新打开或重新连接后结果是否稳定。单张截图弱于包含输入、设置、动作、输出和时间的完整记录。

检查点 9：分离失败时，请重新安装包含 HTDemucs 与 ONNX Runtime 的完整发行包。如果应用警告后直接分析未分离混音，这份草稿需要更严格的复听。

针对“分离失败时，请重新安装包含 HTDemucs 与 ONNX Runtime 的完整发行包。如果应用警告后直接分析未分离混音，这份草稿需要更严格的复听。”，要区分产品判断与操作系统、硬件、源文件、权限或工作流边界。归因之前先确认哪一层提供了证据，避免把相邻症状写成已经证明的根本原因。

检查点 10：谱面为空：逐步提高灵敏度，或换用鼓分轨。误检太多：降低灵敏度，并检查贝斯、吉他、节拍器与母带限幅造成的瞬态。

把“谱面为空：逐步提高灵敏度，或换用鼓分轨。误检太多：降低灵敏度，并检查贝斯、吉他、节拍器与母带限幅造成的瞬态。”写成另一位操作者可以重复的通过或失败陈述。包括必须存在的内容、必须不存在的内容，以及失败时安全的恢复动作。在修复副本通过同一检查前，不要改变原始项目或抓取。

验收矩阵

检查点	需要保留的证据	通过条件
音频、工程、播放与导出故障排查	初始状态、一个动作和结果状态	另一位操作者可以重复所述结果
先确认失败发生在哪个阶段，并保留原始音频与 .bforge。	初始状态、一个动作和结果状态	另一位操作者可以重复所述结果
制作可以重复的问题样本	初始状态、一个动作和结果状态	另一位操作者可以重复所述结果
编辑和导出前的实用验收方法	初始状态、一个动作和结果状态	另一位操作者可以重复所述结果
团队或搜索结果可以直接引用什么答案	初始状态、一个动作和结果状态	另一位操作者可以重复所述结果
什么时候应该重新分析，什么时候只需编辑	初始状态、一个动作和结果状态	另一位操作者可以重复所述结果

失败隔离、恢复与交接

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

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

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

问答

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

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

应该保存哪些证据？

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

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

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

什么时候可以交接？

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