My files have ape tags on all formats (mainly flac, mp3, m4a) and most fields work fine thanks to common naming convention and I assume a good list of builtin mappings. However, one of my fields is RATING and its value does not show at all, not even verbatim in the Details screen. It’s an enum of 1/2/3, I don’t expect the star bars and stuff to support my custom scale but the literal value or mis-scaled stars (3/5 or 3/10) would be great.
In the media provider config, tag ratings as user ratings is on (I assume the off value is meant for users who don’t clean tags and don’t necessarily agree with the rating left in the tag, same as a scrobbled rating).
Logs:
Upload description: 2 uploads: marnes ape rating song & marnes ape rating logs
Additional information:
Reproduction steps:
Play any flac or mp3 from samba (synced or in files mode) with a RATING apev2 tag field valued 1 2 or 3
Well I can’t comment on what’s popular or the de facto standard. I went with my personal choice of 1/2/3 because I don’t care to nuance my ratings beyond bad/ok/favorite, and I didn’t want tons of meaningless “middle” numbers like 23 or 72 to exist on the scale. I guess you could say I applied KISS. That’s also the spirit of ape tags IMO, to keep it simple and avoid magic values/symbols/keywords (like “feat.” and all forms of separator char that may just be part of a name too, ugh). Less is more.
There wasn’t any solid consensus on ratings back when I looked for it, it was all just vendor flavors. I absolutely wanted to avoid lost in translation (is it 72/100 or 72/255?) and vendor lock. I used to do 1-5 because that seems by far the most common bar star size, but I felt the difference between 1 vs 2 and 4 vs 5 wasn’t meaningful or quantifiable and I often couldn’t choose or didn’t have meaningfully different automations for them (like autoskip).
I think 1-5 makes the most sense overall, given that’s pretty much the universal bar star size. 1-10 if people actually seriously even use half stars. My 1/2/3 can become 1/3/5 or 1/5/10, I don’t mind much. Anything more like 1-100 or 1-255 just seems contrived and like a c++ server implementation detail they forgot to hide behind a logical API. But if it’s super common now then it must be supported of course.
For symfonium, I would argue to serve but also empower the user and implement 2 things. Symfonium seems an app for people who know what they’re doing, so if the current hardcoded system is set as defaults, nothing will change for users who don’t have a problem.
“literal rating tag: on/off (perhaps default off)” for the Details screen, filtering/searching, etc
“rating scale: number or auto (default auto)” where
auto means that funky if/else tree I saw in the docs that I assume is the current implementation
or number is the max of the scale, meaning I could set 3, someone could set 5 to give tracks integer stars, someone could set 10 to give half stars, or people could set 100/255 according to their vendor
This should probably be a media provider option (hidden where there’s a known singular correct value) because, well, different sources use different flavors
Well I won’t add a setting for that, there’s standards for a reason, else everyone come with a special need because he choose something different and it’s impossible to maintain.
The problem is that in Symfonium ratings are important for the mixes and smart filters.
Last possible proposal would be:
0 = 0
1 - 9 = 1 to 9 (so 0,5 to 4,5 stars)
10 - 100 = X / 10
So you won’t be able to use 10 as top and would be limited to 9 or 4.5 stars but that should cover the common needs
I agree with keeping maintenance down, but that’s the thing: there isn’t really 1 standard. There are loads of files out there with base 5, 10, 100, 255, … If you just let the user set the scale max that’s used for the normalization to base 10 during sync instead of guess-mapping it, no one will have to come for support as any 0-linear convention would be supported without error. I think your base 10 in the db is an excellent choice for a scale (database or otherwise) and I’d even like to adopt it, but as you just said, heuristics actually breaks all scales up to including 10 instead of helping with them.
Is your position that you want to push base 100 as the golden standard to be used? Is it really that common already across all kinds of platforms and tagging apps? I’m fine with adopting that convention but I’d like to be sure it’s really a dominant standard and not just another vendor flavor before I do, and I don’t use any clouds or such for my music so I honestly have no view on it.
Either way, it would be great if symfonium’s requirement on the user to use base 100 ratings was clearly indicated in the gui and docs, along with which tag key names are supported for it (rating, popm, popularimeter, …) and other display properties. Foobar for example lets you customize the name mapping, which of course I’m not asking for symfonium to do, but knowing which names are read for what attribute is pretty important. Disc and disk, tracknumber and track number, …
My suggestion for the raw value was to serve 2 secondary purposes really: on the one hand show that a file’s flavor of tag naming works and the value is read, and on the other to support filtering regardless of scale (by normalizing the search value by the same logic, since I now know about the normalization before saving to db). This isn’t important if the ratings just work instead.
You do know that I’m alone and not really making a lot of money from this ?
And yet there’s already more docs than 99,99% of the apps on Play Store.
I can’t document hundreds of combination of tags and maintain that, it’s just not realistic.
APE tags are the least used tags, the only tools I have that support rating on them like Kid3 use a 100 scale, so yes it’s probably the norm.
There’s the same issue with vorbis, and no I won’t add complex settings that 99% of users would not understand and some would put the wrong value and trigger support.
So yes I think I’m going to use the same as Vorbis and enforce the 0 / 100 range specially since the rating key is not even part of the official APE tag specs.
This will in the end only touch you since you are the only one yet noticing that ape tags do no handle ratings.
I gathered from here and there and I think it’s impressive what you’ve built, don’t get me wrong, thanks for having put this app on the world This is foobar2000+components tier functionality with a pretty gui to boot.
I assumed the code already contains list-like structures of tag keys to read and fill the display properties with, but yeah, I know docs are probably the most annoying PITA in any dev project, they always are for me too. But users need to know the “language” of an app like this to get the most out of it, at least when things don’t work as expected. That 99% of other projects are poorly executed dogshit doesn’t really factor into anything IMO, junk can do what it wants.
Ape/vorbis are the only alternatives to id3 that I’m aware of, and id3 has the problem of being “translated” when it comes to key names, needing lookup tables for users and definitions that can be ambiguous to apply. I don’t really think friendly key/value pairs is an underdog format anymore given the prevalence of flac and such today.
I tried googling rating tag standards again and all I found was a blog mentioning just like you that players seem to be converging on 0-100. So yep, I guess that’s the standard we’re going for
I wouldn’t call a numeric scale max a complicated setting (and there are several already that I find a lot more confusing), but I can see how it would be cryptical to users who don’t know about this whole interpretation issue. Totally understand you wanna avoid that hassle just as much.
AFAIK there is no ape/vorbis tag spec and that’s the point of them, to just be straightforward names with straightforward values, no mapping needed, only fuzzy name matching. If vorbis specifically defines ratings are 0-100 then it absolutely makes sense to extend that to ape tags!
I don’t see how this is a “just me” issue since all the world is using non-id3 formats like flac these days and the tagging issue is exactly the same there.
0-100 let’s go. Thanks for the debate and all your work
For the record 99,9999999% of users of flac will have id3v2 or vorbis tags in them not ape.
I do not even officially support ape tag in flac files, so if it works for your files it’s the default taglib mapping and so won’t support the rating I add.
If you have ape tags in a flac file with rating, please upload one here so I can look.
Oh yeah, sorry, I do use “ape tags” as a catch-all for vorbiscomment and any others that may exist that are all functionally identical, differing only in the binary format. For me it’s mostly to say “not id3” since I dislike its cryptic, fixed key names and some of its semantics.
I set it up ages ago in foobar, which chooses the right tagging tech for any given file transparently afaik. My mp3s have ape for sure since that’s very explicit in foobar and id3 is the only other choice, but what flac, vorbis, m4a, etc get tagged with isn’t said, I assume each file type has a solid standard pick (as you said, vorbis for flac, etc).
I’ve uploaded a sample of each filetype in my collection (marnes rating tag filetypes). All of them have a rating tag, and symfonium seems to show all their tag values except the rating. I would expect taglib to just discover tags of any type transparently and return the key/value list tbh.
Could the issue simply be that whatever the current normalization logic is turns values 1/2/3 into blanks?
I did a test with the files I uploaded earlier, cleared their tags except an album and rating=80.
flac and ogg vorbis show 4 stars
m4a aac is found by album search but lacks a rating
id3 mp3 with custom rating tag is found but shows no rating (but using the correct id3 tag I have no doubt it will work)
mka aac and apev2 mp3 aren’t found by an album search at all, which is odd because most of my library is apev2 mp3 and it’s showing up just fine otherwise, but let’s chalk it up to apev2
mka is maybe a little exotic as format so that’s ok (I have a few more that I left out of this convo for that reason). I guess I’ll adopt the base 100 ratings, reconsider id3 if that’s what it takes for mp3 to work (not just for the rating but other tags too, apparently), and read about m4a tagging first because that’s the format I know least about. Sorry for the extensive edit, something came as an afterthought
Taglib gives access to the tags but the default mapping is lacking a lot so it’s not used unless custom parsing fails.
mka are not supported by taglib for now so it’s normal.
mp4 have a specific rate thing on a 0 100, and it seems some tools use the iTunes custom field, but it’s not yet mapped. I’ll add support for 0/100 in that field too.
For mp3 it’s a bug on the parser on my side with your files where it think there’s id3 tags and so skip the ape, it’s already fixed.
Ah, thank you for the fixes then. I’ll look forward to the release and do a careful test again afterward. Shame some less common filetypes won’t work but oh well.
In addition to your last reply, could you also map the rating (0-100) tag on mp3/id3v2 please? You said you’'ll add it for mp4 and mp3/ape, but currently it doesn’t seem to work for mp3/id3 either. IIRC id3 expects popm (0-255?) to be used and that’s probably what you map now, but tag names changing depending on format is the mess I want to avoid. Would be great if rating was simply universal, which it seems we’re just 1 format away from now.
Thank you Filetype-agnostic semantics/conventions ftw though. I became a uniformity-evangelist the day I changed players once and half my files lost some tags and the other half gained tags out of nowhere.
While I agree on principle, deviating from the “standard” tags of formats can lead to problems when you use your files in multiple players.
Let’s take the rating TXXX tag for example.
A user might use popm for the actual rating and then decide to also include a custom tag to store a rating fetched from an online source for example and decides to use the TXXX:RATING tag for that purpose.
By supporting both popm and the TXXX version that can lead to conflicts or unexpected behaviour when the popm rating is expected and the online fetched TXXX one is displayed or vice versa.
Personally I found the most widely supported way of tagging is to use one field name in your tagging software and let it map that tag internally to the correct frame or tag of the format in question (when there is a convention/standard).
Mp3tag has a good list of its internal mappings and so far I have not run into problems while using my library with MusicBee, Plex, Jellyfin, Navidrome, lms, Mediamonkey and a couple other players I have probably already forgotten.
It’s cool that Symfonium now supports a couple extra tags, but I wouldn’t count on other players to go out of their way to do the same.
That’s an awesome piece of doc, thanks. Foobar has similar mapping logic. And yeah, I agree with the principle of sticking to a given format’s own standards too, it’s obviously necessary for the tags to work universally.
The original reason I set up all my custom mappings was that I find a lot of the conventional tag names too “bad”, full of abbreviations, weird names, and odd styling like concatenated words. It makes scripting and such a lot less userfriendly. I preferred the concept of vorbiscomment/ape of just setting obvious and human friendly names, and didn’t want those tags to become a mix of friendly names from my custom tags (disk title, album variant, etc) with 4-letter alphabet soup from id3.
I’ll look forward to the release and do a careful test again afterward. Shame some less common filetypes won’t work but oh well.
Filetype-agnostic semantics/conventions ftw though. I became a uniformity-evangelist the day I changed players once and half my files lost some tags and the other half gained tags out of nowhere.