一个样本准确的音乐循环仍然可能听起来像断裂的。以下是三个可以修复它的传递模式。-墙外贴吧

对于游戏音乐，存在两个不同的缝合问题，仅仅解决其中一个问题仍然可能使循环听起来像断裂。

第一个是时间。从Update、Step或_process中polling一个playhead将一个音频事件绑定到游戏帧率。在60FPS下，许多音频样本可以在检查之间通过。使用引擎的本机循环区域，导入循环元数据或可用的音频时钟调度。

第二个是 连续性。即使跳转发生在精确的样本上，最后的和弦仍然可能在循环边界之后响起。一个正常的单声跳转会在新开始时丢弃衰落。你的耳朵会听到缺失的尾部作为一个断裂。

有三个实用交付模式：

干边界。编写或渲染循环，使重要的东西不超过结束。这很简单也很坚固，但可能会限制布局和效果。
折叠尾。渲染超过结束，混合衰落在开始下，然后导出一个自包含重复文件。这在简单的单声玩家中很有效。 tradeoff 是第一过的开始有一个从从未发生的过的尾部。
两声。在循环边界开始下一过的同时，保持上一个声的尾部播放。这保留自然衰落，但需要样本精确的调度和在运行时的声控清理。

交付还需要匹配引擎。例如：

风险的部分不是任何单个步骤。它是保持每个步骤同步。手动过可以意味着计算样本位置，裁剪身体，渲染尾部，将其折叠到头部，重新打开结果以听审循环缝合，转换标记为引擎期望的单位，编写实现说明。移动一个边界，几个输出可能会过时。

这个工作流程就是为什么我建立了 Loopsmith。它保留一个循环定义，精确的标记编辑，缝合听审，尾部处理和引擎交付说明一起。它可以准备一个标记的循环，折叠尾部文件或两声配方从同一来源。

全盘披露：我建立并销售Loopsmith。我在这篇文章中省略了产品链接，因为这篇文章是技术参考。这些技术中没有一个需要我的工具。相比手动执行的价值是可重复性：当音乐或标记发生变化时，听审，导出和实现说明仍然基于相同的循环定义。

在生产中，人们如何处理这个问题？您是否喜欢自包含文件，还是在运行时代码中保留尾部重叠？

一个样本准确的音乐循环仍然可能听起来像断裂的。以下是三个可以修复它的传递模式。