This question came up in a discussion on Meta, and I thought it might be a good question to ask on the general site.

ABC notation is a relatively simple text-based format for writing music scores and sharing them online. It was originally written for folk tunes, but is general-purpose enough that it has been used, for example, to notate a movement of a Beethoven Symphony.

I get the feeling that it is not as fully-featured as other text-based score-writing formats (such as lilypond or MusicXML), but I've not used any of these systems enough to get a good feel for what the differences are.

So what, specifically, are the limitations of ABC notation, compared to a fuller-featured system? Note that I'm especially looking for limitations inherent to the format, rather than limitations of any tools that work with the format. I'm also curious about how major or important these missing features are, but that's probably too subjective of a question for this site, since everyone will have different goals.

  • 1
    Hi. I've changed the title to your question, in hope to better capture the intention. If you think I've missed your point, just revert it. Cheers. – Meaningful Username Sep 23 '14 at 17:23
  • 2
    Thanks. I think I understand the intent of the edit, but the new title ("Is the... format complete") is almost certainly "no", given the potential level of complexity in scores. The question isn't one of completeness, so much as understanding in what ways it isn't complete. I've tried to capture this in another edit. – Caleb Hines Sep 23 '14 at 17:28
  • It is important to realize that this question is about the ABC-format that gets parsed into actual sheet music. It's not about the very simple ABC-format that we sometimes use when we don't feel like including images in our posts. I had written three paragraphs for an answer before I realized this... :-) – Lee White Oct 14 '14 at 5:47

My sense (after writing parsers for ABC, MusicXML, Cappella, Noteworthy, and about 6 other formats; and output to Lilypond, etc.) is the limitations of ABC, the format, cannot be completely separated from the limitations of ABC parsers. As both Kevin and Chris noted above, the ABC format has the capacity to encode much of the complexity of MusicXML and Lilypond and other formats, so it is not especially limited with respect to those formats (though the precise formatting and layout options of MusicXML and Lilypond, necessary for storage of a score that can be reconstructed, are rudimentary).

The limitations arise in that an ABC parser cannot know from the data format what types of ABC extensions or seldom-used features it may encounter at any moment or how the language may evolve in the future. As far as I am aware, there is no formal grammar for a well-formed ABC document that would let a programmer know where the following chain of elements (lyrics, voices, etc.) would end. Contrast with MusicXML where the XML format of <tag>contents</tag> has a sort of encapsulation that is easy to parse and can be tolerant towards future changes in the specification. (Lilypond is harder to parse or generate in this way, but it does have a grammar specification that can help). The difference means that MusicXML readers (or the few Lilypond readers) can know whether a file is well-formed in advance, and selectively parse or read elements that may or may not be relevant to the task. With ABC notation, it can be extremely difficult to skip information that may be correct but from a different (older or future) standard.

Because it evolved from a (great) way of simply editing music, some aspects of the implied grammar are contradictory or and can lead to very different output depending on which parser or interpreter is used. For instance, the 2.1.1 (dev) spec says, "A percent symbol (%) will cause the remainder of any input line to be ignored." however, later "A stylesheet directive is a line that starts with %%, followed by a directive that gives instructions to typesetting or player programs." (as in the %%score directive above). Such non-standard additions let the format grow according to the needs of the community, but make parsing of important features difficult and leave a somewhat non-standard standard. Important constants or attributes, especially in these directive signs, are left undefined: one can see that there is a "%%papersize" directive, which can be followed by "A4", but is the US version of this directive "letter" or "8.5x11" or "8.5" or "8.5/11"? In Lilypond or MusicXML such constants are well-defined.

If the OP wants more specific limitations rather than philosophical, some important ones: little or support for tuplets beyond basic information (how they should be displayed (number, ratio, no sign), nested tuplets, placement in metronome/metric modulation marks); many fewer ornament (decoration) signs; support for early music signs (full in Lilypond; a few in MusicXML) and contemporary notation symbols (diamond harmonics; cluster chords; microtones etc.; full in Lilypond; some in MusicXML); control over positioning of grace notes, in particular grace note groups in multiple parts (useful for a Beethoven symphony); different key signatures in different parts (very important for Beethoven symphonies; needed even after the transposition settings are complete since trumpets should not have marked key signatures in any transposition). Richer metadata (arranger, copyright [for the piece, separate from the encoding]), precise control over bar numbering schemes. Rich instrument playback support (in MusicXML 3.0; as opposed to pure MIDI number).

None of that is to say that ABC is a limited format -- it's incredible for making simple things simple and writing music by hand in a text file, but for something as large as a Beethoven symphony, I believe that the limitations will make it a vexing choice.

(edited:) You asked if there was a non-subjective way to decide how important these features are; I tried to answer in the context of notating Beethoven symphonies, since you used that example, but let me answer in the context of how people might use notation here, maybe a bit less subjective. For questions about "What does X obscure symbol mean?" It'll be much more possible to make that symbol in Lilypond or MusicXML (assuming it's a baroque trill sign, a contemporary notation sign, etc.); of course the questioner probably couldn't use it in his question, since he'd have to know the name for it, but an answerer could use it in her response. Guitar chords are often discussed here; they can be written in ABC, but except for this list they have no semantic meaning (treated like text expressions); they are fully supported in both other formats (along with figured bass for baroque music questions). For theory questions ("What's an augmented 6th chord") ABC would work fine and be much easier to enter.


There are a number of features planned for abc notation - major updates for v2.2 and v2.3, as well as a number of minor proposals.

abc v2.2 is mainly concerned with "sort[ing] out ambiguities and incompatibilities in multi-voice music", relating to the 'control voice'. As far as I can see, both Lilypond and MusicXML have fully-fledged multiple voice functionality. abc appears to have a few scope ambiguities, detailed here, and clef ambiguities.

abc v2.3 will be looking at markup and embedding; "i.e. embedding of abc within other document types and embedding of other markup types within abc documents". Lilypond can be embedded within Latex, and allows Scheme to be embedded within itself - I'm sure there are other examples too. From what I gather, abc has no functionality here.

More minor (and more defined!) future plans include:

Transposition: It's currently possible to transpose a lilypond script using \transpose frompitch topitch musicexpr and MusicXML has a <transpose> tag - abc notation doesn't seem to have any method of transposition yet.

A Syntax for creating medleys of tunes. Here, MusicXML has the opus file format, and Lilypond an option for multiple \score blocks.

All information found from the abc notation wiki and Yahoo group. (retro!)

  • There's the opus file format for MusicXML and the multiple \score block coding for Lilypond, but for simplicity in creating medleys of tunes (and support for parsing), nothing beats ABC. – Michael Scott Cuthbert Oct 19 '14 at 0:10

ABC Notation is a wonderful notation language that a number of people prefer to Lilypond. Many of the limitations of ABC Notation are not in the notation but in the implementation of tools. Before ABC Notation 2.1 the main limitation was in the writing of multiple voice music, but this has been addressed in ABC Notation 2.1 and will be finalized in ABC Notation 2.2.

Example (from ABCnotation.com):

    T:Zocharti Loch  
    C:Louis Lewandowski (1821-1894)  
    %%score (T1 T2) (B1 B2)
    V:T1           clef=treble-8  name="Tenore I"   snm="T.I"
    V:T2           clef=treble-8  name="Tenore II"  snm="T.II"
    V:B1  middle=d clef=bass      name="Basso I"    snm="B.I"  transpose=-24
    V:B2  middle=d clef=bass      name="Basso II"   snm="B.II" transpose=-24
    %            End of header, start of tune body:
    % 1
    [V:T1]  (B2c2 d2g2)  | f6e2      | (d2c2 d2)e2 | d4 c2z2 |
    [V:T2]  (G2A2 B2e2)  | d6c2      | (B2A2 B2)c2 | B4 A2z2 |
    [V:B1]       z8      | z2f2 g2a2 | b2z2 z2 e2  | f4 f2z2 |
    [V:B2]       x8      |     x8    |      x8     |    x8   |
    % 5
    [V:T1]  (B2c2 d2g2)  | f8        | d3c (d2fe)  | H d6    ||
    [V:T2]       z8      |     z8    | B3A (B2c2)  | H A6    ||
    [V:B1]  (d2f2 b2e'2) | d'8       | g3g  g4     | H^f6    ||
    [V:B2]       x8      | z2B2 c2d2 | e3e (d2c2)  | H d6    ||



  • Do you know some of the current limitations? If there are no significant limitations, that is also good information. – Meaningful Username Oct 16 '14 at 15:38
  • 1
    Multiple voices is the only limitation I know of and that is provisionally resolved in 2.1 and should be permanently resolved in 2.2. – pro Oct 16 '14 at 15:40
  • 1
    Judging from this example, for more advanced example, it's on par with lilypond for readability. For simpler examples, ABC is much more readable. – Meaningful Username Oct 16 '14 at 15:41
  • 2
    Added <pre></pre> tags, that keeps the jTab away. It is quite annoying, hopefully a fix will be implemented now that we're showing on the radar. – Meaningful Username Oct 16 '14 at 15:46

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.