A digital score can travel without arriving unchanged

John Philip Sousa studies the score of The Invincible Eagle March in 1901. William Nicholson Jennings's photograph catches a score in its oldest interoperability layer: marks arranged for another human to read. Library of Congress via Wikimedia Commons.[14]

A digital score can move cleanly from one open-source program to another and still arrive changed. The pitches may survive while a line break moves. The printed page may look right while playback chooses another sound. A browser may render every note while discarding scholarly annotation it never loaded. None of those outcomes proves that the software is broken. They reveal that “the score” was carrying several different promises in one file.

The open notation ecosystem works best when those promises are separated. MuseScore Studio is an interactive authoring room with native project files. MusicXML is the broad interchange contract. LilyPond turns text source into engraved pages. MEI can describe a musical document with a richer scholarly frame, while Verovio turns MEI and imported MusicXML into web-ready notation. PDF, SVG, and audio are delivery artifacts, not editable equivalents.[1][4][8][11]

This is therefore not a comparison in search of one winner. It is a map of ownership. A durable workflow names which representation owns musical meaning, which one crosses a boundary, which renderer owns layout, and which artifacts are frozen for readers. Openness makes every layer inspectable; it does not make the layers identical.

MusicXML is the bridge, not the whole building

MusicXML 4.0 describes itself as an open format for exchanging and archiving digital sheet music. Its common score-partwise form places measures inside each instrumental part; the alternative score-timewise form places parts inside each measure. That duality exposes the first hard problem: music is not naturally a simple XML tree. It is both a horizontal sequence within each part and a vertical alignment across simultaneous parts.[1][2]

The format carries real semantics—notes, durations, voices, ties, lyrics, directions, part identities—and a large vocabulary of display information. A compressed .mxl file packages the XML in a ZIP-based container. The Library of Congress preservation guide accordingly describes MusicXML as an open interchange format for sharing notation data across software platforms.[13] It can carry page and system information, but MuseScore's documented import cleanup is a practical reminder that it does not freeze a reading surface the way a reviewed PDF does.[3]

That boundary is a strength. A violin part can remain a violin part instead of becoming a picture of five lines. Another program can transpose it, extract it, restyle it, or render it for a different page. The cost is that a receiving application must interpret the representation. Its font metrics, spacing engine, defaults, supported elements, and import policy all participate in the result.

So “supports MusicXML” is only the first question. The operational questions are more exact:

Which MusicXML version does each side read and write?
Does the consumer preserve semantic structure, appearance hints, or both?
What happens to application-specific data for which the exchange format has no shared expression?
Is the handoff one-way, or will the file return to its originating editor?

A format badge cannot answer those questions. A representative score corpus can.

MuseScore owns the interactive editing state

MuseScore's native formats are .mscz and .mscx. Its export surface is deliberately broader: MusicXML, MEI, MIDI, PDF, SVG, audio, and other artifacts leave the application for different jobs.[4] That distinction should shape repository design. If musicians will reopen a score in MuseScore and continue adjusting notation, parts, styles, and playback, the native MuseScore file should normally remain the editable source of truth. The MusicXML export is a handoff, not a more virtuous replacement for the working file.

The project's own handbook sets an honest expectation. It says MusicXML preserves notes and instrumentation faithfully but that cleanup is usually needed to reproduce the original appearance exactly. Exporters can choose compressed or uncompressed MusicXML and decide whether to include all breaks or only manual breaks. On import, text positions and custom properties are retained as far as possible, then can be reset to MuseScore defaults.[3]

Those controls are not cosmetic footnotes. A publisher receiving a carefully paginated part may want manual breaks treated as requirements. A teacher importing an old score into a new house style may prefer to discard most positional history. Both are reasonable, and the same file cannot infer which intention matters more.

Maintenance activity also makes version capture worthwhile. MuseScore Studio 4.7.5 was released on September 8, 2026, after several 4.7 point releases; the release feed explicitly records import and MusicXML fixes among that series.[5] An export acceptance test should therefore record the exact writer and reader versions. “MuseScore 4” is too coarse when importer behavior can change between point releases.

LilyPond makes the engraving decision explicit

LilyPond begins from a different center of gravity. Its durable input is a text .ly file, and its renderer applies engraving rules to produce pages. The stable 2.26 documentation describes musicxml2ly as a converter that extracts notes, articulations, score structure, and lyrics from partwise MusicXML into LilyPond source. The same page warns that some MusicXML elements are low-level and graphics-oriented, making automatic conversion non-trivial and sometimes impossible.[6]

The command's switches reveal the ownership transfer. --no-page-layout can ignore imported margins and page or system breaks. --no-beaming and --no-stem-directions tell LilyPond to apply its own decisions. Other switches retain or suppress specific classes of information. Import is therefore source generation with policy, not a transparent tunnel.

Once a team edits the generated .ly, it has created a new canonical branch. Re-exporting from another editor and regenerating that file later can erase manual LilyPond work just as surely as overwriting source code with the output of a scaffolder. A sensible publishing pipeline imports once, reviews the generated source, commits it, and thereafter treats upstream score changes as merges that require musical and visual review.

The project is visibly maintained: LilyPond 2.26.0 became the stable release in April 2026, while the 2.27 line continued as a development series later in the year.[7] For reproducible engraving, pin the executable and font environment alongside the .ly source. Text is diffable, but identical text does not promise identical page geometry across renderer or font changes.

Verovio is a web component with a conversion boundary

Verovio occupies another part of the map. It is a portable engraving library whose native representation is MEI, with command-line, Python, and JavaScript toolkits. It can import MusicXML directly into its internal MEI model and render SVG for a browser. Compressed MusicXML takes a distinct path in JavaScript: .mxl data must arrive as an ArrayBuffer or base64 string and be loaded through loadZipDataBuffer() or loadZipDataBase64(), rather than the ordinary loadData() call.[8]

That API detail matters in production. It is the difference between a demo that handles uncompressed XML and an upload service that handles the files notation programs export by default. A robust boundary should inspect the file, select the correct loader, surface conversion warnings, and refuse to call a successful HTTP response proof of a successful score import.

Verovio can emit SVG, MEI, MIDI, and a JSON timemap. Its renderToMIDI() path produces MIDI data for a separate player, while timemap output connects score-time events to note identifiers.[9] Those affordances make it a strong fit for interactive editions: the application can render notation, highlight elements, coordinate playback, or navigate pages without operating a desktop editor on the server.

But Verovio's documentation is unusually clear about round trips. Unsupported MEI elements are not loaded and therefore are not preserved in MEI output; some analytical markup is normalized unless preservation is requested. Converting MusicXML to MEI through Verovio likewise produces one valid representation shaped by the toolkit's supported model, not an archival facsimile of every possible source intention.[9]

Version capture belongs here too. Verovio 6.3.0 was released in August 2026 with, among other changes, further MusicXML importer improvements.[10] A site that regenerates thousands of SVG pages should upgrade the renderer against a visual and semantic regression set, not merely accept a new package version because its API still initializes.

MEI asks what kind of document the score is

MusicXML's great advantage is broad interchange among notation applications. MEI begins from a wider documentary question. The Music Encoding Initiative describes its schema as a way to record both the physical and intellectual characteristics of musical documents, developed by a community spanning technology, librarianship, history, and theory.[11]

That makes MEI attractive for critical editions, manuscripts, variant readings, and research collections where the relationship between the notation and its source matters. It does not mean every MEI consumer implements the entire model. MuseScore, for example, says its MEI support focuses on MEI Basic, a subset intended for data exchange.[4] Verovio's rendering model has its own explicit support boundary.[9]

A Library of Congress research guide identifies MusicXML, MEI, and PDF/A as the three formats on which it focuses for exchange and long-term preservation of digital scores. It also warns that an archive may lack the originating notation software needed to open a native project file.[12] The combination is instructive. Structured notation supports future interpretation and reuse; a fixed page artifact preserves an approved reading surface. A preservation package can reasonably keep the native editor file, a validated interchange file, and a fixed rendition because each protects against a different failure.

Test a journey, not a checkbox

The smallest credible interoperability test is not an ascending scale. Build a compact “golden score” that contains the things your catalog actually depends on: multiple voices on one staff, transposing instruments, cross-staff notation, ties across barlines, repeats with endings, lyrics, chord symbols, dynamics, cue-sized material, percussion mapping, and deliberate system and page breaks. Add one or two historically awkward files from the real archive. The point is not to exercise every element in MusicXML; it is to make silent loss visible before it reaches hundreds of scores.

For every boundary, inspect four layers:

Musical structure: pitches, durations, voices, measures, tuplets, ties, repeats, transposition, and part order.
Reading surface: staff grouping, collision avoidance, line and page breaks, lyric alignment, cue size, and the relationship of directions to notes.
Performance interpretation: tempo changes, repeats, instrument mappings, articulations, and the difference between symbolic MIDI data and rendered audio.
Provenance: source hash, exporter and importer versions, chosen flags, validation result, warnings, fonts, and the human who approved the rendered output.

Run the score forward through the intended route, then perform a round trip only as a diagnostic. A MuseScore file exported to MusicXML and reopened should be compared with the original native score, not assumed equivalent because it opens. MusicXML converted with musicxml2ly should be reviewed as newly generated source. MEI emitted by Verovio should never overwrite richer canonical MEI until warnings and unsupported constructs have been audited.[3][6][9]

Automate what is stable. Validate XML against the versioned schema. Parse both sides and compare selected semantic invariants. Render pages and use image diffs to flag movement, while keeping a human in the loop for musically legitimate reflow. Listen to a small set of playback cases. Most importantly, store the fixtures and accepted outputs beside the pipeline so an upgrade changes visible evidence, not only a dependency lockfile.

Put authority where failure is cheapest

Different teams should draw different maps.

For a school ensemble or community arranger, MuseScore's native file can own the edit, MusicXML can serve collaborators using other notation programs, and PDF plus audio can serve performers. The workflow stays friendly, and the native file preserves the quickest route back to a correction.

For a publisher with code review and automated typesetting, .ly may own the edition. MusicXML is then an intake format, not a round-trip collaboration bus. The organization accepts the cost of reviewing imports in exchange for deterministic text changes and centralized engraving rules.

For a digital library or interactive scholarly edition, MEI may own the document model while Verovio is a pinned delivery component. Generated SVG, MIDI, and timemap files are replaceable caches. If the site needs to accept MusicXML, the import report and original upload stay beside the normalized MEI rather than disappearing after conversion.

The boundary condition is operational maturity. A two-person music group probably should not invent a schema-normalization service. An institution ingesting ten thousand scores should not rely on someone remembering which export dialog boxes they clicked. The larger the collection and the longer its intended life, the more valuable versioned schemas, conversion logs, golden fixtures, and multiple preservation representations become.

John Philip Sousa's desk in the cover photograph holds paper rather than XML, but the underlying contract is recognizable. A score has always had to carry intention across a boundary—from composer to copyist, engraver, conductor, player, or reader. Today's open tools make those transformations inspectable and repeatable. Their real achievement is not that a score stays perfectly unchanged. It is that a team can say what changed, where it changed, and which representation still has the authority to correct it.

cronfeed.work