Jack Campin writes:
| If an index is zero, the entire file is returned; if nonzero, only that
| tune is returned.
|
| Does this mean that if I convert my tune files to have only zero indices
| for all the tunes, I can ensure that they are only downloaded or converted
| in their entirety?
Yes, I think this would work. Of course, there's a good chance that
other software would be confused by a file full of X:0 tunes. The X
index is used for selecting tunes, after all, and this would sorta
defeat that. I've heard that some of the ABC apps don't like X:0 very
much, but I suppose this would tend to get fixed after the author
gets a few bug reports.
This is probably the first time that I've seen someone trying to
intentionally defeat the users' intent by manipulating the X lines. I
suppose it had to happen eventually. If you find yourself looking at
such a file, there are a number of abc programs that can renumber the
tunes in a file.
A lot of abc files have illegal or dubious uses of X lines. Some time
back, I rewrote my Tune Finder's tune-extraction code so that an html
form can also include the title, which will be matched during the
extraction. This was to handle the problems caused by all the abc
files on the net that have duplicate X lines. It also solved the
problems caused by files that had been renumbered since the search
bot last indexed those files. I'm not abxolutely sure what my code
does if it gets both X:0 and a title. Maybe I'll do a bit of checking
to see what happens. I'd guess that it would ignore the title and
include all the file's tunes, but I'm not absolutely sure.
There is a great deal of plain sloppiness in how X lines are used.
I've generally taken the defensive programming approach of trying
to make the best of a bad situation, and try to fetch the tune(s)
that the user wants. This isn't always successful.
An approach that I and others have used is to combine tunes into
medleys using P lines for the titles. If you put a number of tunes
into a file this way, with one X line and one T medley title line,
my Tune Finder will treat it as one tune and return the whole thing.
Of course, you can't search for the P lines in such a file.
There is also the intermediate form of this, used at a number of
sites (including mine), where the tunes in a medley each have X and P
lines but no T line. My Tune Finder recognizes this, and uses P lines
if there are no T lines. The Tune Finder can extract individual tunes
from such files. There are also a number of sites with tunes that
lack both T and P lines. The Tune Finder can't handle this at all;
such tunes aren't in my index and can't be matched or retrieved.
I mostly use abc2ps, which actually handles all of these without any
problems. It's pretty good at dealing with fragments of abc. I've
used this at times, in producing small examples for some tutorials.
| What would other software make of this? (BarFly doesn't care).
| GGet returns entire file.
| AABC returns selected ABC tune as text/vnd.abc.
| TTXT returns selected ABC tune as text/plain.
|
| So you only get to control file type if you download tunes individually?
Yes; that's what the current interface does. I've been working on a
new web UI that might give more control. But it's not obvious how to
make a simple UI for such things. So far, most of my ideas have
produced something that I thought was too complex for the typical
user who just wants a tune. It should be noted that the current Tune
Finder is already too complex for some users. I occasionally get some
rather confused email from people who just can't figure it out.
The whole reason for the A and T links was to solve the problem that
browsers don't come configured to handle text/vnd.abc, and a lot of
users can't figure out how to do the configuring. I know several
people who tried once, and now IE hangs permanently when they attempt
to download a text/vnd.abc file. Also, there are a number of sites
that deliver abc as application/octet or some such, which is pretty
much unusable by almost everyone except browser gurus.
(Then there's the site that has plain-text abc files that are sent as
text/html. Jeez ... ;-)
These A and T links were intended as a way of overriding whatever
type a site sends for abc files, and return them as abc or plain
text, so you can at least get a tune in a usable form. I've thought
about doing something more general, but so far I don't have a good
design for the UI. The code behind it is running on a unix system, so
it has no problem with any supposed file type. It's just data. It
would be easy to send the data as any type, since a type is just
another string of data. But it's not obvious how to write the UI.
Some of this might fall into place with some new web pages I've been
experimenting with. I've had a number of
