Weird Techmusicbraillemidipythonopen sourceaccessibility
Chris McCoy Played Gottschalk's Grande Tarantelle by Decoding a Blind Musician's Braille Score Into MIDI, and His Parser Caught Seven Bars Where the Braille Disagrees With the 1874 Print
No scan, no optical music recognition: a standard-library Python decoder reads Hu Haipeng's braille transcription note for note, checks every one of 539 bars adds up to 6/8, and layers rubato, pedal and rolled chords on top.

Braille music has no guesswork in it. “The braille gives every pitch and duration exactly, so no optical reading of the 1874 scan was needed,” McCoy writes in the repo’s README. Every note sits in a plain-text .brf file as cells of six dots, written out as ASCII.
That file is the work of Hu Haipeng, a blind pianist from Wuhan who transcribes scores for his Braille Orchestra and Open Braille Music projects. He launched Open Braille Music in 2016, China Daily reported, to give away braille scores “to reduce the difficulty for blind music learners like me.” His Gottschalk transcription sits on IMSLP as a bar-over-bar file, “optimized for refreshable braille displays,” under a Creative Commons license.
McCoy’s brf.py reads it using only Python’s standard library. That’s harder than it sounds. The decoder handles octave marks and BANA’s rules for when an octave goes unmarked, intervals that read down in the right hand and up in the left, in-accord voices, measure repeats “whose extent comes from the bar’s length,” triplets and quintuplets, grace notes, ties, fingered tremolos, first and second endings, and key changes.
The proof it works is arithmetic. “Every voice of all 539 bars (and the two second endings) adds up to exactly 6/8,” the README says.
Then McCoy checked the braille against the 1874 Oliver Ditson print, which is also on IMSLP, in every section. “Six places in the braille differ from the print,” he writes, and brf.py fixes them in a table called CORRECTIONS. Bars 2, 3, 5, 440, 444 and 446 voice a left-hand A major chord as A2 C♯3 E3, where the print has A2 E3 C♯4, because “the tenth needs an octave mark the braille lacks.” Bar 489 has “a stray 5k after the third note” that the print doesn’t have, and without it “the bar is exactly 6/8.”
The notes alone would play like a player piano, so perform.py adds the human part, all from the score’s own markings. The tempo is “Tempo di Tarantella at ♩. = 158, with a light lilt on each beat.” Più mosso runs about 11% faster. No chord lands all at once: each hand places its own, the left “usually a few milliseconds ahead,” fanning out “over about 10 ms for an octave to 20–40 ms for a big chord.” Even the wobble is reproducible. “The randomness is seeded, so every build is the same.”
The best piano isn’t one his script can reach. render.swift can’t load GarageBand’s Steinway, an EXS24 instrument that AVAudioUnitSampler refuses with error -10868, so the README tells you to open the MIDI in GarageBand yourself and click Import Tempo, because “the rubato lives in the tempo map.” The braille also leaves out the print’s ossia and Facilité staves, so this performance skips those passages entirely.
The repo opens a door for every score Hu and other transcribers have already done. Each one is now a candidate for a decoded, checked performance with no scanning step, and the error tables those decoders produce could flow back to the transcribers as corrections.
Expect the reverse trip, too. A parser that reads braille music well is most of a checker for anyone writing it, and a tool that flags “this bar doesn’t add up” before a blind student hits it is the kind of thing projects like Hu’s could put to work right away.
What’s still missing is the half of the score the braille skips. Whether someone codes the ossia and Facilité staves back in by hand, or the next decoder learns to read them from the print, is the open question in McCoy’s README.