OnKey：开源 Mac 唱歌训练器，听一遍就能学会任何歌曲的旋律

OnKey 是什么，以及为什么 Show HN 帖子受到关注

OnKey 是一款免费、开源的 Mac 唱歌训练器，由 Daniel Murrell 创建，它能学习你播放的任何歌曲的旋律，并根据旋律对你的现场演唱进行评分。它提供了卡拉 OK 评分系统中的音高反馈部分，而无需处理任何授权音乐：你自己的音乐应用播放歌曲，OnKey 负责聆听。

项目位于 github.com/dsmurrell/onkey，文档和带声音的演示在 singonkey.app。其 Show HN 帖子获得了 169 分和 72 条评论。README 的标语是：“自 2026 年起，拯救淋浴歌手。”

与音高训练器或卡拉 OK 游戏不同的核心主张是：歌曲不需要由开发者预先编排或编程。OnKey 在您的 Mac 上，通过一次聆听即可自行推导出旋律。

OnKey 如何学习歌曲：在本地运行的四模型流水线

OnKey 没有歌曲数据库。当一首歌曲结束时，它会在用户的 Mac 上为该歌曲构建音符图表，并在以后的每次播放中重复使用。

每首歌曲的流水线包含三个阶段，使用 OnKey 在文档中致谢的模型：

  1. 人声分离。 一个模型将主唱人声从伴奏音乐中分离出来，使用的组件包括 UVR 的 MDX-Net Karaoke 2。
  2. 音高跟踪。 CREPE 在分离出的人声中跟踪歌手音高。
  3. 音符转录。 GAME 音符模型将音高轨迹转换为音符，每个音节生成一个小节。

OnKey 还致谢了 wav2vec 2.0，与 CREPE、GAME 和 UVR 的 MDX-Net Karaoke 2 并列。

在首次播放时，您只能看到歌词。歌曲在播放结束时被学习。在后续播放中，音符条会向播放头滚动，您的实时音高会绘制在它们上面，落在音符上时显示为绿色。OnKey 通过音乐本身而不是存储的偏移量来确定其在歌曲中的位置，并实时跟踪您的声音。

评分在两点上刻意宽容，如 README 所述：低八度演唱也算正确，稍微延迟不会受到惩罚。

要求和安装

OnKey 需要 Apple Silicon Mac（M1 或更高版本）运行 macOS 14.2 或更高版本。没有 Intel Mac 版本，也没有 Windows 或 Linux 版本。

安装方法：从最新的 GitHub 版本下载 OnKey.dmg，打开它，然后将 OnKey 拖到应用程序文件夹。

设置需要两个权限和一个偏好设置：

  • 麦克风访问，用于听到歌手的声音。
  • 系统音频录制，用于听到音乐应用的声音。
  • OnKey 是否可以跟随 Spotify 和 Apple Music。 选择仅聆听则仅通过声音跟随歌曲。

入门指南和常见问题解答发布在 singonkey.app/docs。

隐私：哪些内容保留在 Mac 上，哪些内容会传出

OnKey 从不保存它听到的音乐。它在播放时在内存中分析声音。您的录音和它学过的歌曲保留在您的 Mac 上。README 指出一个注意事项：通过扬声器演唱的录音可能包含部分音乐，而耳机录音则不会。没有账户，没有分析，也没有崩溃报告。

文档记录了四类出站请求：

  • Shazam（Apple）： 音乐应用声音的简短签名，不是音频，也绝不是麦克风，用于在音乐应用未报告播放内容时，为 OnKey 未学过的歌曲命名。
  • LRCLIB： 歌曲的艺术家、标题、专辑和时长，用于获取歌词。
  • iTunes 搜索和查找（Apple）： 艺术家和标题，或 Shazam 返回的 ID，用于封面和歌曲时长。封面图片来自 Spotify、Apple 或 YouTube 的图片服务器。
  • GitHub： 启动后一分钟检查一次新版本，每天一次，以及更新下载。

设置中有 Shazam 开关、歌词开关和更新检查开关。仓库文件 scripts/release-hosts.txt 列出了发布版本接触的所有网址。

Hacker News 评论者 stevage 特别指出这是项目的突出品质：

我非常欣赏这种透明度。希望这能成为标准。

合理使用设计：OnKey 如何规避音乐许可

OnKey 不提供、不流式传输也不下载音乐。这一单一约束使其余法律设计成为可能，README 说明了要求用户遵守的规则：

  • 不要分享学到的转录。 每首歌曲旋律的转录仅用于个人练习，不应分享或发布。
  • 使用内置的分享功能发布演唱。 分享功能生成一个包含您的声音和音高线的短视频，不包含音乐，歌手可以从 Instagram 自己的音乐库中添加歌曲，该音乐库已获得该用途的许可。建议使用耳机录音；不要发布播放音乐的屏幕录制。
  • 在酒吧或活动中使用获得许可的卡拉 OK 服务。 OnKey 的歌词来自免费的社区数据库。
  • 不要修改 OnKey 以保存音乐。

权利持有人可以联系 hello@singonkey.app，LEGAL.md 涵盖了详细信息。

这是对帖子中其他构建者遇到的问题的直接回应。评论者 fourneau 描述了一个卡拉 OK 评分项目正是因为这个原因而停滞：

我的卡拉 OK 项目停滞不前，因为我负担不起获得音乐版权的费用，而且似乎没有很好的法律解决方案来获取音频。

fourneau 还指出，DAM 和 JoySound 卡拉 OK 系统已经提供了评分模式，可以做两件事：帮助您唱准音，并匿名与其他歌手排名。

从源代码构建和验证发布

OnKey 采用 MIT 许可，README 记录了完整的源代码构建过程，适用于任何不想信任维护者二进制文件的人。它需要一台装有 Xcode 命令行工具、Rust、Node 和 Python 3 的 Apple Silicon Mac：

git clone https://github.com/dsmurrell/onkey && cd onkey
npm install && npm --prefix ui install
python3 -m venv .venv && .venv/bin/pip install -r scripts/requirements-models.txt
PYTHON=.venv/bin/python scripts/fetch-models.sh
npx tauri build

fetch-models.sh 步骤下载模型并通过 SHA-256 检查它们。自建副本会失去一项功能：它无法请求 Shazam 为新歌曲命名，因为这需要维护者的 Apple 签名。Spotify 和 Apple Music 会自行报告播放内容，因此这仅影响 YouTube 播放和“仅聆听”模式。

官方发布版本使用 Murrell 的 Apple Developer ID 签名，并由 Apple 公证。spctl -a -vv /Applications/OnKey.app 显示谁签署了已安装的应用。

关于许可证的商标条款：修改版本不能称为 OnKey 或使用其图标，如果您基于代码构建，希望您提供指向仓库的致谢链接。CONTRIBUTING.md 记录了测试以及如何检查发布版本的校验和，THIRD_PARTY_NOTICES.md 包含完整的声明和许可证文本。

评论者称赞的内容

帖子中的热情集中在三件事上：这个想法、不需要歌曲编排的事实，以及隐私文档的透明度。

评论者 wnissen 喜欢歌曲不需要开发者支持：

多么有趣的想法！我喜欢歌曲不需要开发者编程。

wnissen 还将其与摇滚乐队时代的节奏游戏进行了比较，这些游戏提供了练习的动力，但不一定能提高歌唱水平，并指出了耶鲁音乐实验室的音高感知测验，网址为 themusiclab.org/quizzes/td，用于测试相对音高感知。

其他反应来自有实际用途的人：infossgmllc 说一个在合唱团的女儿会去看看，abktya 说它适合整天唱歌的妻子和女儿，nopurpose 则惊讶于外部应用可以与 Safari 标签页中的 YouTube 交互。

评论者 bita_nidir 在个人待办事项清单上列出了同样的项目已有 20 年，包括 Linux 和小提琴支持，并询问代码中存在哪些 Apple Silicon 限制，提出愿意发送拉取请求。

帖子中的批评和未解决的问题

资源使用和 Tauri 技术栈

最尖锐的技术批评来自评论者 viraptor，他认为该应用完全是“氛围编码”，并质疑为什么使用 Tauri 通过 webview，而原生 Swift 应用可能更小更流畅：

人们使用 electron/tauri/whatever 来使编写和维护更容易，但如果我们只是在“氛围”而已，能不能回到尊重资源的问题上？

评论者补充说，他们喜欢这个想法，并且过去曾使用过类似的付费应用。这是对实现选择的批评，而不是对代码编写方式的验证性声明。

平台限制：仅限 Apple Silicon

OnKey 需要 M1 或更新的 Mac。评论者 mkesper 要求 Linux 版本，hungryhobbit 更尖锐地提出了同样的观点，指出 Mac 和 Linux 现在足够相似，值得考虑移植。

评论者 busssard 提供了一个绕过 Mac 限制的可能途径：他们自己的声乐记谱项目，托管在 om-intelligence.ch，可以将歌曲转换为可唱的记谱，并且在他们看来，可以集成。

语言覆盖

评论者 robofanatic 询问 OnKey 是否适用于任何语言的歌曲，还是仅限英语。README 没有直接解决语言覆盖问题；其流水线处理分离的人声音频和 CREPE 音高跟踪，而不是歌词，而歌词本身来自 LRCLIB。

音高、音程和“跑调”的含义

评论者 TZubiri 认为相对音程比绝对频率更重要：

我认为把音程弄对更重要，你可以取任何起始频率，只要音程正确，听起来就会正确，即使频率本身不完美。而如果你使用这种基于频率的方法，你会有一个绝对的参考框架，而不是相对的。

OnKey 部分地通过将低八度演唱视为正确来适应这一点，但其显示将您的音高与学到的音符位置进行比较，而不是抽象地评分音程准确性。

评论者 criddell 提出了一个术语问题：对他们来说，“跑调”意味着唱出作品调性之外的音符，而不是相对于目标音符偏高或偏低。他们指出，YouTube 上的一些曲目似乎整体偏高，可能是因为在混音或母带处理时加速了，并询问这些是否会被视为跑调。

教学法：视觉反馈会取代聆听吗？

评论者 sligbad 教授节奏学生，警告依赖视觉反馈：

我认为这类工具可能有用，但我见过的需要摆脱视觉节拍器依赖的节奏学生数量是惊人的。部分困难在于真正倾听自己，并学会发现自己的错误。

他们补充了一个针对构建者和用户的警告：不要花在制作和维护练习工具上的时间分散了对最重要的事情——更多练习——的注意力。

评论者 enzoaguado 提出了相关的范围论点，即唱歌不仅仅是唱对音符，列出了呼吸管理、避免在困难歌曲中受伤的发声技巧、诸如强混声、鼻音、头声、胸声和气泡音等技巧，以及韵律和节奏训练，这些都是有抱负的歌手需要的技能，而音高评分器无法覆盖。他们的结论是，这样的工具是一个很好的入门点，让用户尝到唱歌的滋味，但覆盖或至少提及这些其他方面会有所帮助。

功能请求和未解答的问题

  • 游戏化。 评论者 pheraph 建议为女儿添加分数或星级评级，并结合难度级别，她可能会喜欢。OnKey 已经产生分数和逐行报告，但评论要求在之上添加进度层。
  • 排除错误标记的部分。 评论者 hensenjuang 询问当人声分离拾取的是伴唱而不是主旋律时，是否可以排除该部分不计入评分。
  • 乐器支持。 评论者 julianromano 询问 OnKey 是否可以扩展到乐器。
  • 音高检测细节。 评论者 HummingBirdGif 询问音高检测是如何实现的；README 在组件级别回答了这个问题，使用 CREPE 进行音高跟踪，使用 GAME 音符模型生成音符条。

帖子引发的更广泛辩论

除了应用本身，讨论中出现了两个主题。

首先，关于 AI 辅助应用构建的利弊。评论者 drltaidev 描述了自己有编程背景和机器学习博士学位，他说自己对 Claude Code 的能力印象深刻，自己几乎不再写代码，同时指出了缺点：现在每个人都可以构建自己想法的版本，但不一定是最好版本能存活。他们还同意范围批评，即唱歌涉及远不止音高。

其次，明确说明软件通过网络发送什么的价值。帖子中获赞最多的反应不是功能请求，而是对 OnKey 披露其四种出站请求类型的赞赏，并希望这能成为发布软件的标准。

Sources

相关