recognizing win exp m4a Ratings

[MrSinatra]

I know DrO will be excited to do this!

...but as per these threads:

http://forums.winamp.com/showthread.php?t=373680

http://forums.winamp.com/showthread.php?t=324512&page=4

we now know that winamp is not reading the ratings win exp is writing to m4a files. this is b/c the rating win exp writes is proprietary, and not using the %rate% atom. I am guessing it is somewhere in the file header as it shows as part of the file's properties.

so my suggestion would be for winamp to continue to write ONLY to the %rate% atom, but read both the %rate% atom, AND the rating that win exp is writing, but preferring the %rate% atom for display if both are present.

this is worth doing b/c WMP probably does the same thing, and b/c if you don't do it, it will confuse users. it also would allow users to get the proprietary ratings read into winamp, so they then could "re-rate" them all via sorting the ratings column, to get the proprietary ratings into the %rate% atom.

just a suggestion for the wishlist.

[DrO]

it stores the rating in a completely different atom within the mp4 container. and from a not so quick attempt, it's not being looked up in a manner expected when i enter the correct atom to use, so either there's an issue with the library used to parse the mp4 container or they do something weird.

[edit]
i've kludged some fallback support but need to do more research to better determine how it's meant to be formatted... as i'm not at all happy with what i've done so far.
[/edit]

and what is this 'win exp' thing you keep typing? is that a jibe at Windows XP? as to my knowledge, it doesn't even support making edits to mp4 containers (as i've only been able to replicate the issue on Windows 7 so far...).

[MrSinatra]

sorry DrO... "win exp" is just my lazy shorthand for "windows explorer"

I like XP, no shots taken. but I use win7 mostly.

can you tell me what atom it is? I am shocked windows supports a m4a rating atom at all, b/c they must have invented it, since I can't find any other app that supports their atom. I would not be surprised to find out they do something weird!

[svnpenn]

In my opinion if this is going to be implemented, it should be done all the way.
That is to say, user should be able to choose from

read and write to "rate" atom

or

read and write to "WM/SharedUserRating" (Windows version of "rate" atom)

doing it any other way is only going to confuse users.

[MrSinatra]

Originally Posted by svnpenn

read and write to "WM/SharedUserRating" (Windows version of "rate" atom)

that does not apply to m4a. that is for WMA files.

[svnpenn]

Truly, you are a frustrating person to work with. I know from personal
experience that the "WM/SharedUserRating" tag is used with M4A files.

You know how I know? Because I tested it beforehand. You would do well in the
future to know what you are talking about before posting.

[MrSinatra]

Originally Posted by svnpenn

Truly, you are a frustrating person to work with. I know from personal
experience that the "WM/SharedUserRating" tag is used with M4A files.

You know how I know? Because I tested it beforehand. You would do well in the
future to know what you are talking about before posting.

are you really this big a jerk? I have done nothing but help you this whole time, and I know I know what I am talking about, which has been far more than you know.

what you are referencing is called a map. windows has mapped what it does on its own formats to other formats.

please, elaborate on this "test" u did beforehand. spell it out.

a m4a uses atoms for metadata. if you know so much, what is the specific atom that windows is writing when it writes a rating to m4a?

[svnpenn]

The string "WM/SharedUserRating" is written to the file, followed by 10 bytes of
something, followed by a one byte rating.

code:


1 STAR

00 00 00 01 00 00 00 0E 00 13 01

hex 01 = dec 1



2 STARS

00 00 00 01 00 00 00 0E 00 13 19

hex 19 = dec 25



3 STARS

00 00 00 01 00 00 00 0E 00 13 32

hex 32 = dec 50



4 STARS

00 00 00 01 00 00 00 0E 00 13 4B

hex 4B = dec 75



5 STARS

00 00 00 01 00 00 00 0E 00 13 63

hex 63 = dec 99

[MrSinatra]

glad we're back to constructive posts.

ok, so are you saying that windows is writing the info to the m4a without using an atom? b/c if that's the case, its a huge, HUGE hack on their part.

when I ask for the atom, I am asking for the string used that other apps can see. I tried your string and different variations of it in mp3tag, but nothing worked.

so assuming I did not make an error, windows is either not using an atom and presumably breaking the container spec, or it is using an atom but with a different string name than the one you are citing, which is the official tag name for ratings in WMA.

[svnpenn]

Originally Posted by MrSinatra

ok, so are you saying that windows is writing the info to the m4a without using
an atom?

Windows is not using an atom. It is using some crap that they made up looks
like. But it looks easy enough from a programming standpoint. Everything but the
last byte in the tag stays the same.

[MrSinatra]

well, imo, winamp should not write to such a hack. it should read it, so that users can get the ratings into winamp, and/or get them into a proper %rate% atom (by sorting and re-rating the files), but just because windows has indulged in this bad behavior does not mean winamp should respect it by writing to window's hack'd up solution (and/or figuring out how to do so reliably since windows is likely breaking the spec).

I am still curious as to where windows is putting this info, meaning if its not an atom, is it in the audio file header, or container header, or where? whatever it is doing, its a very odd thing for windows to do, (meaning not use even a made-up custom proprietary atom, but something outside of atoms altogether)

just FYI, the way windows created that stupid 0-99 scale for that attribute has caused problems with other formats as well. its why POPM now de facto uses 1,64,128,196 and 255 instead of a much more sensical 51,102,153,204 and 255 range, which would've allowed for proper granularity. MS uses 128 b/c that was closer to 50 than 153 was, in the MS devs minds, and that now is the reality we all have to live under.

btw, I am GLAD to have helped you.

[DrO]

it is putting it into an atom (I don't have access to the full atom at the time of this reply on mobile other than its something Xtra) and then it appears to be a custom data blob (I wouldn't be surprised if its what would be in a WMA file tag just stored in the Xtra atom).

I will only add read support for this. otherwise it'll only write to the rate atom. I understand the argument for extra control, but I don't think its right (and considering the grief rating support has been, I only want to do the minimum).

[MrSinatra]

Originally Posted by DrO

it is putting it into an atom (I don't have access to the full atom at the time of this reply on mobile other than its something Xtra) and then it appears to be a custom data blob (I wouldn't be surprised if its what would be in a WMA file tag just stored in the Xtra atom).

wow, that's horrendous. so its similar to how some apps hack id3 into wav riffs? ugly.

I'd like to know what atom (like, specific name) windows is using for this, and what other WMA type tags they are hacking into it? whatever light you can shed when you are able will be appreciated.

thx for the clarification!

[DrO]

there is nothing stopping putting custom data into an mp4 container tag as long as its placed in a valid atom (as is the case).

so its not hacking the spec as its all done inside a specific atom they've decided to use. since it can take other WM/ fields, hence why I think it's putting the data blob you'd get in a WMA tag into the atom they chose. which is why I need to do a bit more research to see if that is a correct guess on my part and sort out proper handling in case other WM/ fields are present i.e. parsing things correctly instead of crude matching.

[MrSinatra]

so m4a has an atom similar to TXXX in id3 that allows for custom entries?

and a custom entry of a data blob containing a full WMA style tag is acceptable?

surely windows is using proper atoms for when it edits "artist" for example? I would think the data blob would only consist of WMA fields that had no official atom equivalent, like ratings. ("rate" is a de facto standard)

whats the date about? how are dates used in WMA?

[DrO]

date is a typo of data (i hate replying on mobile).

and yes what's done is acceptable since it's in a valid atom and what goes in that is down to whoever created it. so i guess it's like the custom mp3 field but you could say every atom is custom, it's just that most have been specifically registered for use.

and i assume that they work on the normal atoms correctly, it's just some extended data which goes into it from what i could find last night.

either way, i think you're over thinking things and just need to accept that they use a specific atom and that it can be read from it as needed to get the rating value in (it just needs a bit more work to determine what the format of the data blob is so it will be correctly read if anything else is present in it).

[MrSinatra]

its not that I don't accept any of this, b/c I do, I just want to understand the mechanics of it all under the hood, like for example what the actual name of the custom atom is that win exp is writing to? and what all windows is writing to the data blob in it?

I realize you're still working all that out, but when you have time and know, I'd love to hear it so I can be up to speed. thx.

ps. its fascinating to me that we have not heard about this issue before, (that I recall), which must mean not too many people are using win exp to rate m4as, thankfully. but even so I would've thought it would have come up by now.

[DrO]

it's using moov.udta.Xtra which is simple enough to find with AtomicParsley (if such things are needed again in future).

[svnpenn]

Weird, I used that with a Windows Explorer rated file, and did not pick it up.

code:


$ atomicparsley norah-jones-dont-know-why-live-128k-aac.m4a -t

Atom "cnam" contains: norah jones dont know why live 128k aac

Atom "ctoo" contains: Lavf55.25.101

[DrO]

i used the -T option and it showed as an unknown atom in the output i got. though i only used that to work out things after looking at the raw file contents to make sure i'd determined it correctly.

[MrSinatra]

ok, so I put:

%moov.udta.Xtra%

into mp3tag as a column and nothing showed. is this to be expected since windows is sticking a blob in there, or did I format the name wrong?

[DrO]

you're not going to see anything just be doing that as the rating value itself is stored later in the data blob (which is filled with a 0 to start with which will cause it to look like an empty string i suspect in what you're trying to do with mp3tag).

[MrSinatra]

I just now see that you guys both used the -T switch.

so that is really strange, why one of you would get the atom and the other not.

are you both using the same ver of atomic parsley?

[DrO]

there is a difference between -T and -t (notice the difference in case) and i just grabbed the windows version from the sourceforge page.

[svnpenn]

"-t" is not the same as "-T".

[MrSinatra]

and this is how I learn. thx.

[svnpenn]

Hopefully this will be my last post on these forums. Winamp has served me well,
and I wish you all the best. This was the nail in the coffin for me

Originally Posted by DrO

I will only add read support for this.

"WM/SharedUserRating" has been mentioned as early as 2011
and I feel for M4A files on Windows, this is the best and
correct way to rate them. This is what Windows itself does. Note that as of April
MediaMonkey supports read and write "WM/SharedUserRating"

I have uninstalled Winamp for MediaMonkey.

[MrSinatra]

the %rate% atom has been supported by a lot more apps (incl MM) a lot longer than this WM tag in m4a, and until u saying MM now supports it, windows was the only one I knew who did.

DrO will add read support for it, which is good enough for my use. however, I don't think its unreasonable to ask for winamp to read AND write to both atoms simultaneously, even if that's redundant. perhaps expose it in an ini for the few people who care about this, or maybe the configure plugin options.

it is maddening that a format has two competing protocols for rating a file, just b/c the spec for it is so poorly implemented.

[DrO]

I only committed to read support and even that I'm not sure it'll make it into the initial 6.x releases as details on it are incomplete or require silly library requirements to handle something that is being shoehorned into the tag when not using what everyone uses as a sane option.

if ratings is so important then please do use what better suits your needs as I've clearly expressed my dislike of having such a,subjective value stored in file tags and that whilst I still work on Winamp I'll fight to keep it an opt-in to save ratings into fle tags where supported by the tag format (and is why read support was the only thing I'd initially committed to try to add).

either way I'd expected svnpenn to move to something else based on other comments.