In a recent post about a tune collection, a couple
of side questions arose regarding the abc coding and the number of errors I found in the file I was working
on. The largest number of errors I encountered were to do with incorrect abc syntax and mangled file headers,
many of which caused MIDI playback of the tune to foul up, but there were also an odd few howlers which
were straightforward musical nonsense...Most of the 'corrections' I make to an existing abc tune enable it to
be played back correctly via a MIDI player. The additions I make are generally to format the notation for printing
in a manner I find pleasing and legible and are very much a matter of personal taste.
Thank you Pete.
I agree 101% with everything you say in your post, particularly in respect of the 'archival' approach
to coding stuff for the VMP (though CP lets me 'get away' with a few departures from VMP SOPs).
Editing these 'legacy' files (which is what the original thread was related to) is a bit of a labour of
love, but my limited experience has led me to believe that there are sometimes gems in there which
may well not be found elsewhere, so it's 'worth it'...
Different folks have a different approach to this problem of editing (or correcting, cleaning-up, w.h.y)
these files. A few examples of what I do:
I find there are two types of file - I call them 'corrupted' and 'fragmented'. The 'corrupted' files contain
stuff like (for example)
A2.999999999993/1.9999999999997B/1.9999999999997 where clearly
A3/2B/2has been corrupted. It's often not as clear as that, and unless it's obvious how to fix it, I will usually
(reluctantly) delete the tune from the file. Life's too short...
I don't know how it happens (I find it difficult to accept the idea that the original transcriber did it on
purpose), but the 'fragmented' files contain perfectly valid ABC code, but broken up in a strange way. For
instance, the example cited above might be coded across two lines, thus:
A3/
2B/2or, several bars-worth of music is strung together withminimal 'punctuation' (bar lines):
"D"F>ED3/d/(3BdB(3ABAG>BA>FE/E/EE|"A7"AF>ED3/d/(3BdB(3ABAG>B A3"D"/2F/D/D/DD|"A7" A(note the single bar-line, the accompaniment chord within the
A3/2, and the end of line broken bar).
I will usually try and 'repair' such a tune.
Other things I do (the first two are a bit radical):
'Normalise' all tunes to a default note length of
L:1/8. This does lead in some cases to a slight increase in
the size of the file (surprisingly often, it leads to a decrease in the size of the file). It does means that
A2always stands for a crotchet,
B always stands for a quaver, etc... I find this very helpful.
Introduce 'white space' between all musical 'objects' where there would be white space in the printed score.
I find this improves readability and comprehensibility to such an extent that without it, I simply wouldn't
be able to use ABC (it is this departure from VMP SOPs which CP allows me to 'get away' with). It doesn't
actually increase the size of a file bya ll that much - remember - a lot of ABC files use more space for
the headers than for the actual music. In any case, a couple of the edits below will save some space...
Remove/delete/correct obsolescent/deprecated ABC code, eg: end-of line
!; instructions within
+...+ +fine+becomes
!fine!; chords within
+...+ +ABc+ becomes
[ABc]; removal of
E:; removal of unnecessary empty
or 'content-free' fields, eg:
N:Tune infos, etc.
Re-cast some constructs in a shorter form (thus saving space). For example
A3/2B/2 becomes
A>B and
A2>B2becomes
A3 B, etc.
Fix some clear errors. A favorite is using a slur when a tie is meant, eg:
(A A) should be
A- A. These look fine
in the printed score but can muck up MIDI playback.
Explicitly specify start/end repeats and start/end 1st/2nd play, ie:
|:...:|,
|:...|1...:|2...|]. Again these
can look OK in the printed score, or can be correctly interpreted by competent musicians, but the can muck up MIDI
playback if not correctly specified.
Carefully edit out unnecessary use of
[ and
], for example, they are not required in 1st/2nd play; in
|[1...:|[2...|],
they are unnecessary (*I have 'private' reasons for this one).
The previous two need careful application to the case of multi-voice tunes. Sometimes, start/end repeats are not
specified in 2nd and subsequent voices in order to avoid the appearance of multiple Volta brackets in 2nd and
subsequent voices. Again, this looks OK but doesn't play back correctly. The repeats need to be specified in full
and the extraneous Volta brackets suppressed with a
%%score 1|2 directive.
Fix text annotations which are presented as if they were accompaniment chords. Thus
"Text" becomes
"^Text"...
Go for a 'default' nominal line length of 4 bars/measures (as per VMP standard). This sometimes leads to a
line length in terms of characters which is 'too long', but the edit window in EasyABC (my preferred software)
is ~116 characters wide, so it doesn't happen often. When it does, I accept this and the subsequent
slight inconvenience of occasionally having to do a horizontal scroll...
Moving
W: fields to the correct position
after the tune code.
And so on, and on, and on...
I will always insert a comment line:
%A lightly edited tune from...immediately after the title line to make it clear to subsequent users that the tune/file has been edited by me.
That's the way I do it. Pete does it differently (chaçun a son gout
).
The effect can be to produce two completely different looking tune files - which sound exactly the same.
This is true of my edit and of Pete's edit of the tune collection which sparked this discussion.
Which brings us back to Pete's starting title for this spin-off thread - there are surely different ways to do
stuff, and I for one am not going to stick my neck out and say something is right or wrong - except when I'm
right, of course
...
[* My 'private' reasons are to do with preparing robust, well-structured ABC code as test data for a couple of programming projects I have in hand.]