MP3Tag, MediaMonkey don't see eye to eye concerning RATING in ID3 tag

Incident relates to MP3Tag 2.49, MediaMonkey (MM) on Windows XP Professional SP3.

I was testing the reliability of storing ratings in MP3 files.

  1. In MP3Tag, I created the target field name "Rating wmp" by using the extended field RATING WMP. I displayed the name as a column head and in the tag panel.
  2. I experimented with just one MP3 file.
  3. From within MM, I assigned a rating of *** to that file.
  4. I assigned a rating of 5 within MP3Tag. Saving the MP3Tag rating changed the MM rating to *****. The update was automatic. No mouse clicks, no buttons pressed.

However, after reducing the rating to 1 from inside MP3Tag, the MM star did not respond. No responses after I tried other values within MP3Tag, including switching from * to *****. No success either from refreshing MM's screen with F5, reloading the folders, or even restarting MM. After many trials (that I cannot list accurately), I could again produce ONE response in MM from saving a rating change in MP3Tag. Then, there would be a long string of failures again. And so on.

MP3Tag's rating NEVER budged in response to rating changes initiated in MM, even after using MM's Tools | Advanced tag management | Synchronize tags.

Whose bug is it? Probably MM's, but I can't tell, and I think this problem would be of interest here anyway.

Can someone shed some light on that mystery?

Look here. Near the bottom of that page:

Could it be that you should use RATING MM for your tests?

Thanks for the link. I saw it before and it helped me understand how to create a user name for the rating field in MP3Tag. I tested all three extended fieldds (for MM, WMP, and WINAMP). I also thought MM was the logical choice, but only WMP produced results at all.

There could be a glimmer of an explanation for this: Windows Media Player was apparently the first major media player to write to tag rather than just to the internal database, so it may have been a "practical standard" to follow. I checked the Winamp forum and the talk was about how Winamp had to follow WMP. Winamp developers seemed to have opted for emulating what WMP did, rather than having a specific Winamp way of doing things--although Microsoft has hardly been the best sofware writer, just the 500 pound one! BUT Microsoft had the great common sense and merit to write ratings in the file itself, which should be the primary way of handling ratings.

I forgot to mention that I set both software to preserve the timestamp. It occurred to me that this setting could complicate the updating of rating in the tag for both software.

So there are now 4 ways of testing the rating-in-tag update issue:

  1. Timestamp preservation ON, for both. I reported for that setting already: very poor ability for both software to make a rating change in the tag that the other could recognize. MediaMonkey could not communicate any change that MP3Tag could read. MP3Tag could make a change that MM could recognize VERY rarely.

  2. Timestamp preservation OFF, for both. MM could reliably communicate ONLY a change of TIMESTAMP that MP3T could recognize. It would rarely communicate a rating change recognized by MP3Tag. By the way, the rare times it did, MP3T would express the rating in stars, even if it displayed a numeric symbol prior to the change. [Note: I synchronize within MM with "Tools | Advanced tag management | Synchronize tags".] A change in MP3T can only be seen with a F5 refresh in MP3Tag. EVERYTIME the change was initiated in MP3Tag, MM would recognize the change, with no need for the user to refresh its display [because its "file monitor" option is ON].

  3. Timestamp preservation OFF in MM, ON in MP3Tag. MM still has great trouble changing the rating seen in MP3Tag. It reliably continues to change the file's timestamp (as can be seen inside MP3Tag with a F5 refresh). MP3Tag now has difficulties again changing the rating displayed in MM.

  4. Timestamp preservation ON in MM, OFF in MP3Tag. MM still cannot communicate its rating change to MP3Tag. It stops changing the file's time, as it is now supposed to with timestamp preservation on (this option works well in MM and also in MP3Tag). MP3Tag reliably changes the rating change displayed in MM (and the filestamp, of course).

Conclusion: MM's "synchronize" option has trouble making rating changes to the file tag in any way that could be remotely called reliable, whatever the timestamp protection setting in either software. So timestamp protection is not an immediate issue in MM. MP3Tag can change the rating displayed in MM reliably ONLY when its own timestamp preservation option is off, whether MM is in timestamp preservation mode or not. MP3Tag can still affect the rating displayed in MM when its timestamp option is on, but VERY unreliably. So the timestamp preservation in MP3Tag is clearly an obstacle: when in timestamp preservation mode, it cannot reliably make changes in the tag's rating field that MM can read.