Richard Robinson wrote: | On Mon, 8 Jul 2002, Jack Campin wrote: | > > Could we directly insert a little code at the beginning of an abc | > > file to exclude it from your tune finder, like for the robot | > > exclusion header in html files?
Actually that's not a bad idea. I've been a bit busy lately; not time to answer much email. But I'll try to get arount to it. But there are the contra-indications ... | > Mirroring is a major headache when using the Tune Finder - the way the | > ABC corpus is now, you can get up to twenty copies of the same thing. | > Something needs to be done to stop this getting any worse. Google's | > "do you want to see similar results?" is sensible. | | This is a problem, I agree. For John's TuneFinder, there would be the | additional problem of identifying the primary version, rather than | displaying an n-th generation copy and offering the primary as "similar" | to it. This *could* be done, given universal agreement on a sensible use | of headers. Umm, right ... Yah; I'm not holding my breath until we get universal agreement on such things. There is one kludge that could help now. We've had occasional suggestions that we use the F: header line to contain a tune's original URL. People to mirror tunes usually wouldn't bother changing this, so it could be a tipoff that the original is elsewhere. I responded to this suggestion by having the tune finder generate a F:URL line showing where it got a tune from. That way, if you ask for an abc version of a single tune, it contains the source URL, and you can use that information if you like. I've seen a few cases where tunes end up with several F: lines as a result. It did take a bit of experimenting to figure out how to handle line terminators. My first attempts to generate F: lines caused some people's software to choke due to mixed line separators. Finally I stumbled across what seems to be the solution: My code now just canonicalizes on the ASCII standard (only LF as a terminator). This does seem to work, at least for people who download files via a browser. I'd guess that it's because browsers try to put text files into their system's "standard" form, and they all know how to translate from standard ASCII to their system's form. | A case in point ... I've just managed to put a big update to my "Tunebook" | in place (less than ideal, because I'm going away tomorrow so won't be | able to deal with the inevitable glitches and bugreports for a couple of | weeks. Oh well, at least I've finally got the bulk of it done). Among the | changes, it fixes a series of *horrible* typos to Skinner's "the Spey In | Spate". These have been there since the thing started (?1994?), and will | continue to be perpetuated by every site that's holding copies, unless | they individually do something about it. I wonder how many of those people | have thought of using mirroring software ? ... in my case, there are now | headers that identify my version as mine, which TuneFinders could use, but | they'd have to know about all the sites that do that, on an individual | basis; and then there are copies that were taken before I put those | headers in ... bleaargh. One thing I've found impressive is how difficult it can be to get typos corrected. I sometimes get the feeling that people try hard to locate the oldest transcription of a tune, and give that to all their friends. Of course, for traditionalists, this isn't surprising behavior. But it does mean that an unedited version tends to propagate faster than a later edited version. Then there are the fun problems when files are reformatted slightly as they pass from one kind of computer to another. Especially when you use email, and line wrapping and/or quoted-printable encoding is done at various steps. Maybe some day this will be recognized as yet another way that music can be transformed. To subscribe/unsubscribe, point your browser to: http://www.tullochgorm.com/lists.html
