I have some ideas for going to AGI sound from the editor. Where the resolution problem occurs is actually going from AGI sound into the editor, and I think it's mostly because right now I've got a very dumb algorithm that just calculates the 1/60 sec. durations of each basic note type and then finds the closest basic note type match for the duration of each note in the AGI file (that algorithm works pretty good for calculating the note names from the frequency value, but it's not so good for getting the musical notation from a duration value). A slightly smarter algorithm will probably do away with this problem. Also, I'm thinking about maybe saving a small data file to go with each AGI sound file that is edited so that the editor can remember things like tempo, whether the user was editing in treble/bass clef, etc. I'm not worried about the resolution loss in terms of being unable to handle really, really short notes at tempos 120 and above, because I don't think the interpreter can handle them, anyway, and I sort of want an editor that's as limited as the AGI Sound format. That way you can know immediately that what you're trying to do won't work.
As for the minimum time, I was asking what's the minimum amount of time that AGI can sound a note, not that the PC speaker can. I could also use information about what the minimum and the maximum frequencies are that AGI sound can play.
Slight variations in the time for each note should be ok, although the resulting notation when the sound file is loaded might be ugly to look at (it is when you convert the Sierra AGI sounds to midi, incidentally), but the sound files that my program will produce should be very constant about what the note durations are.