Audiveris
更新于 2026-10-27 17:55:53
一句话定位
Audiveris 是一款开源的 OMR（Optical Music Recognition，光学乐谱识别） 应用：把纸质乐谱的照片、扫描件或 PDF 变成可编辑的 MusicXML，让谱子能进 MuseScore、Sibelius、Finale 继续编辑、移调、播放。
它不是「又一个 PDF 转图片」的工具，而是由 识别引擎 + 人工校对编辑器 两个部分咬合在一起工作的桌面软件，识别不了的部分由人来补，这是它能在真实出版物上跑出可用结果的关键。
它是怎么识别乐谱的
Audiveris 的引擎没有试图用一个大模型「端到端」解决所有问题，而是按符号类型分别上手段：
| 目标 | 方法 |
|---|---|
| 五线谱的谱线 | 针对性的 ad-hoc 检测（按行/按列扫描 + 形态学） |
| 符杠（beams） | 图像形态学闭运算 |
| 歌词、标题等文字 | 调用外部 OCR（Tesseract，仓库里锁定 tessdata 4.1.0） |
| 符头（noteheads） | 模板匹配 |
| 其余定尺寸符号 | 神经网络分类 |
这套组合的工程含义很直接：谱线、符杠这类几何特征强的东西用传统图像算法更稳、更快；真正难的是符头和各种记号，才交给模型。作者在 README 里也很坦白：即便是现在，「100% 识别率在很多情况下根本达不到」，所以编辑器不是附属品，而是设计的一部分。
上手：装包就能用，不用碰 Java
从 5.5 版起官方为三大平台提供自带 JRE 的安装包，安装在 Assets 里：
| 系统 | 安装包 |
|---|---|
| Windows | .msi，也支持 winget / scoop |
| Linux | .deb，或 Flathub 上的 org.audiveris.audiveris |
| macOS | .dmg（Apple Silicon 与 Intel 分开下载） |
当前最新稳定版 5.11.0（2026-07-11），发布节奏大约 6–12 个月一次；仓库到 2026-10 仍在持续提交，属于活跃维护状态。
典型工作流：
- 打开图片 / PDF / 扫描件，可以一次导入几百页的整本谱集；
- 在工具栏上勾选本次要启用的处理开关（比如是否识别歌词、和弦、吉他谱）；
- 跑识别，等它出 OMR 结果；
- 在编辑器里逐页过一遍，改错音符、补漏记号；
- 导出 MusicXML 4.0，或用
.omr工程文件保留完整的结构化中间数据。
.omr 是 XML 格式的音乐信息工程文件，OMR 数据结构在文档里有完整说明，也可以直接通过 Java API 读取——这一点对做批量处理或二次开发的人很重要，等于给你留了一个不依赖 GUI 的数据接口。
适合谁用
- 需要把纸质谱、老版谱、IMSLP 上的扫描 PDF 数字化的个人或乐团：省掉手工打谱；
- 音乐老师 / 编曲：拿现成谱子改成练习版、移调版、分声部版；
- 做乐谱检索、音乐信息处理的研究者：
.omr+ Java API 是干净的入口； - 要批量处理几百页谱集的团队：官方明确支持大工程，而不是只能玩单页 demo。
不太适合：只有一两页、且要求「一次到位零校对」的场景；以及需要识别手写谱的场景——公开资料里它的强项是印刷体出版物质量。
坑与注意
- 认准官网：README 顶部专门挂了警告，
audiveris.com和audiveris.net（.com/.net 后缀）与项目无关，被安全扫描器标为高风险，链接会跳转到加密货币、体育博彩之类的页面，是典型的钓鱼站。真正的入口是github.com/Audiveris/audiveris和audiveris.github.io/audiveris。 - 校对仍是必需步骤：把识别率预期设成「80% 起步、人工收尾」更现实，尤其低质量扫描件、密集和弦、连音线复杂的段落。
- 许可证是 AGPL-3.0：自己用没问题；但如果你想把它塞进闭源产品或做成在线服务，AGPL 的网络使用条款会要求你开源修改后的代码。商业集成前建议先过法务，别默认「调个子进程就没事」。
- 源码构建门槛不低：需要
git+gradle+ JDK 25（gradle.properties里theMinJavaVersion = 25）。想改代码的话先装好 JDK 25，否则 Gradle 直接跟你翻脸。
二开与二次利用
- 分支策略：
master只放发布版本，所有开发都在development分支，定期 merge 到master。想跟新功能就盯development，想稳定就跟 release。 - 最省事的集成方式：用官方安装包 + 命令行/GUI 输出 MusicXML，再拿 MusicXML 去接自己的流程（MuseScore 命令行、music21、自己写的解析器都行），避免直接改 Java 源码。
- 要动引擎：核心在 OMR 各 step 的 chain 里，按符号类型分模块，改某一类符号的识别不需要碰全流程；文档里有
project-structure.md和 Wiki 讲结构。 - 想扩导出格式：仓库自带 MusicXML 4.0 exporter，作者也提到后续会基于 OMR 数据加别的导出目标，这是比较友好的扩展点。
和「音频扒谱」的分工
如果你手上的素材不是图片而是录音，那 Audiveris 帮不上忙——它只吃图像/PDF。录音转 MIDI/乐谱可以看同批收录的另一条路线 MuScriptor（muscriptor/muscriptor），输入是音频、输出 MIDI 和 MuseScore 排版后的 PDF/谱面。两者正好接在同一个目的的两端：
纸质谱 / 扫描 PDF ──Audiveris──▶ MusicXML
录音 / 现场演奏 ──MuScriptor──▶ MIDI / MusicXML / PDF
一句话总结
Audiveris 是开源 OMR 里少见的「工程完整度很高」的项目：识别引擎分工明确、编辑器补齐最后一公里、.omr 与 Java API 让数据可被程序消费。装包即用、支持几百页大谱集，代价是必须接受「识别 + 人工校对」的工作流，以及 AGPL 带来的商业使用约束。