That detail turns a magical-looking trick into a useful, testable workflow. A PDF has to become musical data before a transposition command can act on notes, measures, voices, and lyrics. I wanted to know how much of that chain would survive outside a 59-second video, so I built a score we could legally share, ran the conversion, kept the failures, and compared the files.
The hidden step in the demo
In the original X post, Codex is asked to move a one-page Schubert score from D major to B-flat major while preserving the voice, piano accompaniment, markings, and two lyric verses. A separate two-page PDF appears at the end. That is interesting evidence of possibility, but the recording does not give us a note-by-note comparison, the recognition settings, or the intermediate MusicXML.
A lot of people will search for “transpose sheet music PDF with Codex,” but that phrase hides three different jobs: optical music recognition (OMR), symbolic transposition, and engraving. Codex can organize those jobs and inspect their files. It is not itself a replacement for the specialized recognizer or notation editor.
The distinction is supported by the product documentation too. The official GPT-5.6 Sol model page lists image input and tool support. It does not promise native OMR or musical accuracy. The “GPT-5.6 Sol Medium” label belongs to the source video; our local test is about the file workflow, not a benchmark of that model.
I built a score I could actually inspect
Using a famous score would have made the example feel more familiar, but it would also have introduced edition rights and an answer key we did not control. Instead, I created September Window: an original eight-measure song in D major with one vocal staff, a piano grand staff, two lyric verses, a tie, a slur, two dynamics, a crescendo, two articulations, tempo text, and repeat barlines.
You can download the source PDF, the B-flat review copy, or the complete evidence kit. The kit includes the raw OMR file, both failed setup logs, corrected MusicXML, correction ledger, scripts, and the unfinished musician checklist. In other words, the awkward middle is there—not just the tidy result.
| Test fact | Recorded value |
|---|---|
| Source | 1 A4 page; D major; 3 parts; 8 measures per part |
| Tools | Audiveris 5.11.0, MuseScore Studio 4.7.5, music21 9.9.1, Tesseract 5.5.2 |
| Requested move | Down a major third, exactly -4 semitones, to B-flat major |
| Compared material | 136 pitched noteheads, 72 note or chord durations, 50 lyric items |
| Release state | Automated checks passed; musician review open |
These are the core commands from the run:
brew install --cask musescore
python3 -m venv .score-env
.score-env/bin/python -m pip install --disable-pip-version-check music21==9.9.1
/path/to/Audiveris -batch -save -export \
-output artifacts/omr artifacts/september-window-source-d-major.pdf
.score-env/bin/python transpose_and_audit.py
mscore -o artifacts/september-window-transposed-b-flat-major-review.pdf \
artifacts/september-window-transposed-b-flat-major.musicxmlAudiveris was downloaded from its official 5.11.0 release because it was not available as a Homebrew cask in this environment. The exact app path varies by operating system, so the kit leaves that part as an explicit placeholder instead of pretending one command is universal.
The OMR failed twice before it became useful
The first batch run reached the text stage and reported that no OCR languages were installed. That was a clean, understandable failure. I added English data and tried again. The second model was the smaller Tesseract “fast” file; Audiveris requested legacy components that file did not contain, so the page completed without usable OCR.
The third run used the compatible full English model. It recognized the staves, most notes, and both lyric lines surprisingly well. It also produced a MusicXML file that would have been dangerous to accept on appearance alone.
| What the raw export did | What the source comparison revealed |
|---|---|
| Created 4 parts | The voice changed from “Voice” to “V.” at the system break and became two parts; the answer key had 3 parts total. |
| Returned 38 note objects instead of 40 | The last D4 in the voice and D2 in the piano bass disappeared. The preceding pitch-and-duration sequences matched exactly. |
| Returned 50 lyric items | The matching count was misleading: p and mf became lyrics while “today” and “again” vanished with the last note. |
| Added 2 first-ending brackets | The source had none. They were plausible-looking inventions over the piano system. |
| Kept 1 slur and 1 accent | The tempo mark, crescendo, tenuto, and both Dynamic objects were missing. |
| Kept all 32 right-hand chords | This entire chord sequence matched the authored source exactly. |
This is why raw totals are a weak quality signal. “Fifty lyrics before and after” sounds reassuring until you inspect which fifty items survived. The correction ledger records eight classes, with a location and evidence note for each one.
The workflow I would use on a real score
- Choose a lawful, readable source. Keep the untouched PDF, record its hash, and confirm that every page, edge, staff line, dot, and accidental is visible. The U.S. Copyright Office overview is a useful reminder that a composition and a particular edition can involve different rights.
- Run OMR into a named raw file. Audiveris describes itself as an OMR application for printed common Western notation and is candid that recognition remains imperfect. Its handbook is worth reading before assuming handwriting or unusual notation will work.
- Correct the original key first. Open the raw MusicXML beside the PDF. Fix parts, measures, pitches, rhythms, lyrics, and markings while every discrepancy can still be traced directly to the page.
- Transpose the corrected checkpoint. State both direction and interval. D to B-flat can mean down a major third or up a minor sixth; those keys are equivalent by pitch class and very different in register. MuseScore’s transposition controls can handle a selection or whole score once the musical objects are trustworthy.
- Compare structure, then read the score. Automate the boring invariants—counts, duration, interval, lyric fields—so a musician can spend attention on spelling, phrasing, alignment, ranges, collisions, and page turns.
The crucial checkpoint is the corrected source-key MusicXML. If you jump straight from imperfect OMR to a polished PDF, recognition errors become harder to distinguish from transposition errors. Keeping both files makes the work debuggable.
What our checks proved, and what they cannot prove
| Automated result | Evidence |
|---|---|
| PASS: inventory | 3 parts and 8 measures per part before and after transposition |
| PASS: pitch move | All 136 pitched noteheads moved exactly -4 semitones |
| PASS: duration | All 72 note and chord durations matched in sequence |
| PASS: lyrics | 50 items retained their text, verse number, and syllabic value |
| PASS: explicit marks | Tie, slur, dynamics, crescendo, tenuto, and accent remained present |
| OPEN: musical release | Enharmonic readability, exact visual alignment, practical range, and rehearsal use need a qualified reader |
The lyric check deserves emphasis. MusicXML can attach text, verse numbers, and syllabic position to individual notes; the MusicXML lyric specification defines those fields. Our comparison proves that the fields stayed equal after the corrected checkpoint. It does not prove that OMR attached every syllable to the right source note—that is why the source-key correction came first.
I also rendered both PDFs and inspected the pages for clipping, broken glyphs, missing staves, collisions, and obvious layout damage. They are clean review copies. I am leaving the score status as NEEDS_MUSICIAN_REVIEW, because visual polish and musical approval are different claims.
A shorter Codex prompt that leaves an audit trail
Help me transpose this printed score as a traceable file workflow.
Source PDF: [absolute path]
Source key: [key]
Destination: [key]
Exact move: [direction, interval, semitones]
Pitch convention: [concert or written pitch]
Parts expected: [inventory]
Lyrics expected: [language and verse count]
Use an installed OMR tool to create raw MusicXML, then an installed notation
tool to render the final score. Keep every stage in [output folder]. If either
tool is unavailable, report the missing dependency before changing files.
1. Hash the untouched PDF and record page count.
2. Export raw OMR MusicXML and retain its project and log.
3. Compare the raw file with the source in the original key. Record every
correction with a measure number; save a corrected-source checkpoint.
4. Transpose that corrected checkpoint by the declared interval. Save new
MusicXML and PDF filenames; leave the source untouched.
5. Compare parts, staves, measures, voices, durations, pitched notes, key and
time signatures, ties, slurs, articulations, dynamics, repeats, tempo text,
and lyric text/verse/syllabic fields before versus after.
6. Flag range and layout concerns without silently arranging the music.
Return a QA report with PASS, FAIL, or NOT CHECKED for every category. Label
the PDF NEEDS_MUSICIAN_REVIEW until a qualified reader has compared every
measure and approved pitch, rhythm, lyrics, expression, and engraving.For a real job, I would add the expected page count, exact part names, known pickups or key changes, and the reviewer’s delivery deadline. Those specifics help more than another paragraph of generic “be accurate” language.
Where Codex earns its place
If you already have clean MusicXML or a MuseScore file, open it in notation software and transpose there. A musician can often finish that job faster than an agent can describe it.
Codex becomes valuable when the input is messy or the job repeats: preserving source hashes, invoking several tools, naming checkpoints, comparing XML structures, collecting logs, rebuilding the PDF, and producing a review ledger. It can turn a fragile sequence of clicks into a repeatable folder that another person can inspect.
I would still avoid scaling from this single fixture to a library. Dense orchestral pages, handwritten corrections, cue staves, percussion notation, chord grids, and poor scans need their own representative tests. The honest next milestone for this article is smaller: have a qualified musician initial the eight-measure checklist, fix anything they catch, and only then change the score’s release state.
