On Fri, 18 Jul 2003, Jack Campin wrote:

> >> I've been working on an Abc 2.0 proposal, which is a stripped-down
> >> version of 1.6.  Amongst other things, I removed most of the headers
> >> (notably A-G, X and Z, to avoid confusion with notes and rests).
> > In my view of things, removing the C:Composer field steps just over
> > the line in being too radical :0(  I really like to see this header
> > just under the title, where it doesn't get lost.
>
> Most of those are too widely used to be thrown away, though some
> are too vaguely specified to be given a reliable semantics.

Vagueness is a good reason to throw them away.  It would have to be 2.0
and not 1.8, since it breaks compatibility.  All the older Abc files would
still work, more or less, just like they do today, but the stricter 2.0
format would work a lot more reliably.  N:notes/narrative, I:indexing
info, and % comments would suffice for anything not essential to rendering
sheet music.  And anything non-standard belongs in a comment.

I've learned to take C:composer with a grain of salt... you never know if
it means "music by" "words by" "learned from" "after" or "in the style of"
unless it's written out in plain English, or Swedish "efter", Gaelic "le",
or whatever.  What's wrong with learning other languages? :)

It occurred to me, belatedly, that A-G,X,Z headers are only a problem when
they're used within music.  The package-dependent E: header is the only
example I know of.  However, if we drop the requirement that headers come
before the music, we'd better play it safe.

Anyway, here's an example:

T:title
W:music by ...
W:words by ...
N:sources, discography, books, history, transcription notes, etc.
% From http://...
L:1/8  M:2/4  Q:1/4=120  K:G dorian


> E: is surely up for grabs now.  I've previously suggested re-using
> it for a universal identifier that would encode the transcriber's
> identity and provide a dated checksum for the tune, to make ABCs
> traceable and verifiable far into the future as they get copied
> and migrate.  This would be a doddle for an editor like JedABC to
> implement, or do with a standalone Perl utility script, but since
> it has very long-term implications it has to be done in a way that
> suits all imaginable platforms and implementors.

That might be nice, but it's hopeless.  One little tweak, and the checksum
is gone.  Besides, you can't expect musicians to use Jed or Perl.  Tune
comparison software is the best bet, and it's still basically hopeless :)

Tom
To subscribe/unsubscribe, point your browser to: http://www.tullochgorm.com/lists.html

Reply via email to