Beyond Ba(t)ch: A Multimodal Meta-Corpus of Digital Chorale Transcriptions and Related Data

This is the README file for the meta-corpus of the Chorale Corpus initiative, a multi-institutional effort to bring together a wide collection of digital chorale transcriptions for musicians and researchers. When you use (parts of) this dataset in your work, please read and cite the accompanying data report: Gerhardt, K., Hentschel, J., Phan, V. D., Kirsch, M., Kirsch, K., & Gotham, M. R. H. (2026). Beyond Ba(t)ch: A Multimodal Meta-Corpus of Digital Chorale Transcriptions and Related Data. Transactions of the International Society for Music Information Retrieval, 9(1), 440–455. https://doi.org/10.5334/tismir.226 Beyond Ba(t)ch: A Multimodal Meta-Corpus of Digital Chorale Transcriptions and Related Data Chorales (broadly speaking, hymns) have featured prominently in the musical life of Western cultures for hundreds of years — and, more recently, as a focus of attention in computational approaches to music, where the dominance of 'the Bach Chorales' is a strange quirk of history. This meta-corpus brings together a wider collection of chorales, still centred on Germany and the 18th century, but featuring more collections from that regional-temporal centre and expanding beyond it. The meta-corpus combines the following sub-corpora, included as git submodules (DOI links always point at the latest version of the respective sub-corpus): Georg Christian Apel (1775–1841) – Vollständiges Choralbuch [DOI][repo][ZIP] J.S. Bach – 389 Chorale Settings (Choralgesänge) [DOI][repo][ZIP] Claude Goudimel – The Geneva Psalter [DOI][repo][ZIP] Johann Christian Kittel – 'Vierstimmige Choräle' and '24 Choräle mit acht verschiedenen Bässen' [DOI][repo][ZIP] Johann Balthasar Rein (1714–1794) – Vierstimmig Choralbuch [DOI][repo][ZIP] Niels Schiørring (1743–1789) – Choralbook [DOI][repo][ZIP] Bendix Friedrich Zinck (1715–1799) – Vollständige Sammlung der Melodien [DOI][repo][ZIP] Getting the data download individual sub-corpora as ZIP files using the URLs provided above download a Frictionless Datapackage that includes concatenations of the TSV files of all sub-corpora and a JSON descriptor: data.zip data.datapackage.json clone the repo with all submodules: git clone --recursive -j8 [e-mail]:Chorale-Corpus/data.git where -j8 means running 8 jobs in parallel. Data Formats Every sub-corpus follows the same layout; see the individual sub-corpus READMEs for details and provenance. Information related to one and the same chorale is represented in multiple formats, with identical filename prefixes acting as IDs: an uncompressed MuseScore 3.6.2 file (.mscx), the authoritative format; an MEI file (MEI/) and a musicXML file (musicXML/), both automatically converted from the MuseScore file using MuseScore 4 — convenient, but without guarantee of perfect congruence with the source files; three TSV tables extracted with ms3: notes/, measures/, and chords/ (the latter containing markup such as lyrics and bass figures), each accompanied by a JSON descriptor following the Frictionless specification. In addition, each sub-corpus comes with a metadata.tsv (one row per chorale), and this meta-repo provides the concatenation of all of them as data.metadata.tsv, described by data.metadata.resource.json. The scripts used for maintaining the meta-corpus (score conversion, metadata concatenation) are in the code/ folder. Opening Scores You can open the scores in the sub-corpora with the free and open source score editor MuseScore. Please note that the authoritative .mscx files are edited with MuseScore 3.6.2 exclusively, whereas the MEI and musicXML versions are generated from them using MuseScore 4. Opening TSV files in a spreadsheet Tab-separated value (TSV) files are like Comma-separated value (CSV) files and can be opened with most modern text editors. However, for correctly displaying the columns, you might want to use a spreadsheet or an addon for your favourite text editor. When you use a spreadsheet such as Excel, it might annoy you by interpreting fractions as dates. This can be circumvented by using Data --> From Text/CSV or the free alternative LibreOffice Calc. Other than that, TSV data can be loaded with every modern programming language. Loading TSV files in Python Since the TSV files contain null values, lists, fractions, and numbers that are to be treated as strings, you may want to use this code to load any TSV files related to this repository (provided you're doing it in Python). After a quick pip install -U ms3 (requires Python 3.10 or later) you'll be able to load any TSV like this: import ms3 metadata = ms3.load_tsv("data.metadata.tsv") # metadata for all chorales notes = ms3.load_tsv("Apel_GC/notes/A-MCAU_AP1832-001_SID026.notes.tsv") You can look up what any column means in the documentation of ms3: https://ms3.readthedocs.io/columns Version history See the GitHub releases. Questions, Suggestions, Corrections, Bug Reports Please create an issue and/or feel free to fork and submit pull requests. Cite as Gerhardt, K., Hentschel, J., Phan, V. D., Kirsch, M., Kirsch, K., & Gotham, M. R. H. (2026). Beyond Ba(t)ch: A Multimodal Meta-Corpus of Digital Chorale Transcriptions and Related Data. Transactions of the International Society for Music Information Retrieval, 9(1), 440–455. https://doi.org/10.5334/tismir.226 License Creative Commons Attribution-NonCommercial-ShareAlike 4.0 International License (CC BY-NC-SA 4.0). Maintenance: releasing a new version of this Chorale-Corpus meta-repo The sub-corpora release independently: every merged pull request in a sub-corpus repository triggers its version_release.yml workflow, which bumps the version tag, updates .zenodo.json, CITATION.cff and the README, creates a GitHub release with the datapackage artefacts, and thereby (via the Zenodo webhook) archives a new version on Zenodo. Updating this meta-repository afterwards involves the following steps. 1. Update the submodules In a full recursive clone (see Getting the data), first create a release branch: start from the current tip of main and pick a fresh, version-specific branch name — branching off a stale local main, or re-using a branch name that already exists on the remote (e.g. from a previous release), will make the git push in step 3 fail with "failed to push some refs". Then pull the latest state of every sub-corpus and commit the moved submodule pointers right away — the next step requires a clean repository: git checkout main && git pull git checkout -b release-v2.2 # use the upcoming version number git submodule update --remote git submodule status # verify that each submodule points at the intended (usually the latest tagged) commit git add Apel_GC Bach_JS Goudimel_C Kittel_JC Rein_JB Schiorring Zinck_BF git commit -m "updates submodules" 2. Regenerate the metadata This step requires a completely clean repository: ms3 refuses to run if there are any uncommitted changes — not only the submodule pointers committed in step 1, but also anything else you may have lying around in the working tree. Check with git status and commit or stash leftovers first. Then, with ms3 installed (pip install -r code/requirements.txt), run from the top level: python code/update_metadata.py This re-concatenates the sub-corpora's metadata.tsv files into data.metadata.tsv, updates the Frictionless descriptor data.metadata.resource.json, and refreshes the overview tables at the bottom of this README. Review the diff, then commit: git add data.metadata.tsv data.metadata.resource.json README.md git commit -m "updates metadata" 3. Open a pull request and merge it Push the release branch and open a pull request against main: git push -u origin release-v2.2 Do not push to main directly: every merged PR produces a tag and a GitHub release. On merge, the version_release.yml workflow bumps the minor version (add the PR label major_version for a major bump), rewrites the version string and all dates in .zenodo.json, CITATION.cff, and the README (committing as ms3-bot), pushes the tag, and creates a GitHub release with the artifacts of ms3 transform. The PR title and body become the release title and body, so write them for the public — and keep in mind that PR/release bodies render every line break literally, so use unwrapped paragraphs (one paragraph per line, as in this README). 4. Generate Chorale-Corpus-vX.Y.zip A complete ZIP file is required for the Zenodo release. Contrary to the corpus directories, this needs to happen manually for meta-repositories which compile submodules because they appear as empty folders in the automatically generated ZIP files. So to create the file manually, head to the top level of your local clone, make sure it is clean and fully up to date (git submodule update --init --recursive), and do: zip -r Chorale-Corpus-v2.2.zip ./ -x '*.git*' '*.idea*' replacing v2.2 with the version number that the release workflow created in step 3. The '*.idea*' exemplifies how more exclusions can be added to the command (here, it's ignoring all directories called .idea and their contents). 5. Create the new version on Zenodo The Zenodo webhook remains disabled for this repository because no files can be added to an automatically created release after the fact — and the automatically archived ZIP would have empty submodule folders. New versions are therefore created by hand: Open the record via the concept DOI 10.5281/zenodo.17229783 (always resolves to the latest version), log in, and click New version. Remove the inherited file(s) and upload: Chorale-Corpus-vX.Y.zip — the complete ZIP of this repository including all submodule content, created in step 4 Chorale-Corpus.zip — the datapackage with the concatenated TSV files, i.e. the asset data.zip of the GitHub release created in step 3, renamed Chorale-Corpus.datapackage.json — its descriptor, i.e. the release asset data.datapackage.json, renamed Update the metadata by hand — manual versions do not read .zenodo.json (only the GitHub webhook does): set the new version number and publication date, and bump the version in the related identifier pointing at the GitHub tree (https://github.com/Chorale-Corpus/data/tree/vX.Y). Authors, license, keywords, and the remaining related identifiers usually stay unchanged. Publish. The new version receives its own DOI automatically; the concept DOI keeps resolving to the latest version.