Skip to main content ↑ ↓

Notice

Please note that most of the software linked on this forum is likely to be safe to use. If you are unsure, feel free to ask in the relevant topics, or send a private message to an administrator or moderator. To help curb the problems of false positives, or in the event that you do find actual malware, you can contribute through the article linked here.
Topic: Wrong handling of rating tag fields for .m4a files (Read 1850 times) previous topic - next topic
0 Members and 1 Guest are viewing this topic.

Wrong handling of rating tag fields for .m4a files

First, a few words on the sane handling of rating tag fields for .mp3 files that fb2k already is capable of:

When you add a "RATING" field with the tagging dialog of an .mp3 file, it writes the "POPM" field to the file as my hex editor HxD shows: "POPM���#��Windows Media Player 9 Series�€����". This also shows that fb2k virtualizes the "RATING" value, because it's not directly the one shown in the dialog and I need to do the following calculation to get from what HxD shows to what the dialog shows (guessed formula): byte_value / 255 * 4 + 1.

------------------------------------

Now to .m4a files. I'm not an expert regarding the inner structure of .m4a files, but I seem to understand enough to tell what's the problem here. When you use fb2k's tagging dialog to set "RATING" for an .m4a file, fb2k obviously uses a mechanism of MP4 tags where you can freely define the name field and writes the following bytes where it retains the value from the dialog (doesn't virtualize it): "���name����RATING���data�������4".

What fb2k really should do is map "RATING" from the dialog to the MP4 tag field "rate", which seems to use decimal values from 0 to 100 as text. Currently, when you try to use "rate" in the tagging dialog directly, it again uses the same free-form mechanism it uses for "RATING": "���name����rate���data�������50".

I know of 2 other pieces of software that support the MP4 tag field "rate" without going the free-form route: the Android app "GoneMAD Music Player" where you set a number of stars and that writes a number from 0 to 100 to the file, and Mp3tag. In the file, it looks like this (without "name" before): "���rate���data�������60". This page, where native MP4 tag fields are written in lowercase, also confirms "rate" as an equivalent of "POPM" and "WM/SharedUserRating".

fb2k doesn't currently recognize native "rate" at all. It's just not shown in the dialog when it's present in the file. And fb2k's free-form "rate" or "RATING" isn't recognized by the Android app. When you set free-form "rate" with fb2k and native "rate" with the Android app on the same file, Mp3tag shows "RATE" two times, which is a state no software should get a file into (and fb2k is the problem here).

So, it's time to support native "rate". And since "RATING" is virtualized for ID3v2 tags and one wouldn't want to consider the file type when using fb2k's Quick Tagger, fb2k should additionally map "RATING" to MP4 tags' "rate" and virtualize it's values.

I could do exhaustive tests for you to find out what exact values "GoneMAD Music Player" writes for which rating.

---------------------------------

There's also "WM/SharedUserRating" that the Windows file property dialog writes into .m4a files when specifying a rating there. It sure wouldn't be bad, if fb2k also could read those values, if it's the only rating present in the file, and make it available as "RATING". One could also ponder whether it's desirable to keep it up to date with "rate" (at least if it's already present) or to always delete it when setting "rate".

-----------------------------------

BTW: fb2k isn't consistent with its UI when it comes to how it writes the names of free-form tag fields into files. You can add a field "FrEeFoRmFiElD" and it's written that way into the file, while the UI converts it to all-caps. The software Mp3tag, by contrast, enforces the all-caps variant in the file.

--------------------------

EDIT:

.m4a files where the user just had set "RATING" will have been tagged wrong on many machines. Besides being generally useful, this is an especially good argument for the following. The tagging dialog should display free-form fields and mapped fields like "RATING" differently. The format "<FREEFORMFIELD>" could remain established for such fields. "Comment" is the format for standard mapped fields. Now, we need another format for mapped fields that aren't standard fields that are always displayed (unless you want to add "Rating" to the always-there standard fields); this format could, e.g., be: "<Rating>".

For files with ID3v2 or MP4 tags, this could potentially mean that "<Rating>" and "<RATING>" are displayed, if a free-form field is also present, instead of behaving incomprehensively to the user.

Ideally, fb2k should offer the user to convert "<RATING>" to "<Rating>" when it encounters "<RATING>" in MP4 tags in a playlist or in the media library.

Re: Wrong handling of rating tag fields for .m4a files

Reply #1 –
Noted, thanks for bringing this up.
Note that MP3Tag also writes freeform 'rating' if asked to write 'rating', uses 'rate', only if asked to write 'rate', or if you remapped 'rating' to 'rate'.
I'll evaluate this for the next update after 1.6.9, looks like changing default writing of tags will improve compatibility with some software while breaking compatibility with other software.
Microsoft Windows: We can't script here, this is bat country.

Re: Wrong handling of rating tag fields for .m4a files

Reply #2 –
Thanks for taking this on!

Regarding ID3v2 tags: While fb2k maps "POPM" with it's virtual "RATING", Mp3tag maps it with it's virtual "POPULARIMETER", "RATING MM", "RATING WMP" and "RATING WINAMP" (documented here). It's just the software-specific mapping name. Mp3tag has, of course, yet to improve it's mapping of MP4 tags' "rate"; this is in the works or already proposed, from what I've read. But reading and writing it not as a free-form field is already supported by the "Extended Tags..." dialog from the context menu of files.

I'm not sure what you mean by compatibility with other software would be broken.

-----------------------

More proof for "rate":

- Describes "rate" as "RatingPercent" and string, which says something about it's possible values (search for field names in single quotes): https://metacpan.org/dist/Image-ExifTool/view/lib/Image/ExifTool/TagNames.pod#QuickTime-ItemList-Tags
- Confirms "rate" as equivalent of "POPM" for multiple other pieces of software (especially at the lower part of the page; search for "rating"): https://community.mp3tag.de/t/mp4-felder-atom-box-in-anderer-software/48614

The ASCII strings that "GoneMAD Music Player" writes as "rate" are:

- 0,0 stars: "0"
- 0,5 stars: "10"
- 1,0 stars: "20"
- 1,5 stars: "30"
- 2,0 stars: "40"
- 2,5 stars: "50"
- 3,0 stars: "60"
- 3,5 stars: "70"
- 4,0 stars: "80"
- 4,5 stars: "90"
- 5,0 stars: "100"

--------------------------

Note that "rtng" is not to be confused with "rate". It's the parental-advisory kind of rating, where "Explicit" is one possible value.

There's also "urat", which is mentioned on the pages linked above and, e.g., here or here ("User 'star' rating of the media"). It seems to me to be practically less prevalent than "rate". Maybe fb2k should support reading it and keeping it up to date like "WM/SharedUserRating" (alleged value list for latter here).

------------------------

Following up on what I wrote at the end of my last comment: It really shouldn't happen that users don't have any way of transferring wrongly set free-form "RATING"s to the new "RATING"s mapped with MP4 tags' "rate" (at least manually in the tagging dialog with "Format from other fields...", although many wouldn't understand that the same dialog value is written to the file a different way).

Re: Wrong handling of rating tag fields for .m4a files

Reply #3 –
MediaMonkey (tested under Windows) also supports MP4 tags' native "rate".

MediaMonkey and GoneMAD Music Player also support "rate" values like "    00000000060    $   ". The following regular expression describes how they get the number: "^\s*0*(\d+).*$". MediaMonkey treats values greater than 100 as 100. (GoneMAD Music Player currently has a bug and displays more than 5 stars in this case.)

-------------------------------

There's another bug with ID3v2 tags: When I use GoneMAD Music Player to rate an .mp3 file with 0 stars, the file contains a "POPM" field with text "GMAE" and rating byte 0. fb2k doesn't reflect the existence of the "POPM" field in its property dialog; this is only true when the rating byte is 0. So, now, you can add a "RATING" of, say, 5 and apply and the file will contain two "POPM" fields (an additional one with text "Windows Media Player 9 Series").

Another problem: When you set "RATING" to, e.g., 0 or 6, the "POPM" field is removed and a free-form "RATING" field is instead written to the file. fb2k currently also changes "RATING" values in the same manner I described above with the regular expression (like "4.5" or "4,5" to "4"); this could be viewed as a precedence to coerce the value into the range fb2k supports.

---------------------------------

I wanted to propose supporting a rating of 0 and a rating granularity of 0.5 anyways. Can we discuss this here also? GoneMAD Music Player and MediaMonkey also support this for at least .mp3 and .m4a. Many posts on the internet show that a number of people would like to see the possibility of half-star ratings.

I have done extensive tests for .mp3 and .m4a files, checked every single possible rating byte or text value in mainly 3 other pieces of software that support rating with 0.5-stars or 1-star granularity. I have these available as LibreOffice spreadsheet documents. They would be important for you to decide how to interpret which value when reading ratings and what values to write for different ratings. For historic reasons, this is not so straightforward for "POPM". But there's a way to keep it compatible with other software including Windows, which only supports 1-star granularity. (fb2k's writing of "POPM" with text "Windows Media Player 9 Series" shows that it strives to be compatible with Windows/Windows Media Player.)

Decimal separator inconsistencies (. vs ,) must then never be a problem in queries or when writing tags.

Re: Wrong handling of rating tag fields for .m4a files

Reply #4 –
A small bug with ID3v1 tags (version one!) I've found by chance: The genre byte 0x43 (decimal: 67) at the very end of the tag is translated from fb2k to "Psychadelic". This is written incorrectly; it must be "Psychedelic" (proof from Merriam-Webster dictionary). There also doesn't seem to be an established genre like that that was deliberately written incorrectly (since ID3v1 is old you could expect a Wikipedia article). You might have taken the list from here where there's the same typo. That same list contains "Psychedelic Rock" without the typo, though. Here's another source for the ID3v1 genre list without the typo. The software Mp3tag and MediaMonkey translate it correctly.

Other differences between the two lists with writings in the first list that possibly could be improved (should be researched), in case you indeed copied the same source:

  • Jazz+Funk vs. Jazz&Funk
  • Bebob vs. Bebop
  • Drum & Bass vs. Drum’n’Bass
  • Club - House vs. Club-House
  • Christian Gangsta Rap vs. Christian Gangsta
  • Synthpop vs. SynthPop

Re: Wrong handling of rating tag fields for .m4a files

Reply #6 –
These 2 links already contradict each other. First link vs. second link:

- AlternRock vs. Alternative Rock (fb2k: Alternative Rock)
- Native American vs. Native US (fb2k: Native American)
- Rhythmic Soul vs. Rhytmic Soul (wrong sound!!!)

And "Bebob" (in both links) is obviously wrong, too:

- No mention of "Bebob" in Wikipedia article: https://en.wikipedia.org/wiki/Bebop
- No admission of "Bebob" as a variant: https://www.google.com/search?q=%22bebop+also+bebob%22%7C%22bebob+also+bebop%22%7C%22bebop+or+bebob%22%7C%22bebob+or+bebop%22

First link also uses wrong English: "The following genres is defined in ID3v1".

These list items don't seem to be taken seriously to the letter. MediaMonkey and Mp3tag also display the correct "Psychedelic". It's just a textual representation of a number for the user. It should be about not alienating the users. " 'Bebob'? What's that?! I know my music as Bebop!"

Re: Wrong handling of rating tag fields for .m4a files

Reply #7 –
Also contains German racial slurs, #133. One developer's site suggests it's a Swedish racist joke. TagLib that I use in Cog reads it as "Worldbeat", and has the offending string, along with several that were already modified for typos or other reasons, for correcting the old values back to their numbers on write.

I have also created a patch against FFmpeg's ID3v1 genre list for several of TagLib's corrections, but it seems they already picked up a few of them, including "Bebob" -> "Bebop". No attempt by FFmpeg to remap the previous field contents to numerics, or any code whatsoever for mapping text back to ID3v1 numerics.