Amarok - Import MP3s with Ratings

Help
1

I am attempting to move my MP3 music collection from Media Monkey(MM) on Windows to Amarok on Debian 13 while preserving the ratings that are stored within the MP3 ID3v2 tag. I’ve gone part way into this journey but I am now stuck.

Concepts I’ve already come to understand in my research:

  • When adding MP3s to the collection, Amarok imports all ID3 metadata fine, just not the ratings.
  • Ratings are stored in the Popularimeter(POPM) frame in ID3v2.
  • POPM stores a 0 to 255 ranged value that each program uses in their own way.
  • Amarok appears to use it’s internal DB as the source of record for ratings.
  • When using the Amarok GUI to set a rating on a MP3, it stores it in the DB and copies the rating successfully in the POPM frame on the file, which is why…
  • I have figured out the POPM values that Amarok uses for each rating (using ExifTool to view the metadata).
  • I also figured out the equivalent values that MM uses for each rating.

I wrote a script to convert those MM values to Amarok equivalent values, saved those in the POPM frame on file successfully. But this is where I’m stuck. When I import, Amarok doesn’t import the ratings upon adding the MP3 into the collection. Even though, as far as I can tell, I’m using all the same POPM values that Amarok uses. I figured I must be missing something. Is there a way to force Amarok to read the POPM value when importing the MP3?

2

A good question!
Never used the functionality myself, but looking at the source code, I believe you have to have Settings → Metadata → “Write statistics to file” enabled for Amarok to read ratings from files (the logic being: otherwise the statistics would get read from the files, but wouldn’t be updated if you changed the rating in Amarok).

1 Like
3

Thanks for the reply. I believe I have had the “write statistics to file” selected ever since the beginning, which is how I was able to see which POPM values Amarok was writing to the file when editing ratings through the Amarok GUI.

But just to be extra sure, I tried it again. Here’s the steps I performed:

STEPS:

  1. I confirmed “write statistics to file” is checked.
  2. Deleted all tracks from collection and local storage. (It’s now empty with no tracks in collection nor playlist)
  3. Quit Amarok, then restarted Amarok to confirm it stayed empty upon restart.
  4. Quit Amarok again.
  5. Copied MP3s from backup to Amarok local collection folders.
  6. Ran my script to convert Media Monkey POPM values to Amarok friendly values directly on the MP3 ID3 tag.
  7. Started Amarok
  8. Ran a full rescan (it picked up all the MP3s I copied into the collection folder as expected)
  9. Added all tracks to a playlist.

RESULT:

The tracks all appear in the GUI with no rating (0 stars).

If I perform the same steps above but without running my conversion script (step 6), I also get the same result (0 stars for everything). (Just to confirm that my script wasn’t corrupting anything).

Extracting the metadata with ExifTool, I can see the tracks have a correct POPM value despite it not showing in the Amarok GUI:
[ID3v2_3] Popularimeter : no@email Rating=255 Count=0

If I use the Amarok GUI to change the rating it will update in the file as expected:
[ID3v2_4] Popularimeter : no@email Rating=51 Count=0

So writing to the file isn’t the issue, the only issue is Amarok reading the rating on initial import.

OTHER CLUES:

One thing I noticed is that when Amarok writes to the file it updates all ID3v2_3 frames to ID3v2_4 (which you can see in the output above). Could that be a possible clue? Does Amarok not like 2.3 tags? Seems strange because it reads fine from all the other 2.3 frames without issue.

Another thing I noticed is that upon changing the rating in the Amarok GUI it adds two additional frames in the ID3(FMPS Rating and FMPS Rating Amarok Score). Is Amarok only reading from these frames and not POPM?

[ID3v2_4] FMPS Rating : 0.3
[ID3v2_4] FMPS Rating Amarok Score : 0.005

SAMPLE DATA:

Btw, the tracks I’m working with are a sample from my collection that represent every star rating value. It’s a collection of 22 tracks, two of each possible rating value. e.g. two have a 5-star rating, 2 have a 4.5 star rating, etc.

POPM VALUES:

Here’s a chart of the POPM values set by each application and the equivalent star rating.

Star Rating - Media Monkey - Amarok
0 0 0
0.5 13 26
1.0 1 51
1.5 54 77
2.0 64 102
2.5 118 128
3.0 128 154
3.5 186 179
4.0 196 205
4.5 242 230
5.0 255 255

4

I looked a little more into that custom FMPS Rating frame. It looks like a redundant form of rating storage created specifically for Amarok, because the values seem to consistently line up to star values:

Star Rating - Media Monkey - Amarok - FMPS Rating
0 0 0 0.0
0.5 13 26 0.1
1.0 1 51 0.2
1.5 54 77 0.3
2.0 64 102 0.4
2.5 118 128 0.5
3.0 128 154 0.6
3.5 186 179 0.7
4.0 196 205 0.8
4.5 242 230 0.9
5.0 255 255 1.0

So I thought: “What if I use my script to create that custom ‘FMPS Rating’ frame myself, then prefill all the values the same way I do with POPM? Perhaps Amarok will read those on MP3 import?” Well, I gave it a shot. I was able to create the frame exactly as it appears in ID3 but still, those ratings aren’t imported into Amarok along with the other MP3 metadata. There might be something else special with that ID3 frame that I’m not accounting for in my script.

I noticed that my utility MP3::Tag (a perl module) serializes the frames as ID3v2_3 instead of ID3v2_4, like Amarok does. I don’t think my perl module does 2.4. I would have to re-script everything using a different tool to even try to serialize the frames as 2.4 (assuming that would even make a difference).

So, I’m stuck again. I can’t figure out how to import my ratings from the MP3, neither through Amarok, nor programmatically. :downcast_face_with_sweat:

5

Ah, sorry, didn’t read your message carefully enough, and the “write statistics to file” check seemed so obvious in code that I just mentioned that. But actually, now that I tried, it only has effect if the file is not in collection. If the track is in collection, the embedded rating is shown in any case.

I tested something similar: I took some mp3 file and set a rating to it using kid3. It seems to be saved in POPM frame; reading the tags with id3info, it says “POP (Popularimeter): , counter=0 rating=100” [the scale here is 0-255 I believe]

Starting with empty database: After scanning collection, Amarok successfully finds a rating for that one. I tried converting it to both ID3v2.3 and ID3v2.4, and the rating was found with both. If I set rating manually in Amarok, an additional FMPS_Rating tag is added (scale 0-1.0) in TXXX frame.

So, my experience so far: Should work no matter whether write statistics to file enabled or not, should work whether ID3v2.3 or ID3v2.4, when stored in frame POPM as rating. If not exactly the rating Amarok uses for the star, will be rounded to nearest star (is divided by 256 and multiplied by 10 in source).

Could you try running amarokcollectionscanner -r directory on some directory containing those tracks and seeing if there’s a tag included in the results for some file with a rating?

1 Like
6

I gave it a shot. I deleted my MP3 collection, and restored the MP3s to the directory from backup.

I ran amarokcollection scanner on the 22 MP3 files (before editing them with my script and before importing them into Amarok)
RESULT: It reads all the files and all the tags except there is no tag in the results.

I ran my perl script to convert the POPM values, then I ran the amarokcollectionscanner again.
RESULT: There is still no tag in the result.

I did a “full rescan” from the Amarok GUI, importing all the MP3 files. Then via the GUI, I edited the ratings. Then I ran amarokcollectionscanner.
RESULT: There is now a tag in the result with appropriate rating value, e.g. “4” value for a 2-star rating in the GUI.

TL;DR: amarokcollectionscanner doesn’t display a rating tag unless I import the MP3 and then edit the rating in the GUI.

Since it is working for you, I wonder if there is something wonky about how my MP3 ID3 tags are encoded. Perhaps something Media Monkey did.

Next, Ill try to download a few MP3s from online from various sources, untouched by Media Monkey to see if I get the same result. I’ll still have to use the script to rate them.

7

If you want, you can also try sending me one of your problematic MP3s and I’ll try to find out what’s the matter there.

1 Like
8

oops, it appears the <rating></rating> tags were getting interpreted in my last post. Anywhere I said “tag in the result” should read “<rating></rating> tag in the result”.

I’ll send a couple MP3s over to you.

9

I figured it out! I’m actually embarrassed that I didn’t think of it earlier.

As you know, POPM has three components:

  • email/user
  • Rating
  • Counter

Amarok doesn’t like the email/user that Media Monkey writes to POPM. MM writes literally “no@email” for every email/user value.

I was able to confirm this by doing the following tests (using the kid3 tool you mentioned for editing the tags):

  • Edited my MP3s ratings (only the ratings) from backup. NO RATINGS IMPORTED.
  • Added a rating of a downloaded MP3s untouched by MM. RATINGS IMPORTED!
  • Edited my MP3s ratings from backup AND ALSO delete the user/email value of “no@email” from POPM. RATINGS IMPORTED!

I thought the “no@email” value was generic enough to not have any relevance, but apparently not. And I should have thought of that earlier because the entire point of that field is to delineate between ratings made by different users (or even applications?). But I think it also threw me off that Amarok didn’t care about user/email value when writing the rating back to the file. It only cared about the user/email value when reading from the file. Whenever I edited a rating in the Amarok GUI it would write that rating to the same POPM frame that had “no@email” and leave that email/user value intact.

So thinking out loud, the simplest approach would be just to delete “no@email” from every POPM frame. But would a better practice be to leave the MM POPM frame untouched and create a new POPM frame just for Amarok? That way my ratings would theoretically work in both MM and Amarok? Is there a POPM user/email value that Amarok uses just for itself?

10

Okay, indeed, any POPM frame with non-empty email is skipped. In case there are multiple POPM frames, rating is read from the first one with an empty email. However, if writing ratings to files, rating is written to first POPM frame regardless of email being empty or not. Based on a quick glance, TagLib probably doesn’t support multiple POPM frames well enough to make more specific handling feasible.

On the other hand, FMPS_Rating is read from TXXX frame and favoured over POPM, no matter if there’s email on POPM frame or no POPM frame at all. However, if writing statistics to file is enabled, the rating is written to both TXXX → FMPS_Rating and POPM → rating

1 Like
11

Ok, I dug into history of this behaviour.

Reading POPM frame was originally introduced in commit

and justification for the behaviour most explicitly stated on a related bug report

Amarok will only read and write POPM tags with an empty email address which is allowed in the id3v2 spec.

Some background discussion and related references are available in Banshee bug from 2008 Bug 532650 – Metadata Ratings and Playcount import/export

After some pondering, I find this behaviour indeed does make sense. If one wants to share ratings between different music players, there shouldn’t be anything that dictates the rating to some specific player. no@email would perhaps be an acceptable generic value, too, but as it is not used by anything else than MediaMonkey, it is de facto MM specific.

I’m not perhaps totally completely happy with the rating being written to POPM frames with email, too, but that’s pretty small corner case, I guess.

So thinking out loud, the simplest approach would be just to delete “no@email” from every POPM frame.

Yeah, after this digging, I can confirm this is the case.

1 Like
12

Thanks for digging into the history and giving me the whole picture. Your assessment sounds well reasoned. I agree that ideally it should be consistent and either only “import and write” if there’s an email or “not import and not write” if there’s an email. But with there being a workaround identified (which I’ve already implemented) and me being possibly the only person affected since 2008, it’s probably not even worth tracking as a bug.

I appreciate your responsiveness and thoroughness on this. I feel like I owe you. What’s the best way to donate $ to Amarok efforts?

13

Happy to help! It was an interesting dig.

There are no Amarok specific donation channels nowadays, but the general KDE donation path is a very fine option.

1 Like
14

Thank you for the link. Sorry for the delay. I finally got around to it and donated some money to KDE. Hope it helps you all. I appreciate the help you provided on this thread.

1 Like