Hey y'all

Since there's problems in storing some of the amarok data in the ID3 tags (because of an outdated library, iirc), or read some tags set by other mp3 managers, I have decided like an idiot to do this myself.

Currently I managed to read mediamonkey ratings and mood tags, copy the ratings into the amarok DB, and copy moods as labels and add them to the tracks.  I found out that the tag used by mediamonkey to store rating is actually a standard one (POPM). So I'll just reuse the same tag to store amarok ratings. I guess it has more chances to be compatible with other players then...

I'm now going to investigate the recording of the amarok DB values into id3v2 frames (which may turn out to be an utter and complete failure)

So after you have made great fun of me I'd like a couple of thoughts from you
- has this been done already (I have a weird feeling that it would save me a lot of time and frustration)
- what are your thoughts about amarok values that should be stored in ID3? I was planning on ratings only, but do you think scores or other values should be recorded in the ID3 also?

I would love having the "vote" (rating) value stored into the mp3 itself, is there a way to write a script able to do that?

G.

The rating is apparently a standard tag called POPM (Popularimeter)
What I'm not sure is if all players that read this tag use the same value in there, since it allows range 0-255 as values.

For now, I use Mediamonkey's values, but if anyone has a link to a "standard" way of using this tag, I'm buying.

I haven't worked on the script for a while, but once I have it almost finished, I'll post it here.

Being able to restore rating was what moved me to think about a script to move collections since most informations in the DB are stored with "absolute" path.

IvanSB wrote:Being able to restore rating was what moved me to think about a script to move collections since most informations in the DB are stored with "absolute" path.

You know I never really understood the logic in Amarok about this...  It looks like some track records in the DB are defined relative to a path that you find in the "device" table, some are absolute, and some even end up as duplicates in the DB 

I ended up assuming it's all relative, and assuming / is the device path if there is no device id that can be found in the track info...  But I'd still like to understand how the program decides how it stores what it stores