>> [header fields A-G] 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 where does that leave all the uses that have nothing to do with sheet music? Look at my G.S. MacLennan tune file and see what I'm doing in the second half of it - try typesetting that! One of ABC's neatest features is that you can transcribe stuff in a two-stage process; first create headers to act as bibliographic entries, and add the bodies later when you get time (or in the case of that GS stuff, when I get permission). You still have a useful tunography even if you never get round to doing the bodies; in fact ABC could be useful to DJs for exactly that purpose - they need to know the discographic reference data, BPM, duration and key of the stuff they'll be mixing, but they'll never need a score (though a MIDI might help). Where does your "I:" come from? Nobody's discussed that here. > 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 That breaks existing conventions for "W:" - it's for lyrics that aren't to be printed aligned with the tune. And it makes searching for the information you've dumped in the "N:" field insanely difficult. If I want to know which tunes I've taken from a particular book, I will launch a search for the "B:" line and nothing else. "N:" fields are a grab-bag that can contain absolutely anything; some kinds of searching need structure. You also MUST have a way to identify the transcriber - that's what the "Z:" line is for. >> 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. That's the point. It identifies when you've got something identical to the original, so that if you suspect there have been some tweaks you'd rather do without, but the "E:" field is intact, you can go find an untweaked version, even if the originating site is long gone and all the copies are in mirrors or recompilations. And it gives you a quick way to avoid storing exact duplicates of stuff you've already got (unedited duplicates account for a sizable proportion of the ABC on the web). > Besides, you can't expect musicians to use Jed or Perl. Any program that can compute the signature and stick it in the tune or file header will do the job. What I had in mind is a utility that adds the digital signature before you upload stuff to the web or pass it on in some other way. It could be nearly as seamless as the way MS Word adds identifying info to its documents. If you care about where your stuff is going to end up (as anybody doing it for commercial reasons will) you'll use it. The only bit that has to involve significant effort is getting registered as an originator in some public way; this need not involve a central registry but it does need a public, agreed protocol and it needs you to put the same data into your local configuration that you've told the world about (much like registering with a search engine). After that's been done, it's trivial to use the mechanism. > Tune comparison software is the best bet, and it's still basically > hopeless :) Tune comparison does nothing to tell you what the original is or help you find it. It serves entirely different purposes. ----------------------------------------------------------------------------- Jack Campin: 11 Third Street, Newtongrange, Midlothian EH22 4PU; 0131 6604760 <http://www.purr.demon.co.uk/jack> * food intolerance data & recipes, Mac logic fonts, Scots traditional music files, and my CD-ROM "Embro, Embro". ------> off-list mail to "j-c" rather than "abc" at this site, please <------ To subscribe/unsubscribe, point your browser to: http://www.tullochgorm.com/lists.html
