Popularimeter Tag Fails in 2.48c

Could someone explain to me why this is not simply a bug?

https://docs.mp3tag.de/mapping says

POPULARIMETER
This description is for only ID3v2 tags. The playcounter is an optional value.

Syntax: Email|Rating|Playcounter
Example: Mp3tag|255|5
Note: The Rating is an integer between 0 (worst) and 255 (best).

so surely %popularimeter% is supposed to work.

i think its clear that this is a bug.

i have no beef with Florian "dumbing down" the app to do "RATING WINAMP" with 0-5 values, etc, for those who find that useful, but that ABSOLUTELY should not then cause the "POPULARIMETER" columns/values to STOP working!!!

in other words, feel free to ADD the app specific functions, but for the love of god don't depricate / remove the way it should work by spec!

RATING WINAMP is USELESS to me, totally useless. worse, i can't use mp3tag to even implement a workaround to get POPULARIMETER back the way it was. the whole point of mp3tag, imo, is to show you whats actually in your tags, not to interpret your tags for you.

i don't want to get too histrionic, but please, PLEASE, restore proper functionality. thanks.

QUOTE (chrisjj @ Jul 12 2011, 02:59) <{POST_SNAPBACK}>
Could someone explain to me why this is not simply a bug?

https://docs.mp3tag.de/mapping says

POPULARIMETER
This description is for only ID3v2 tags. The playcounter is an optional value.

Syntax: Email|Rating|Playcounter
Example: Mp3tag|255|5
Note: The Rating is an integer between 0 (worst) and 255 (best).

so surely %popularimeter% is supposed to work.

FLORIAN,

can you PLEASE allow %popularimeter% to work SIMULTANEOUSLY with ratings in files by winamp, wmp, or whatever else? (see previous posts)

PLEASE???

thanks!!! (love mp3tag otherwise!)

I second that MrSinatra, can't see any logical reason why the winamp rating function needed to REPLACE viewing the raw data

Thanks for the confirmation.

This leaves me mystified by the lack of any response from Florian during the year since the original report.

having just gotten winamp to fix the way they read ratings, i have yet another reason for Florian to please implement this request:

the way an app writes a rating varies, the syntax by spec is:

email addy | 0-255 rating value | playcount #

but what happens in reality is that some apps will overwrite an existing email addy (or similar text string ID) when writing the rating value, (bad behavior, i'm looking at you WMP and windows explorer) while some others DON'T, (good behavior, like winamp).

this means that you could have situations where the default email addy, like the one MM uses, is properly left in place by an app like winamp, yet has an UNEXPECTED value. for 5 stars, MM writes 252, but winamp writes 255.

its yet another reason why %popularimeter% should be left to show the raw data, if a user uses that column, irrespective of what the "app specific" rating columns do.

in order to get winamp to fix its issue with the way it READS ratings, i had to use a different program to analyze files. i could not get the raw data out of mp3tag.

/t/14296/1

ok, now i am finding bugs with the way Florian WANTS it to work.

check out this file:
dead link

the POPM frame for it is:

no@email|255|0

ergo it SHOULD be in the RATING MM column. it is NOT.

it shows up in the popularimeter one instead. i have a couple other MM rated files, and they seemingly have the same syntax and do show up in the RATING MM column.

so again, this just goes to show that the %popularimeter% column should never be deactivated just b/c mp3tag sees a given text string. and apparently, app rating columns don't always work even when the strings are present!

EDIT:

i suspect the reason its not working, is the 255 value as opposed to 252. further reason to not assume things based on the text string. the file was rated first by MM, then later by another app that appropriately does not overwrite an existing text string, but uses a # value MM does not.

dano,

is it forbidden to post links to example files at mediafire or elsewhere?

if so, i apologize, just wanted to show the issue. the link isn't dead tho afaik.

Well I couldn't download from this link and links to complete audio files will never stay long here for obvious reasons.
It would be best if you just posted the first ~50kb of the file since ID3v2 tags are at the beginning of the file. (if there's an embedded cover you might need a larger part)

unfortunately i have no idea how to do that.

the mystery is solved tho, mediafire now seemingly looks for things it thinks are copyrighted and then won't let you share them.

i posted at 4share instead:

it does require a login, but its free, and you could use FB to login, etc...

however, all you really need to do is enter the value i posted above for POPM into any mp3, and you will see one buggy permutation. the easy fix is to just reinstate %popularimeter% so that its "always on," regardless of what the app specific ratings columns are or aren't doing.

Please only links with a direct download.
But as you said the sample is not needed. The issue can be easily reproduced.

Not obvious to me. Could you clarify, Dano? Is there some forum policy prohibiting complete audio files? And if so, what's meant by "complete"?

I would add that recent soon to be released changes in both winamp and MM will make mp3tags handling (described in post 16) break pretty badly.

I don't understand why mp3tag is ignoring the issues in this thread?

Surely the reason it is a problem is it is a failure to operate as required. See https://docs.mp3tag.de/mapping/#popularimeter for how it is supposed to operate.

Can anyone tell me the latest version of Mp3tag that does not suffer from this failure? Thanks.

2.48b

EDIT:

(for winamp anyway. I don't know when the "app specific" fields got added for MM and WMP, might be in the version history though)

Thanks.

I take that to mean: when POPM has email rating@winamp.com, anyway.

just to be clear, it means that if u have rated your files using winamps default value (which u state above), then the last mp3tag to show the raw data for that is 2.48b

just fyi, the new winamp thankfully allows the user to denote any email or txt string they like.

however, it will be earlier versions of mp3tag than 2.48b to get POPM to show the raw data if u rated files with MM or WMP. I don't know which earlier versions, but u might be able to deduce it from the version history.

[quote name='MrSinatra' post='70650'] it means that if u have rated your files using winamps default value (which u state above), then the last mp3tag to show the raw data for that is 2.48b

Meaning the last Mp3tag not to suffer from "all of my %popularimeter% and POPULARIMETER references have stopped working" on files rated using Winamp's default settings is 2.48b.

In the matter of this confused implementation, I think we need every bit of clarity we can get. :slight_smile:

Can someone please summarize the issue that is reported in this thread?

thanks for the interest!

the most basic issue, is that %popularimeter% does not work as a column, meaning it does not show any data at all, if the text string ID in a POPM frame is one that mp3tag recognizes, namely:

windows media 9 series (RATING WMP)
rating@winamp.com (RATING WINAMP)
no@email (RATING MM)

the proposed solution is to allow both columns to work simultaneously. so if a file had:

rating@winamp.com|196|0

...in its POPM frame, then it would continue to show "4" in a RATING WINAMP column, but it would simultaneously show "rating@winamp.com|196|0" in a %popularimeter% column, instead of nothing, which it currently shows.

the main point is that I want to see the raw data in the one column, and currently I can't if it has one of those "recognized" txt ID strings.

"popularimeter" is missing from your listing to create columns btw. it used to be there, altho I can't recall if it was in the "information fields" or "extended fields" list.

--

you should also be aware of the following things:

just because the text id might seem to suggest a given program wrote the rating, does not mean a DIFFERENT program didn't write a different rating later. currently, MM will write 252 for 5 stars, but winamp will write 255. if a winamp user re-rates the file, OR gives it a different rating, the MM txt string REMAINS in place, but the value changes. this then completely breaks what you are trying to do in the "app" rating columns. see post 16.

Also, I have gotten the devs at MM to agree to use "255" instead of 252 and "1" instead of 23 going forward, but that change has yet to be released. in addition, winamp will in its next release, allow the user to specify their own email addy, as opposed to the default above, (also my request).

thx for your attention to this issue!