OMR-Datasets：光学音乐识别数据集从整理到基线搭建全解析

简介面向光学音乐识别OMR与音乐信息检索研究者的数据集聚合包汇总了手写符号、印刷乐谱、谱线、音符标注等多类公开数据集并梳理了各数据集的规模、格式、典型用途、下载入口及许可引用要求方便直接用于谱线检测与删除、卷积神经网络训练、端到端识别、符号分类与对象检测等任务。资源共87个文件以png示例图片、py工具脚本、md说明文档和xml标注文件为主整体仅6.24MB其中omrdatasettools模块提供数据下载器、多种图像生成器与可视化辅助代码便于复现或扩展实验数据并附有说明文档、测试脚本与持续集成配置等辅助内容。目前已有298人学习。借助该包可快速建立OMR数据集索引避免逐一搜索官网同时脚本与示例能帮助构建自定义训练样本适合做数据准备、模型评估或系统对比验证的研究者。1. 光学音乐识别为什么这么依赖数据集集合1.1 从OCR到OMR难点到底在哪OMROptical Music Recognition光学音乐识别这个方向中文圈子里讨论得不多但它在数字人文、音乐图书馆和乐谱数字化里一直是个硬骨头。简单说OMR 的目标是输入一张乐谱图片——不管是印刷谱还是手写谱——程序自动把里面的音符、谱号、调号、节奏、连音线、歌词全部认出来最终输出成 MusicXML、MEI 这类结构化格式。很多人一听就说这不就是 OCR 换个识别对象吗自己动手以后才发现完全不是一回事。OCR 面对的是线性文字阅读顺序基本是固定的而乐谱是二维排版一个音符往左看是调号往上看是连音线往右看是下一拍的时值同一个符号在不同语境下含义完全不同。更麻烦的是OMR 识别错一个符头位置音高就偏了一度认错一条谱线整段旋律就散了。所以这个领域的模型、数据、评价标准都得单独设计。而设计的前提就是得有足够多、足够规范的数据。1.2 数据集散落是领域最大的门槛我最初接触 OMR第一反应是找个现成数据集直接开训。结果翻遍各个论文附录、作者个人主页、老旧的学术 FTP整个人都不好了。这个领域的数据集散落得太厉害有的藏在论文的补充材料里有的挂在个人网站的角落里有的下载链接已经失效还有的格式说明只有半页 PDF甚至标注口径各不相同。很多论文声称用了某个数据集但你真去复现的时候光是把数据跑通就得花上两三周。所以 OMR-Datasets 这个项目表面看是一个“数据集集合”本质上是把散落在学术生态里的资源重新组织成一个可用的起点。对于刚入门的研究者它省去了满世界考古的功夫对于已经在做相关项目的人它是自查数据是否覆盖全面的一份清单。这篇文章我会按“为什么要整理—数据源有哪些—格式与预处理—基线模型怎么跑—常见坑”这个顺序展开把我在整理过程中的实际经验和对这个集合的理解都说清楚。2. 拆解 OMR-Datasets 里的核心数据源2.1 印刷乐谱、手写乐谱与合成数据各有各的用处OMR 领域的数据集按来源可以分为三类这三类在 OMR-Datasets 里都会被覆盖。第一类是印刷乐谱数据集。这类数据来源通常是老版乐谱的扫描件或者用制谱软件渲染出来的图片。它们的优点是版面干净、字体统一、标注明确特别适合训练端到端的识别模型。比如 PrIMuS 这类被广泛使用的印刷谱数据集里面的乐谱片段是渲染生成的标注信息非常规整很多深度学习基线都是拿它评测的。缺点是合成渲染和真实扫描之间还是有域差距真实老乐谱有泛黄、褪墨、脏点甚至有手写批注光靠干净渲染图训练的模型遇到实际扫描件经常掉点。第二类是手写乐谱数据集。手写谱比印刷谱难一个量级因为不同人的书写风格差异巨大符头可能不是一个标准椭圆符干角度也千奇百怪。典型数据集有 HOMUS它是按手写符号的轨迹记录的里面每个样本都是一小段笔画轨迹适合做孤立符号识别或者序列识别的前置任务还有 MUSCIMA 和 CVC-MUSCIMA它们包含大量手写谱的符号级标注甚至专门为谱线检测与移除任务设计了验证集。如果要做真实手稿数字化这类数据绕不开。第三类是合成与半合成数据。说实话OMR 发展到现在标注人力成本一直很高靠纯人工标注很难攒出大数据量所以很多团队选择用制谱软件先渲染一批乐谱再通过复杂的渲染参数模拟扫描噪声、纸张纹理、模糊效果做成带标签的“伪真实”数据。这种做法效果不错但也带来一个新问题如果合成参数不够多样模型会记住渲染器的“审美”换个字体或扫描仪就失灵。选择数据源时我建议不要只盯一个数据集而是把三种来源都纳入用印刷谱打底、手写谱逼上限、合成数据补数量。2.2 标注粒度差异同一张图不同数据集给的是不同答案整理数据集的第二个难点是标注粒度。同样是标注一份乐谱A 数据集可能只给你“音符序列”B 数据集给你的是“每个符号在图像里的位置框”C 数据集则更进一步连符干和符头的连接关系都标了。粒度不同能做的任务就完全不同。拿 PrIMuS 来说它的核心标注是一种语义编解码格式把乐谱转成线性 token 流——每个音符包含音高、八度、时值、声部这些信息适合直接做序列到序列的识别训练。而 HOMUS 的标注是符号轨迹它更像手写识别里的“笔画级别”数据。MUSCIMA 则侧重符号级目标检测一个音符就是一个实例还带类别和连接关系。这几类标注没有谁优谁劣关键看你定义的任务想快速跑通端到端识别用语义序列标注的数据集想做检测与版面分析用带框的想研究手写轨迹建模用轨迹级的。提示在同一个项目里混合使用多个数据集时最容易被忽略的就是标注粒度不一致。合并之前务必先统一成同一个中间格式否则训练代码里到处是 if-else 来处理不同标签结构后期的混乱程度会让你怀疑人生。3. 数据格式、标注规范与预处理实操3.1 我建议的标注中间格式与转换策略不同数据集自带格式不同硬要统一很痛苦。我的做法是准备一个中间格式层把它作为所有数据集的交集。交集里至少包括三部分图像路径、图像中谱表的位置如果原数据集给了的话、线性化的符号标签序列。这个序列我用类似“pitchG4, durationquarter, voice1, accidentalsharp”的统一字段描述不直接用某个特定格式因为不同的下游模型需要的是不同的输入形式你自己定义的中间格式灵活性最大。这里我踩过一个坑一开始想图省事直接全部转成 MusicXML。结果发现有些数据集里标注的“半休止符”和 MusicXML 里的表示方式差异很大转换时把一些修饰符号弄丢了。后来我意识到对于训练任务真正稳定的格式是把乐谱转成语义序列而不是追求可视化的 MusicXML。MusicXML 适合最终输出不适合作为训练中间表示。如果你也在做类似工作建议先想清楚你的模型读什么再决定中间格式而不是反过来被现有格式绑架。3.2 一套可复用的图像预处理流程图像预处理在 OMR 里非常关键因为它直接影响识别管线前面的质量。我的常规流程是这样import cv2 import numpy as np def preprocess_omr_image(image_path): # 1. 读为灰度图 img cv2.imread(image_path, cv2.IMREAD_GRAYSCALE) # 2. 自适应二值化应对老扫描件的灰度不均匀 binary cv2.adaptiveThreshold( img, 255, cv2.ADAPTIVE_THRESH_GAUSSIAN_C, cv2.THRESH_BINARY_INV, 31, 15 ) # 3. 形态学去孤点噪声 kernel cv2.getStructuringElement(cv2.MORPH_RECT, (2, 2)) cleaned cv2.morphologyEx(binary, cv2.MORPH_OPEN, kernel) # 4. 统一尺寸宽高 h, w cleaned.shape target_w 1024 target_h int(h * target_w / w) resized cv2.resize(cleaned, (target_w, target_h)) return resized自适应二值化比全局阈值稳定这应该不用多说。真正需要留意的是第三步形态学开运算的核大小2x2 是我试下来比较稳的默认值核再大一点容易把细的符干断开再小则噪声压不掉。这些看似琐碎的操作在 OMR 里会直接影响后面谱线检测和音符识别的质量。预处理完了之后谱线检测与移除是另一个大环节。乐谱识别里一个主流思路是先把五线谱的谱线去掉再识别剩下的符号。传统方法用水平投影找线位置碰到谱线弯曲的手写谱就很容易翻车。整理数据集的过程中我也在集合里保留了一些专门做谱线移除评测的数据比如 CVC-MUSCIMA这部分数据对验证去线算法很有用。如果自己实现可以从最经典的形态学方法起步再逐步换成基于对抗生成网络的去线方法不过后者对数据量和训练技巧的要求都高不少。4. 用这个集合跑通一个 OMR 基线项目4.1 模型选型与输入设计有了经过整理的数据集接下来就是建基线模型。当前 OMR 识别的主流baseline大致有两类一类是 CRNN CTC 的序列识别路线一类是基于 Transformer 的端到端路线。CRNNCTC 的结构更简单训练更稳定对数据集规模的要求也友好适合做第一个基线Transformer 路线在有大量干净标注时上限更高但调参成本明显更大。我建议的快速起跑配置是输入图像切成单行谱表高度固定到 64 或 128 像素保持宽度比例卷积骨干用轻量的 VGG 或 ResNet 前几层序列建模层用两层双向 LSTM输出接 CTC loss。在这套配置下如果数据集是印刷谱几千张谱表就能训出一个能看的模型手写谱就得把数据量再往上加一个量级。4.2 评测指标别只用字符准确率骗自己OMR 领域最常用的指标是符号错误率Symbol Error Rate, SER本质上是编辑距离除以总标注符号数。这个指标很直观但它有一个问题它不区分“音高错”和“时值错”也不区分“多认了一个符号”和“漏认了一个符号”。实际做音乐信息检索时音高错的后果远重于多一个装饰音所以我建议在 SER 之外再单独统计音高准确率和节奏准确率。我整理数据集的时候特意把标注拆成了音高轨道和时值轨道也就是把每个符号的字段分别提取出来方便单独计算指标。这样调试模型时非常有用如果 SER 高但音高准确率不错说明模型主要错在节奏/时值上问题可能出在音符分割反过来则说明音高分类器出了问题。如果你只是想跑通流程SER 一个指标够了但如果你要发论文或者做实际产品建议按任务拆开算否则很难定位错误来源。注意合并多个数据集前务必检查测试集和训练集之间有没有作品重叠。OMR 数据集通常按作品切分但不同数据集的划分标准不一致有的按页切有的按片段切一不小心就会发生同一首曲子既在训练集又在测试集的情况测出来的指标虚高得离谱。我都是建了一个“作品名指纹”表合并前先跑一遍重叠检测。5. 实操踩坑记录与数据集筛选清单5.1 常见问题速查表整理和使用 OMR-Datasets 的过程中我记录了一些高频问题整理成表格直接分享给项目里的新人参考。现象可能原因解决建议下载链接失效学者主页迁移、老 FTP 下线先试 Web Archive不行直接写邮件给作者标注格式各不一样数据集各自定义了私有格式先设计自己的中间格式再写脚本统一转换同一数据集不同来源描述冲突论文里写了 A 版本数据集页面是 B 版本以数据集官方文档为准并在 README 里记录版本训练时 loss 不降谱线未移除干净/切分错位/标签对齐错误先可视化一批训练样本和标签逐条确认模型能收敛但测试集崩掉训练集与测试集分布差异大加入真实扫描图做域适应或用合成增强缩小 gap授权边界模糊页面只写了 “for research”商用前务必邮件确认尤其注意跨机构使用5.2 选数据集的几个判断标准面对 OMR-Datasets 里列出的众多数据集很多新手会陷入“全都要”的冲动。我的建议是先定需求再选数据重点关注五点一是标注粒度是否匹配任务二是数据集的版权状态这个直接决定你能不能公开模型三是数据集的划分是否带官方 train/test split如果没有需要自己留出验证集并记录划分规则四是图片分辨率是否足够很多老数据集扫描分辨率只有 150 DPI对现代深度学习来说略低五是数据集的“域覆盖”也就是有没有涵盖白底印刷、黄底古籍、手写草稿这些不同条件下的图像。结合我自己做过的项目如果目标是快速起步优先选 PrIMuS 这类印刷谱语义序列标注数据集跑通流程最快如果目标是做古籍数字化则要认真考虑真实扫描和手写数据集的组合如果目标只是做谱线移除算法那 CVC-MUSCIMA 这类专门数据的优先级最高。5.3 后续能往哪些方向扩展整理这个集合的过程也让我看到 OMR 这个领域还有不少空缺。比如复杂花体乐谱、多声部声乐谱、带完整歌词的乐谱这些数据类型目前公开数据集还很少再比如同一首曲子的“图像—音频对齐”数据几乎没有公开版本如果往这个方向做很可能踩着空白点出成果。我自己计划下一步是把数据集集合里每份数据的“官方标注之外是否带层级结构”标注清楚因为很多场景下比如自动伴奏、音乐教育软件需要的不只是音符序列还需要整首曲子的段落结构和声部关系。说实话做这个项目最费时间的不是写代码而是跟各种格式、授权、错误的标注搏斗。但当我把第一个跨数据集训练的模型跑通、看到它在未见过的扫描谱上也能认出音符时那种满足感确实值得。最后再分享一个小习惯所有下载好的数据集我在文件目录里都会保留一份原始 README 和下载日期记录。数据集的页面可能哪天就没了但你本地留过一份后面的工作就都有一个可追溯的基线。这一点在很多项目里都不起眼真到复现实验或者写数据说明的时候能帮你省下大量跟人解释的力气。本文还有配套的精品资源点击获取