Here are some of my thoughts on the maintenance of the DT and contributions via Mudcat.

I think the DT needs to keep a central editor/editing team to maintain the definitive version of the DT.

However, in Mudcat instead of the ad-hoc adding of lyrics we have at the moment and users having to search throught the forum for songs not in the DT, why not have an actual Add Song form with all the appropriate fields to add the song to the online database, giving it a DT number. The index only needs a flag to indicate that it's not part of the release DT yet, but can be included in the browse and search DT functions. This will also make it easier for the editors to locate the new songs and produce the final release version later, flagging it as a release file.

Similarly corrections to the DT could be linked directly to the songs in the DT, including the provisional entries added by users. This could be just a link in the song entry pointing to the message or thread, but having it in the database will also make access easier for the editors later. In view of the fact that new additions often
have several corrections more or less immediately, it might be wise to allow the person who initially adds the words to be able to update them (possibly for only a limited time).

Tunes posted could similarly be linked directly to the song via a proper form for submission.

These options would allow the for the openness that some users have been requesting (a feature which is currently there but ad-hoc via the forum) while leaving final control in the hands of the editing team.

It should also make new releases of the DT easier to maintain, since you could do an incremental update of changed/added songs only.


As for the released version of the DT, I quite like the idea of a browser-accessed version. As Jon has shown above it takes nothing to generate the songs as HTML files (It's possible to clean them up a bit too - in the version I imported into Access, I had a program classify the various line types - title, song text, attribution, source, date, submittor, keywords etc. This information can be used to systematise the html).

Also if you generate midi song files suitably you can use a karaoke style player to play the tune with synchronised words. (abc2midi generates a suitable file if the w: tags are used in the abc for example). A java-based appelet would let you have platform-independence for this. While I do like the current player, having the printed music doesn't need to be tied to the karaoke style display - users of the printed score are less likely to be interested in the karaoke player and vice-versa.

That does only leave the printed score to deal with. While I can do that easily via postscript, the general user probably doesn't want to go to the trouble of installing Ghostview/Ghostscript or some similar postscript viewer, so I don't have a better solution for this at the moment.

By way of sizes related to tune files, I have just under 4000 tune files; the abc is about 11Mb, 4Mb zipped (these contain the full song text as well as the synchronised verse); the midi is about 24Mb, 5Mb zipped; the postscript (again including full text) 128Mb, 35Mb zipped. Based on the html for ARDTAC from Jon's site (around 3Kb on my machine), the 8000 or so text files should generate about 20Mb unzipped (and if I had to guess around 5Mb zipped - I haven't got enough to make a decent estimate).

I'm not saying this is the way to go, just offerning it up for thought.


Mick