jiri wrote:Hi MrSinatra,
you've made a great work comparing the apps! I'm on a vacation now, so I'm a little slower on responses...
thx! and np, i hope you enjoy it. let us know when you're back.
jiri wrote:As for your suggestion
- Full stars - 2, 3, 4 - they are clear, no problem there
- Full stars - 5 - yes, I agree with writing POPM 255 here, I don't see any potential issue with this approach
great! thats a step in the right direction, that should promote harmony and interoperability between all apps.
jiri wrote: - Full stars - 1 - I'm not too keen on the suggested non-linearity, though I understand the reason. Is there any app that doesn't current properly read MM 1 star rating (written as POPM 23)?
how deep is the ocean? ;) the point of following microsofts lead, which is what most apps end up doing, is that if all apps follow MS lead, they will all play nice with each other.
i have not tested much beyond winamp, wmp, win exp, and mp3tag. (and MM somewhat in the sense that i am using MM POPM values reported in this thread)
but even with just this small sample size, there are quite a few problems. the current release of winamp does NOT work with the values MM is using, like 23 for instance. it shows NO stars when MM uses 23 for one star. now, in fairness, winamps current POPM implementation is buggy, and due to my efforts in their forum, it should be fixed for their next release. but that isn't really the point. if MM used 1 for one star, as WMP and Win Exp both do, then winamp WOULD work with a MM rated file, even now with its admittedly current buggy popm implementation.
SO, the point is MM is arbitrarily doing something, (writing a value other than 1 for one star), that no one else is doing, (that i know of), and that can lead to problems that are not easy to foresee. it is basically contradicting the de facto standard setters, who are Microsoft.
for instance, as i mentioned earlier, mp3tag can [does] have big problems with what you are doing. mp3tag has a column it has based on your id string, and that string once written, should NOT be over-written even when the file is re-rated. winamp eg. behaves properly in this regard.
so say your app writes 23, (or 252 or 255 for that matter) and then later winamp changes the value to 1, (which it already uses when writing 1 star). the POPM will have the same id string, but the value will be unexpected to mp3tag, and therefore the entry will not appear in the RATING MM column in mp3tag at all! thats the kind of thing we should be avoiding by following the de facto standard.
and don't get too bothered by the non-linearity. most users won't know the difference, but you'll be compliant with MS. that should trump what we both agree is otherwise not intuitive. it has to be done though, b/c of poor choices MS made. really though, it will only affect POPM values of 2-31. after that, things are more or less linear and sensical, albeit inelegant.
jiri wrote: - The rest of POPM ranges - I'd rather stick with the current ranges used by MM, at least for the compatibility reasons with older MM versions.
but you could build in a script to the install routine that would update the old values to proper new ones. this would take no effort on the part of the user. it would be a one time thing. you would just need to properly map old values to new ones.
as to what specifically MM should use to write half stars, my only concern would be that it not contradict windows explorer, and not display 0 stars when the raw POPM value is other than 0, b/c i believe that to be demonstrably false. only 0 can be 0.
jiri wrote:Another thing is that some scripts/users use the full 0-100 range supported by MM and so not storing the range fully in POPM wouldn't be wanted.
Jiri
i have to admit, you've totally lost me here. did you mean to say the full 0-255 range of POPM?
i have always advocated using 0-255 for POPM, since that is established by the spec.
but beyond that, i don't understand the point you are making here?