Balisage Paper: The Road Not Taken

Motivation and Introduction

The idea for this paper originated in September of 2025, when the author joined a local choir. The choir's repertoire consists of sheet music written to be sung in four-part harmony. The four vocal parts, from highest to lowest pitch, are soprano, alto, tenor, and bass. The acronym SATB collectively identifies the parts. During group rehearsals, a piano accompanist plays starting notes for each of the four SATB parts. This is necessary because most singers lack perfect pitch, also known as absolute pitch, and must rely on relative pitch to sing the notes as shown on the music score [Mustafoev 2025]. However, when choir members practice their parts at home on their own, no one is available to provide the needed auditory cue for sounding the correct pitch. Therefore, an IT-savvy choir member creates practice tracks in MP3 format for each of the four parts.

Curiosity led the author to learn more about the practice track creation process. His fellow choir member reported that she uses commercial software to digitize each printed sheet music score, extract the individual SATB parts, and generate an MP3 practice track for each of the four parts. The author, attempting to replicate this process, discovered the world of music notation software. Much to his delight, he found that XML plays a major role in enabling these software applications to interoperate.

Music notation software enables musicians and academic researchers to edit and analyze musical scores, convert them into audio formats, and share them in searchable databases. Underpinning these software applications is an ecosystem of languages and data formats that enable data exchange between notation authoring tools, digitization of printed sheet music scores, and generation of audio renditions. Music notation is more than just a series of notes on a staff. Notations may be instrument-specific, for example, rhythm notations applying specifically to percussion instruments, or tablature notation specific to guitars and other fretted instruments. Notations for rhythm guitar may include both beat patterns as well as tablature. Tablature may also include notes on a staff specifying a melody such as a lead solo. There are multiple ways to slice and dice this ecosystem. Standards may be architectures at an abstract level, vocabularies defined as markup languages, markup-adjacent text-based formats, or binary audio data formats. This paper's focus is on standards for representation and exchange of the music notations themselves, in particular MusicXML [MusicXML 2021], which is widely used in software and is capable of representing a wide variety of notations for a broad range of instruments including voice, wind, percussion, bowed, and fretted instruments.

To provide a good illustration of MusicXML usage today, this paper discusses in depth the aforementioned real world scenario of creating audio practice tracks from sheet music for singers in a choir. The next section provides an overview of music notation markup languages, emphasizing those that influenced MusicXML's development. The following section presents a software-agnostic MusicXML-enabled workflow for producing practice tracks. Next, the paper shows results from a case study creating practice tracks from actual choral sheet music using a notation software application that supports MusicXML. A person who has read this paper should gain an appreciation of the importance of markup technology to musicians and of markup design choices to a music notation standard's success.

Music Notation Markup Languages

The first proposed standardized markup language for music was the Standard Music Description Language (SMDL), an SGML application. It was inspired in part by Mockingbird [Maxwell & Ornstein 1983], an experimental visual music notation software application developed in the early 1980s. SMDL, proposed in the late 1980s, defined an abstract music representation encompassing four domains: logical (the composer's intent), gestural (how the music actually sounds when performed), visual (how the sheet music looks), and analytical (opinions and commentary regarding the other three domains).^[1] These concepts were further refined, expanded, and incorporated into another SGML-based standard: the Hypermedia/Time-based Document Structuring Language (HyTime) ISO/IEC 10744:1992 [Newcomb, Kipp & Newcomb 1991]. SMDL was subsequently standardized as an application of HyTime in 1996. Neither SMDL nor HyTime achieved commercial acceptance. However, ideas from both have influenced subsequent music notation markup languages.

Two such music annotation languages, first introduced in the early 2000s, are the Music Encoding Initiative (MEI) and MusicXML. Both are defined in XML rather than SGML. Although distinct from the Text Encoding Initiative (TEI), MEI shares some of TEI's characteristics. For example, MEI is both a markup language and a research community, and it uses the One Document Does-it-all (ODD) literate programming approach as a single source for its schema, documentation and project-specific customizations. Also, TEI XML developers helped the MEI community with using ODD. MusicXML, unlike MEI, is less focused on scholarly research and targeted more toward developers of notation software for musicians and publishers. Both standards have achieved success in their respective communities.

Figure 1

Relationship between standards.

Figure 1 illustrates the lineage of MusicXML and MEI and conceptual influences of SMDL and HyTime. Solid lines leading to MusicXML and MEI indicate that both are defined using XML and that MEI has architectural similarities to TEI. The dashed lines leading to them show the conceptual influence of SMDL's modes. The timeline on the left indicates when each standard was first approved. Thus, although SMDL predates HyTime, it was later standardized as an extension of the HyTime architecture. Also, although initial versions of MusicXML and MEI date from over twenty years ago, both standardization communities are still active today.

MEI and MusicXML serve different communities and their design approaches differ significantly. Yet both were influenced by SMDL's four abstract domains. MEI uses the SMDL domains as a roadmap for ensuring that MEI markup is detailed enough to meet the needs of the scholars who use it. Therefore, MEI markup contains a rich amount of metadata and is able to represent notations from non-Western cultures as well as notations no longer used in published music today [MEI 2025]. MusicXML's use of the SMDL domains is more prosaic in that MusicXML adopts the convention of using elements to represent logical and analytical concepts and attributes to represent visual and gestural concepts. Also, MusicXML's developers used the SMDL domains to guide translator development, ensuring that MusicXML translators would be able to handle data in the logical, visual, and gestural domains [Good 2006]. Unlike MusicXML, which prioritizes clarity over concision, MEI prioritizes concision over clarity, resulting in compact markup whose element and attribute names are abbreviations with meanings obscure to anyone who has not studied the MEI schema documentation [Good 2006]. This is illustrated in section “Case Study: Bass Practice Track”, which includes examples of MusicXML and MEI markup representing the same notations. MEI and MusicXML markup are not intended to be interchangeable with one another. Although markup conforming to MEI Basic, a subset of the full MEI schema, is transformable to MusicXML and vice versa, the conversion is lossy.

Two de facto notation standards worth mentioning are ABC and ChordPro. Both are text-based (not SGML or XML) formats that have been around since the 1990s and are widely used to this day. ABC is a full-featured notation language popular for representing traditional and folk music. Conversion tools are available for translating between ABC and MusicXML. ChordPro is a lightweight format popular with guitarists. ChordPro can intersperse chords within song lyrics and can accommodate embedded markup, ABC fragments, and alternate tunings and note naming systems. In their investigation of the feasibility of Invisible XML (iXML) for analyzing and comparing the music of different rock and roll bands, Simons and Beshero-Bondar [Simons & Beshero-Bondar 2025] had initially considered using MEI for their work. Deciding that MEI was too complex for their use case, they instead created an iXML grammar that generated a simpler XML markup directly from readily available ChordPro representations of the songs they were studying.

A Workflow for Producing Practice Tracks

As an illustration of how musicians might use MusicXML, this paper revisits the scenario described in section “Motivation and Introduction”, where software is used to create audio practice tracks from SATB scores. Figure 2 illustrates a possible software workflow for creating these practice tracks.

Figure 2

A possible workflow employing MusicXML to produce practice tracks.

The process begins with the IT-savvy choir member being assigned the responsibility of creating practice tracks. This person scans the sheet music, saves it as a PDF, and uses Optical Music Recognition (OMR) software to generate a MusicXML encoding from the PDF. The practice track creator then uses notation authoring software to render the MusicXML as a music score. Because sheet music contains a diverse array of symbols, which in turn have a rich variety of semantics, OMR is seldom flawless for input as complex as an SATB score. Therefore, the practice track creator uses the notation software's graphical user interface (GUI) to correct OMR mistakes and then generate and save individual soprano, alto, tenor, and bass parts. These individual parts are saved as playable audio tracks in a standard format such as MP3. Notation software often generates SATB audio tracks such that lyrics are in a la la la form where the target voice (e.g., the bass) is louder and the other voices (e.g., SAT) are at a lower volume. Practice tracks may also be saved as PDFs for human viewing.

This workflow assumes the practice track creator is running a desktop notation software application that does everything except the OMR. There are many other possibilities. For example, the notation software could include OMR functionality. Or conversely, the notation software's functionality might be limited to authoring and require the use of separate tools for isolating the parts, and converting from MusicXML to MP3. Yet another possibility is that all of the software resides in the cloud and is accessed through the practice track creator's browser. MusicXML's ability to represent both presentation and the underlying semantics of the musical score enable this implementation and workflow flexibility.

The motivation for this paper, i.e., the need to create practice tracks for choir members, is amenable to a workflow where MusicXML is a good fit. As a counterexample, consider Cashner's digital workflow for his research on 17th century music [Cashner 2024]. Low-cost music notation software with an authoring GUI did not meet Cashner's requirements. Therefore, he implemented a workflow utilizing MEI to enable digital editions and data mining and LilyPond, a text-based music engraving software package (analogous to LaTeX, but for music notation), to handle the symbology and semantics of the music editions central to his research. His workflow included his own extensions to LilyPond plus a tool to convert from LilyPond syntax to MEI XML.^[2]

Case Study: Bass Practice Track

The author sings in the bass section of his choir. Therefore, this case study demonstrates how a choir might use readily available software products, that in turn use the MusicXML standard, to create a practice track for the author and his fellow bass section members. The song of interest is Randall Thompson's SATB score for Robert Frost's poem The Road Not Taken, part of Thompson's Frostiana collection of Frost poetry put to music [Thompson 1965]. Figure 3 shows a screen capture of the printed score's first seven measures (delineated by vertical bars). The first three measures and most of the fourth are a piano introduction with no vocals. The soprano, alto, tenor, and bass voices begin on the last beat of the fourth measure.

Figure 3

First seven measures of The Road Not Taken.

The case study uses MuseScore Studio, a desktop notation application that, in addition to providing a GUI for authoring and revising a score, uses the Audiveris OMR engine for importing a PDF score and converting it to MusicXML. Figure 4 shows the isolated bass part from Figure 3 as rendered in MuseScore after PDF import and correction of minor OMR glitches. Because the bass part does not start until the fourth measure, the Musescore-generated notation compresses the first three measures into a single thick horizontal line with the number 3 on top.

Figure 4

First seven measures of the bass part rendered in MuseScore (with corrections).

The XML listing below shows a subset of the MusicXML for the bass part that MusicXML exports. The subset represents the measure following the compressed initial three measures. This measure is rendered as shown in Figure 4 and contains sequentially:

<measure number="4" width="171.33">
  <note default-x="12.5" default-y="-20">
    <rest/>
    <duration>8</duration>
    <voice>1</voice>
    <type>half</type>
  </note>
  <note default-x="79.8" default-y="-20">
    <rest/>
    <duration>4</duration>
    <voice>1</voice>
    <type>quarter</type>
  </note>
  <direction placement="above">
    <direction-type>
      <dynamics default-x="3.1" default-y="9.1" relative-y="10">
        <pp/>
      </dynamics>
    </direction-type>
    <sound dynamics="36.67"/>
  </direction>
  <note default-x="124.66" default-y="-25">
    <pitch>
      <step>C</step>
      <octave>3</octave>
    </pitch>
    <duration>4</duration>
    <voice>1</voice>
    <type>quarter</type>
    <stem>up</stem>
    <lyric number="1" default-x="6.5" default-y="-40.32" relative-y="-30">
      <syllabic>single</syllabic>
      <text>Two</text>
    </lyric>
  </note>
</measure>

The XML listing below shows the same measure exported as MEI. MuseScore implements the export with Verovio, a music notation library designed for MEI. Notably, the exported MEI is more concise than the MusicXML, but less human-readable due to its heavy use of attributes, abbreviations such as oct and dur, and an @xml:id for every element. The result is a format that is more amenable to scholarly musicological analysis using tools developed for the MEI community, but less accessible to non-musicologist musicians and software developers.

<measure xml:id="mqrhlpb" n="4">
  <staff xml:id="m2s1" n="1">
    <layer xml:id="m2s1l1" n="1">
      <rest xml:id="rpgiist" dur="2" />
      <rest xml:id="r1iwepaa" dur="4" />
      <note xml:id="nsv8ryt" dur="4" pname="c" oct="3">
        <verse xml:id="vdxhjv3" n="1">
          <syl>Two</syl>
        </verse>
      </note>
    </layer>
  </staff>
  <dynam xml:id="d17vt7ug" label="pp" staff="1" startid="#nsv8ryt">pp</dynam>
</measure>

The case study concludes with creating audio practice tracks from the first seven measures of The Road Not Taken score: the first a full track with all four SATB voices plus piano accompaniment and the other with the bass voice emphasized more than the SAT voices. This is done using the MuseScore Studio Mixer GUI and playback toolbar to adjust volume levels, and MP3 export to create audio files playable on any digital media player. MuseScore's default playback sounds are choral Aahs for the SATB voices and a grand piano-like sound for the accompaniment. MuseScore generates MIDI data from a score using its own internal sequencer and then uses the open source FluidSynth software synthesizer to convert the MIDI into MP3 or other audio output formats.

Conclusion

The developers of SMDL, MEI, and MusicXML all faced design choices or, as Robert Frost might say, a divergence of roads. SMDL chose the road of abstraction and ambitious scope, leading to some useful categorizations of music information but no implementations. An imperfect but useful analogy is that SMDL is to MusicXML as SGML is to HTML. Although more powerful representationally than HTML, SGML was hard to implement and was rejected by most software developers. When web software developers found HTML to be inadequate to meet their customers' needs, technologies such as Cascading Style Sheets, JavaScript, and JSON were deployed to compensate for HTML's limitations.

Developers of XML-based music languages faced a choice between concision and completeness. MEI favored concision, leading to a feature-rich language suitable for musicologists but less so for non-researcher musicians and the software applications that serve their needs. MusicXML chose a road that minimized the effort required by music annotation software developers to support the standard, even if it meant less concision and more redundancy in the markup. And, to the author and other musicians who use notation software, that has made all the difference.

Acknowledgment

The author thanks Robin Beahm for explaining the process she uses to create practice tracks for the Rockville Chorus. This was immensely helpful in developing the workflow and case study described in the third and fourth sections. He also thanks the Balisage peer reviewers for their helpful suggestions and corrections.