简介面向光学音乐识别OMR研究者的数据集整合仓库集中整理了手写与印刷乐谱的符号分类、谱线检测与删除、目标检测、端到端识别等常见任务所需的多组公开数据集及其加载工具适合音乐信息检索、深度学习和计算机视觉方向的学生、工程师或科研人员快速定位可用数据。资源包共87个文件大小仅6.24MB以Python自动化脚本、PNG样例图像、XML标注文件、Markdown说明文档和CI配置为主其中25个Python脚本覆盖数据集下载、图像生成、掩码生成、度量可视化等流程33个PNG样例涵盖不同乐谱样式XML标注可支撑目标检测与度量识别同时附带每个数据集的官方网站、许可要求及引用文献便于合规获取和后续引用。仓库还保留了清晰目录结构可在README中快速查看各数据集的规模、格式与典型用途方便横向对比和选型。当前已有298人学习无论是入门OMR课题还是复现论文基线都能从中快速找到匹配的数据集与工具脚本有效减少重复收集和预处理时间。 光学音乐识别(OMR)这个方向说实话在国内做的人不算多但真正碰过的人都知道一个共同的痛公开数据集太太太散了。要么在某个教授的个人主页里躺着要么藏在论文的补充材料里要么挂在GitHub上一个三年前的release下面。我前两年第一次做OMR实验的时候光是凑齐训练、验证、测试三个集合就花了将近一周的时间在各大站点之间来回跳转下载格式还不统一标注格式更是五花八门。后来在整理实验记录的时候我干脆把自己用过、调研过、复现过的OMR相关数据集系统梳理了一遍这就是OMR-Datasets这个集合项目的由来。这个项目本质上不是某个新算法的代码库也不是一个现成可用的数据集本身而是一个面向光学音乐识别研究者的数据资源索引。它解决的问题很具体OMR领域的数据集分散、描述信息缺失、标注格式混乱、使用门槛偏高。适合的读者也很明确——准备入坑OMR的研究生、刚接触乐谱识别算法的工程师、以及对音乐信息检索(MIR)方向感兴趣的开发者。如果你只是想找一份现成的数据集直接跑模型这个集合能帮你节省大量调研时间。1. 项目背景与核心思路与其反复搜索不如做一份可复用的索引1.1 OMR的数据现状为什么数据集稀缺且分散OMR做的事情通俗讲就是让计算机“看懂”乐谱——把扫描的纸质乐谱、导出的乐谱图片甚至手写谱转成机器可读的音乐符号表示比如MusicXML、MEI或者MIDI。这个任务链条很长从图像预处理、谱线检测与删除、符号切分到符号识别、音乐语义重建每一环都需要对应的标注数据来训练和评估。但和OCR领域有海量公开文档数据集不同OMR的数据集因为制作门槛高——需要懂音乐的人来做标注成本又高所以数据集总量小、碎片化严重。再加上不同数据集针对的任务粒度完全不同有的只标注谱线位置有的标注单个音符符号的边界框有的提供完整的语义标签甚至还有的附带了音频对齐信息。这就导致研究者很难像在计算机视觉其他领域那样“拿一个数据集就能跑通全套流程”。1.2 这个集合的设计思路按任务形态归类而不是按年份堆列表我做这个集合的时候最初也想过按年份或者按论文出处来整理后来实践下来发现完全不可行。因为OMR数据集的标注内容差异实在太大按时间排除了能看出学科发展脉络对实际选型几乎没有帮助。真正有效的维度是任务形态——你打算做检测、分割、序列识别还是端到端识别决定了你该找哪类数据集。所以OMR-Datasets的整理逻辑是按照数据形态和标注粒度划分层级从单页乐谱图像的符号检测与分割到整曲文档级的歌手识别再到手写乐谱与历史档案数字化。每个数据集条目包含任务类型、标注格式、规模、获取方式以及适合搭配的模型范式。这个索引对新手最大的价值在于它直接告诉你了“我手里这个问题该去哪个数据仓库里找答案”。2. 核心数据集盘点按数据形态分类的全景梳理2.1 单页乐谱图像类最适合符号检测与分割入门如果你最初级的想法是“我想检测乐谱里的音符和休止符”那类别就锁定在单页图像数据集上。目前圈内用得最顺手的几个都需要在项目里重点标注出来。Capitan数据集是个非常有代表性的单曲乐谱数据集它包含了完整的乐谱页面图像和对应的MusicXML标注特征在于整页级标注而不是碎片化的符号框。对于做端到端识别的组来说Capitan几乎是必跑的第一个benchmark。DeepScores则是另一个极端它属于全监督的大规模数据集由乐谱渲染引擎自动生成包含了几十万张图像和超过百万级的符号对象标注非常适合做目标检测类模型的预训练但因为是合成数据需要留意域迁移到真实扫描件时可能存在的性能下降。CVC-MUSCIMA是另一个不得不提的名字虽然它的全称叫手写乐谱图像数据集但实际应用中大家更多把它当作扭曲乐谱矫正和谱线删除任务的标准评测集。它提供了不同扭曲程度下的乐谱图像以及符号级分割标注在谱线检测与删除这个子任务上它依然是当前引用率最高的数据资源之一。2.2 文档级与整曲识别数据集面向复杂排版和完整乐谱重建单页图像跑通之后很多人自然想往更复杂的文档级任务走。现实中的乐谱不是只有一行旋律的简谱而是包含多声部、歌词、指法、力度记号的大版面排版。面向这一类任务Muscima是绕不开的它为超过一千页的乐谱图像提供了精细到对象层的标注每个符号不仅有边界框还有对象间的语义关系比如“这个符头属于那个符干”“这组连音符覆盖了哪几个音”。这种关系标注对做图神经网络或者关系建模的组尤其有价值。还有一个容易被忽略但实际非常实用的数据集是Forinton它专门针对管风琴乐谱多声部、多谱表并存排版复杂度远高于一般的单旋律乐谱。如果你的研究场景涉及教堂音乐数字化、管风琴乐谱历史档案整理这个数据集的排版形态几乎是不可替代的。不过它获取方式比较学术化通常需要通过邮件联系作者获取这点在实际使用时要有心理准备。2.3 手写乐谱与历史档案类更贴近真实数字化的数据手写乐谱是OMR领域里公认的硬骨头。印刷体识别做得再好遇到手写谱照样会崩。原因也很简单——手写符头的大小、位置、倾斜角度千差万别连人眼识别都偶尔需要依赖上下文信息。Homus数据集是手写乐谱识别里名气最大的一个包含了几千页的手写乐谱图像覆盖了不同书写风格。它的单词级和符号级标注都很完整是训练手写音乐符号识别器的首选数据源。历史档案类数据集主要目标不是现代印刷体而是来自文艺复兴时期、巴洛克时期的雕版印刷乐谱。这些老乐谱存在纸张老化、墨迹晕染、版面破损等问题和博物馆数字化直接挂钩。应用场景包括图书馆档案自动索引、音乐学研究的数字人文工具等。这类数据集目前公开的非常少不少项目只发布了部分采样图片。如果目标是做历史档案OCR式的OMR需要接受“数据集需要自己从馆藏扫描件中构建”的现实OMR-Datasets项目里也单独列了一个目录专门记录这些可用的馆藏扫描入口。在数据形态分类之外还可以从标注视角做一次对比方便快速选型。下面这张表是我自己常用的速查表数据集任务粒度标注内容规模参考适合的任务范式Capitan整页完整音乐编码约25首曲目端到端序列识别DeepScores符号对象边界框、类别超10万页目标检测、实例分割Muscima对象关系框、类别、对象间关系千页级关系建模、图网络CVC-MUSCIMA谱线符号谱线掩码、符号分割千页级分割、矫正任务Homus符号单词级手写符号位置与类别约千页级手写体识别、检测Forinton整曲音乐编码数十首复杂版面端到端3. 深入理解数据格式与多模态扩展3.1 Ground Truth格式从图像到语义标注的桥梁数据集选好之后紧接着就是怎么把标注读进来。OMR数据集的标注格式可以分为三个层次。第一层是纯图像级比如谱线掩码的PNG、符号分割掩码这种格式处理起来最简单直接用OpenCV或者PIL读进来就是numpy数组适合做分割类任务。第二层是对象级标注通常以XML形式存在比如Muscima的标注文件就是一个XML文档每个符号对象有id、class_name、bounding_box等字段还包含指向其他对象的relationship链接。第三层是语义级标注最常见的是MusicXML或者MEI这类格式直接描述音乐内容本身——音高、时值、拍号、调号、连音线等。理解这三个层次的差异很重要因为很多初学者会把它们混为一谈导致训练数据加载时搞错维度。比如你拿DeepScores的JSON标注去训练一个端到端的MusicXML生成模型那肯定行不通因为DeepScores的标注是对象检测级的它根本没告诉你“这个小节在整首曲子里处于什么位置”。反过来用Capitan的MusicXML标注去训练一个符号检测器也不合适因为MusicXML不包含像素坐标信息你必须自己去渲染或者对齐。3.2 多模态与跨模态扩展OMR不是只有图像识别近年来的研究趋势里OMR越来越不满足于“只看图”而是往多模态的方向走。典型场景是乐谱图像和音频之间的跨模态对齐——给定一段录音和对应的乐谱扫描件自动建立时间轴上的对应关系。这类任务需要的数据集不仅要包含乐谱还要包含同步的音频。目前在公开领域里这类数据非常珍贵通常需要在音乐表演数据库的基础上自己做对齐标注。OMR-Datasets集合里也对多模态扩展做了单独的标记比如一些原本用于音乐自动转录(AMT)的数据集虽然标注的是音频波形但如果配合乐谱图像可以改造成音谱对齐评测集。这部分我个人的建议是多模态任务不要指望能找到直接可用的现成数据更务实的做法是把单模态的乐谱图像数据集和音频数据集做一个pair然后用半自动方式做对齐标注。实践下来初始对齐可以用动态时间规整(DTW)打底再人工修正边界效率比纯手工标注高很多。3.3 构建自定义OMR数据集从样本搜集到标注落地如果你研究的任务实在太特殊比如要识别某种特定历史版本的乐谱排版现有数据集肯定覆盖不了那就需要自己搭建数据集。样本搜集最简单的方式是在公共乐谱库按作曲家和版本批量下载。拿到扫描图像后第一件事是清理去黑边、矫正倾斜、统一分辨率这些都能用OpenCV跑一个批处理脚本解决。标注环节是最大的人力开销。对于OMR任务我强烈建议不要从零写标注工具优先用已有的图像标注平台比如LabelStudio或CVAT先做符号检测框的标注再通过脚本把检测框转化成模型训练需要的格式。如果想省事还可以用现有OMR模型做预标注——先让模型跑一遍生成初稿人工在初稿上修正标注效率能提升不少。这也是目前业内构建大规模数据集比较通用的一条路径。不过需要提醒的是预标注会引入模型自身的偏置修正的时候要特别留意系统性的错漏比如模型可能把符头都识别偏小这种偏置人工修正时很容易漏掉。在实际制作过程中有一个容易被忽视的细节标注工具里画的框坐标原点可能与模型训练的预期不一致。有的工具原点在左上角有的在左下角如果不做统一转换数据喂进模型轻则检测框偏移重则训练直接发散。我建议标注完成后一定做一次可视化检查把标注框直接画在图像上随机抽几百张看一眼这个步骤能挡住大部分低级错误。4. 实操经验从数据集到训练管线的完整落地4.1 数据准备从下载到训练样本的标准化管线拿到数据集后第一步是统一格式。我用的是一个非常轻量的处理流程所有图像统一转成RGB三通道、统一较短边到合适尺寸所有标注转成COCO JSON格式用现成的检测框架直接消费。统一的格式有个额外的好处——多数据集混合训练时不用为每个数据集各写一套dataloader。以DeepScores为例它的原始标注是JSON格式但字段命名和COCO差异很大。我需要写一个转换脚本把它的对象字典映射成COCO的images、annotations、categories三个主字段。这里有个坑DeepScores的类别数非常多有些类别在训练集里出现次数极少如果全部保留会导致类别极度不均衡。实际处理时通常会做一个类别过滤只保留出现次数超过一定阈值的类别或者按论文常用的设定映射成若干大类。4.2 模型评估符号级、行级与系统级指标的差异OMR任务的评估指标和通用CV有差异。很多新手拿通用目标检测的mAP来评估OMR模型虽然不能说错但会掩盖很多音乐领域特有的问题。比如一个音符的符头位置检测正确了但符干方向识别错误检测框层面的mAP可能完全反映不出来。对于音符结构这种精细任务需要输出结构化结果后再做音乐语义级的比对。我常用的评估方式是分三层第一层是像素/符号级直接用目标检测的precision、recall、F1第二层是对象关系级检查识别的符号之间的连接关系是否与Ground Truth一致第三层是音乐语义级把识别结果转成MusicXML后用音乐信息检索工具来比对语义错误率。如果只是发论文刷指标第一层就够了但如果做的是实际数字化应用第三层才是最终决定可用性的关键。4.3 实操中的数据集划分跨数据集泛化测试更可靠因为OMR数据集普遍偏小训练和测试都来自同一个数据集时效果容易虚高。更可靠的实验设计是拿一个数据集训练在另一个数据集上测试。我在做实验时通常会保留两套评测逻辑一套是数据集内划分用于日常调参另一套是跨数据集泛化测试比如用DeepScores训练在Capitan上测试这个数字才是模型真实能力的写照。跨数据集测试还有一个额外的好处就是能暴露出数据集的域差异。比如在合成数据DeepScores上训练的模型在真实扫描的Capitan上性能往往显著下降这种下降主要是因为真实图像有纸张背景纹理、模糊、光照不均匀等问题。为了缓解这个gap可以在训练时加入随机噪声、对比度扰动、模拟扫描伪影等数据增强手段亲测能提升不少跨域鲁棒性。5. 常见问题与避坑实录5.1 标注坐标不统一与Ground Truth噪声最常碰到的问题是坐标原点不统一。有的数据集标注坐标基于图像左下角有的基于左上角直接混合训练时边界框全乱。这个问题的排查方法很朴素把标注可视化渲染到图上人眼扫一遍。如果符号框全部偏到上方或者下方固定距离基本就是坐标原点问题。我自己的脚本里固定了一个converter函数所有标注进来都先转成统一坐标原点后续再没出过类似的坑。Ground Truth噪声是另一个普遍问题。手写乐谱数据集尤其如此由于标注者本身对音乐理解的偏差同一个符号可能在不同页面上被标成不同类别。我的建议是训练前先统计类别分布把低频类别和可疑样本抽出来做一次人工复核。这个过程虽然枯燥但对模型性能上限的影响很大值得投入时间。5.2 许可证与使用范围学术与非学术的灰色地带OMR数据集的许可证问题非常容易被忽略但实际带来的麻烦比想象中多。不少数据集仅限学术用途非学术机构需要单独申请授权。像CVC-MUSCIMA、Forinton这类数据集都有明确的学术使用限制。如果你在公司里做商业项目直接使用这些数据集训练模型可能会埋下隐患。合并多个数据集时还需要注意不同数据集的标注协议往往不一样。即使都是“音符”这个类别不同数据集的类别定义范围也可能不同——有的把符头、符干、符尾拆成独立类有的则把整个音符作为一个对象。混合训练前最好先对齐类别语义否则模型会学到彼此冲突的判别规则。5.3 复现论文和对比SOTA时的数据一致性最后聊一个科研中很常见的坑不同论文在同一个数据集上的实验设置并不完全一致直接拿论文里报告的指标和你的结果对比很容易得出错误结论。比如有的论文用了完整的训练集有的只用了其中的子集有的做了数据增强有的没做有的用了额外数据做预训练有的从头训练。所有这些差异都会影响最终的数字。我的建议是在使用OMR-Datasets里的任何数据集做对比实验时先仔细阅读原论文的实验设置部分尽量复现相同的预处理和划分方式。如果实在无法复现就在自己论文里明确说明实验设置差异这在学术规范上也是更负责任的做法。6. 我的实操体会与下一步扩展方向折腾了这么久我自己最大的体会是OMR这个领域从来不缺好的算法思路缺的是把数据、评测、基线统一起来的工程化基础设施。做OMR-Datasets这个集合的过程其实也是我自己对整个领域进行系统化理解的过程。把散落在各个角落的数据集整理到一处标注清楚每个数据集的任务定位和格式对后续实验的帮助是几何级数的。最后再分享一个小技巧下载数据集的时候最好把每个数据集的来源页面、下载日期、文件哈希全记录下来。我遇到过好几次下载完过了几个月发现文件损坏的情况如果没有原始记录回溯起来非常痛苦。这个习惯虽然一开始有点繁琐但长期做研究、做工程真的能省下大量不必要的返工时间。下一步我打算在这个集合的基础上增加一个数据集的标准化预处理脚本库把从原始标注到统一训练格式的转换代码全部开源出来。如果你也在做OMR方向的数据工作欢迎参考这个集合也欢迎把你用过的数据集补充进来一起把这个领域的基础设施做得更完善。本文还有配套的精品资源点击获取