I think An Empeg Guy mentioned that custom shuffles can be definied on any arbitrary database field

Hm, I don't know about that. Based on some poking at the jEmplode code (which has a feature where it can generate the database for you) I don't think we can add our own fields to it. Having the player's custom shuffle functionality understand those fields (and address them by name) also seems unlikely. If you can dig up a post where this was advertised, I'd love to read about it, but I remember it being phrased more as "any numerical database field" and it had to be an attribute the player already knew about (Year and CTIME were mentioned, methinks.) In your example, how would the player know about the existence of the "x-rating" attribute?

Another thing that occurred to me last night is that this same strategy of taking over the writing of a fid's dynamic data may also give us the ability to implement a mechanism for marking tracks with different flags (which has been asked for.) There are 30 or so bits marked as "unused" in the dynamic data partition, right next to the "marked" bit. It esems to me that if a user app took control of the process of setting/clearing mark flags (including the existing one) this could be interesting. Of course, for this to be useful, jEmplode would need to be rewritten to understand these. I *believe* the whole dynamic data structure (including the unused bits) travels over to jEmplode, so it may actually work. Still need to prove this one out a little more, though.