I've resumed dreaming about on-the-fly playlist creation by querying the "attribute tag" database. This quickly leads to questions which could kill the idea:

Would it be possible to expand the empeg ID3 tag database to include additional fields? Might as well leverage the player's ability to read and store the database. Wouldn't need to see them in emplode or jEmplode, unless those programs rebuild the database.

In conjunction, how horribly would the database size expand if additional tag fields were added to EVERY record? For my dream program, maybe 15 more fields would be needed.

Or, instead of adding fields, could an existing field be used to store an encoded value which represents 15 additional fields. ie: Genre contains 15 character where each position in the string represents a tag and each character represents a predefined tag value. Then software could parse it (and desktop software could encode it).

If these things aren't remotely possible, then I'll just continue listening to the "Rock" genre on shuffle. I'd much rather query Genre=ProgressiveRock Vocal=Male Tempo=Fast Tonality=Minor Mood=Serious Timbre=Electric, if it fit my mood.

It's not really the number of database fields that matters here, but rather the additional size of the data in all of those fields.

How large will they be? Multiply by the number of database entries which have data in those fields, and there's your answer.

Eg. 15 fields, averaging 300 bytes of new data, with perhaps 400 tracks tagged with the new fields, equals 300 * 400 bytes or 12K. Not significant.

But if all 15000 tracks had 300 extra bytes, then this might (or not) trigger memory troubles on some players.

Generating a playlist on the fly, by selecting attributes etc.. will require a front-panel app to allow entry of the selection info, and then search through the database building up the playlist from matching entries. This could then be written out to one of the stored bookmark areas on the disk, and then activated. All on the fly.

Good idea!

Since you'd have to have an external app to read the data, does it really make sense to put it into the player database? If it were an external database as well, the player wouldn't run into the memory issues you refer to. Of course, the external app might.

Is there any advantage to storing that data in the the player database that I'm missing?

Well, I meant compiling it into a separate database that would be fast to search through, but which wouldn't increase the permanent in-memory load. Right?