Hi there... I\'m not so sure here is the best place to discuss this, but since most of the feature requests that had me make this suggestions came from here, let\'s go...

the thing is, I was trying to implement multiple artist support for Amarok when I actually started to read up on the code and study it a little. I think that to actually achieve support for multiple tags, be it genre, artist or whatever, you need to redesign the way the DB is built. Same thing for supporting new tags, like Composer, Conductor and so on...

may I suggest an approach where you have different tables for each kind of id3v2 Frame you wish to support, and tables that relate each frame to one or more songs... that way you can have a song with multiple artists/genres, and adding support for a new type of frame is straightforward, just add a couple of new tables to the DB....

I\'d really like to help with this, if you decide to go this way, because that would allow Amarok to fill a gap that no other player does, currently...

thanks for a great player.. see ya

I started thinking and realised that this IS quite the correct way we should progress. Unfortunetly we are NOT mp3 player but a music player, that means we don\'t follow just id3v2.4 tagging but instead we provide a generic for all the tags. But the thought itself is quite good and would be quite handy, as some tags have different language versions and stuff, and this would be the way to implement them. But we don\'t actualy have to change the current table, we could juts add the frame_tables improve the current tags table to link into frame tables in case of mp3.
Please not that restructuring of the amaroK database needs a great deal of thinking and probably won\'t be done in the near future as taglib still doesn\'t support full id3v2 support(and we are not keen about extending the support internaly atm).

That is true. Adding the tables is a good way of doing this as to disturb the least the current way the program works. Would a new DB format comprised only of added tables (no modifying or deleting tables) have binary compatibility with the current ones? I don\'t actually know that much about sqlite internals...

On a sidenote, I really think this is the way to go for amaroK \'cause, after this, supporting new kinds of frame, as taglib too adds support for them, would be a breeze. Be it id3v2 or any other format.

Hope this discussion is helpful down the road...

Talking about binary compadibility.. considering the amount of work done in cvs mostly i really doubt that any amaroK version besides berhaps 1.2.x series(probably not even these) are binary compadible with eachother.

But yes, just adding some tables into database won\'t affect the current way of working and is the right way of going at it. BUT i wouldn\'t expect any work to be done in the near future in this area as atm most developers are working on their own ideas that need polishing and work on 1.3 is being heavly done. I really doubt that we will do any major database redesigns in cvs before 1.3 release. That comes also from the fact, that we have to wait a bit for the taglib to catch-up Taglib 1.4 should include lyrics tag support.

I\'m certainly not a programmer, but I do have to say that multiple artist tags for one file would rock! It would let me get rid of all those ugly

Bob Feat: Jimmy - This song rocks

tags. It\'d be quite nice.