我找不到声音效果不是我的问题。互联网已经慷慨地为我埋葬了大约17,000个文件。问题是找到每个接近100个游戏事件的正确一个而不花费余生听impact_07_final_v2.wav。所以我建立了一个本地语义搜索管道，减少了库到一个小批次的候选者。每个声音都用预训练的laion/clap-htsat-unfused CLAP模型进行了索引。它将音频和文本放在同一个512维的向量空间中，所以我可以用平常的英语描述所需的声音，并使用余弦相似度对文件进行排名。没有生成内容，模型也没有重新训练。人工智能只用于根据描述对已有的声音进行排名。对于每个游戏事件，我写了一个简要描述： 该声音代表什么； 该声音应具有的氛围和角色； 该声音的首选持续时间； 该声音在哪里播放； 应避免的概念。最后一部分需要特殊处理。CLAP并不真正理解否定：将“没有警笛”放在主要查询中仍然引入了警笛的概念，并可能将其接近结果。相反，未经允许的概念是单独嵌入的，候选者因匹配它们而受到惩罚。看来即使机器学习也需要被告知“请不要”不是一个邀请。持续时间作为配额而不是硬性过滤器工作。最终结果槽中通常保留了首选范围内的音频文件，而少数槽保留了异常强大的匹配外部的音频文件。在我的当前数据集中，这增加了候选者在请求的持续时间内的百分比，从大约40%增加到73%，而不会隐藏有用的异常值。索引还将WAV、MP3和OGG版本的同一声音的重复版本折叠起来。人类部分发生在一个自包含的本地HTML界面中。对于每个事件，我收到10个候选者，并可以： 播放或循环它们； 通过手机扬声器听一听它们将如何听起来； 按持续时间和是否需要署名进行过滤； 选择相同事件的多个变体； 拒绝一个候选者并立即接收排名最高的下一个结果； 拒绝整个批次，当所有10个都是音频上的诅咒； 将有趣的声音保存到一个通用集合中，当它们不符合当前事件但可能在将来有用时。选择、拒绝和集合在会话之间保持有效。一旦我选择了候选者，这个工具就会将它们通过JSON导出到游戏的音频注册表中。这使我可以导入一个事件的多个变体，在播放时旋转它们，在真实的游戏玩法环境中测试它们，并在以后将它们替换而不需要手动重建所有内容。署名要求始终附着在每个文件上，包括索引、过滤、选择和导出，避免在发布前手动重建所有许可信息。主要的教训是语义相似性并不能代替听力或声音设计判断。它只是在听力开始之前移除了数百个明显错误的文件。对我来说，这节省了大量的时间来重复性地手动搜索。您在自己的项目中如何解决这个问题？当您有数千个声音和大约100个音频槽要填充时，您是否依赖标签、文件夹、自定义工具还是慢慢地失去一个WAV的时间？