Add a local #AGE tag

[dgruss]

Suggestion

The discussion in #54 evolved a lot around some ground truth and that it does not exist since age ratings are different in different countries and personal preferences.

The Ultrastar format already has some keys that are supposed to refer to a universal ground truth and those that do not refer to any ground truth outside of the local deployment of the game.
For instance, #TITLE is supposed to be the correct ground truth title (although many deployments of the game set titles based on their own local conventions). #TITLE is supposed to be copied when sharing Ultrastar song files.
However, #COVER, #AUDIO, ... and many other tags referring to files, are not based on a universal ground truth but refer to local names in the local deployment of the game.

A feature where for a song, an age suitability can be set, is what the initial poster in #54 asked for. I also would like to see that and I know more people that would like to have that feature.
This is not about an FSK, R, or PG rating, it is simply a means to control which songs are suitable for which group you play the game with.

For instance you may play the game with your nephews and nieces (<12) and want to select songs suitable for their age range, later in the day you want to play with some older relatives a (<17), later in the day you play with a group of friends you have not seen in a long time you want to lift the restrictions all together. This asks for a filtering mechanism that is not just tag like "adult" or "child" or "nsfw". However, an AGE tag can help, and can be locally set to whatever you think is appropriate for the song.

Now if this is only a local tag, why add it to the format?

Same as for #COVER, the game needs to do something with that.
I implemented a prototype in UltraStar-Deluxe/USDX#1140 and UltraStar-Deluxe/USDX#1141.

The first PR introduces the #AGE tag and the possibility to search and filter by age, in any of the following formats (14 as an example):

"14" shows only songs that have an age tag 14
">14" shows only songs with age tags above 14 (or no age tag configured)
">=14" shows only songs with age tags of 14 or above (or no age tag configured)
"<=14" shows only songs with age tags of 14 or below
"<14" shows only songs with age tags below 14

The second PR introduces a kiosk mode allowing to move the game into a state where a user cannot quit the game or leave the game's fullscreen window, which can be very useful for setups where the game is controlled without supervision. If no age restriction is necessary, setting kiosk mode to Unrestricted will keep all songs but enter kiosk mode, at the same time, setting an age boundary will hide all songs above that boundary but enter kiosk mode in the same way. This way playing with less supervision is possible.

Again, closing I emphasize that this is not what people understood in #54 -- it is not about a universal ground truth age rating, it is about enabling users to locally set an age boundary for a specific song.

Lastly, why not #TAGS? #TAGS neither looks like a strictly local tag. Nor adding an AGE=14 there will integrate well with the existing format specification.

Use case

No response

Extra info/examples/attachments

No response

[randompersona1]

I like this a lot. Currently, I have multiple folders that I can add to the game with explicit songs. I suspect most people that also play with children do something similar. But that fragmentation is annoying for use with most editing software.

The format shouldn't impose any restrictions or requirements on the use of the tag, just define it so that games expect it and implement its use. Software like Yass, UltraSinger, or the syncer as well as sites like USDB can then do whatever they want according to localization settings or other.

[Baklap4]

In the end we decided in #54 that an age tag won't be added since its different per country and is subject to change when used by different users.

Sites like USDB or tools like the Syncer cannot determine themselves the value of any given song on a per user basis based an universal ground.

The spec however defines the usage of custom fields which software may use to enhance their gameplay. For this Age thing i think it'd make sense to add it as optional header (and not a custom field) which will be written to by tools like USDB_syncer or UltrastarManager. But the field WONT be available from hosting parties like usdb the website since they'll need to suit a lot of different people.

I could see an option where that's being utilized.
For instance USDB-Syncer or UltrastarManager could have an option to alter the local file according to what the enduser specifies, for instance:

1. Select all songs
2. Mark hem <=14
   • This changes the local file and adds in the #AGE header.

Personally i think editing software should not be able to write this field since the txt files produced will be shared and thus define whatever the creator thinks is best.. which is not what the end-user (the people singing) might expect.

It's then up to singing software to either add support (reading/filtering) for this field or not since its an optional header.

As an addition/few cents:
sometimes Lyrics are inappropiate for younger audiences, but sometimes the video itself is also or the only thing that's inappropiate
Aside from that (and i think we should use the #TAGS header for that) sometimes videos are epilepsy triggering.
These things WONT be solved or are partly solved by adding an #AGE header.

[dgruss]

Well, the video can be considered for that.

You can query the age information i locally have for any usdb id here: https://gruss.cc/usdx/age_info.php?id=31479

[Baklap4]

You can query the age information i locally have for any usdb id here: https://gruss.cc/usdx/age_info.php?id=31479

That's based on your perception of the age it should be whereas for other users it might be something different.
Personally i think tools should not use that but rather just let the end-user decide on their selection of songs.

It might be a baseline or be hinted but shouldn't be an auto-mapped field

[dgruss]

i agree that this is something individual. I just wanted to provide the perspective that the video can be considered as well for whatever age you want to configure.

[barbeque-squared]

Imo this is all way too complex. I'm going to side with the original poster of #54 but I'd have worded it as follows:

• #RATING:E = Everyone*
• #RATING:T = Teen
• #RATING:M = Mature
• TBD what to do about songs without rating, but probably just don't show any if restricted to E or T

99% of all songs will very clearly fall into exactly one of these three categories. Does this mean you can let a 5-year old play E unsupervised? Absolutely not, but whoever thinks it's okay to let a 5-year old unsupervised with something like "Karaoke" has much bigger issues anyway.

Some examples:

• things like Lady Gaga or Sabaton will almost always be T. They're clearly not E, and they're also clearly not M.
• things like The Aristocats and The Lion King will be E. Are they as kid-friendly as Baby Shark and Dora? Idk, never seen them, but I'm pretty sure that out of the four, Baby Shark and Dora are the more traumatizing ones anyway
• Karen, you do realize that for your daughter's 10-year old birthday party you can just limit it to E, but when it's just you two, you can probably also enable T but be selective about which ones you sing and which ones you don't.

See also https://www.fimfiction.net/articles/tag-information

[dgruss]

i can follow that reasoning and it would serve my use case just the same, where maybe I'd like to have a fourth level between E and T.

However, it's pretty clear that this E<T<M is a scale as well, just that E, T and M are not nicely comparable. you could also define age levels 0 1 2 and let users and games decide how to use and present that to the user.

then again, why only 3 levels? maybe someone can think of 4, or 100? i would prefer a feature that leaves more room for users to define how they want to use it rather than define 3 levels that make sense to me and you. maybe age is the wrong word for the tag. Maybe it should be framed more generically, e.g. as a numeric suitability level or restriction level. #SUITABILITY ? #RESTRICTION ?

What I'm mostly interested in is:

• A single, comparable scale (monotonic, sortable)
• Locally assignable
• Interpretable by the game for filtering/searching
• not semantically overloaded with cultural meaning

Whether the UI shows that as "Age 12", "Level 2", or maps it to E/T/M-style labels is nothing the format should standardize.
There could even be a game or different settings in the game, that use the same underlying format for display any of these three. With a numeric scale, that is possible. By narrowing it down to E/T/M on the format level already, we are unnecessarily restrictive, eliminating for any game to provide a finer scale than E/T/M.

Complexity and storage-wise E/T/M has no advantage. the age similarly needs 1 or 2 chars of storage. Complexity with a numerical range is (as said above) even slightly lower.

So conceptually I'd argue that a numeric value (0..N) that has no intrinsic meaning other than "lower = more suitable for broader audiences" would be the best for the format. That keeps flexibility, while having lower complexity, and still enabling the filtering use case that apparently several people in this thread would like to have.

[basisbit]

"E, T and M" imho would be a really bad long-term solution, because that is not how age rating works in many countries and there is not even anything close to a standardized understanding of what these letters would mean.

Let's shorten this discussion here: If you want it to eventually be merged into USDX, please come up with something roughly similar to

#Age:{["DE",6],["US",13],["SG",99],["FR",0],["default",13]}

For example this sample song would suggest requiring being at least age 6 in Germany because of mild violence, while requiring being at least 13 in USA because of strong language, while not being legal in Singapore at all because of religious reasons, and some "whatever the author felt like being a sane default" for those countries that so far no one has specified the age rating for for this specific song. This could also be added to USDB and similar sites and maybe some scripts could be written to look up data from different public sources.

I personally don't care about syntax (so feel free to adjust me above sample as you see fit), but have strong feelings regarding usefulness and longevity of the format standardization, at least for what of it gets adopted for USDX.

[dgruss]

i would be fine with the format you propose, where the user can then decide what to select and filter for

[randompersona1]

"E, T and M" imho would be a really bad long-term solution, because that is not how age rating works in many countries and there is not even anything close to a standardized understanding of what these letters would mean.

Let's shorten this discussion here: If you want it to eventually be merged into USDX, please come up with something roughly similar to

#Age:{["DE",6],["US",13],["SG",99],["FR",0],["default",13]}

For example this sample song would suggest requiring being at least age 6 in Germany because of mild violence, while requiring being at least 13 in USA because of strong language, while not being legal in Singapore at all because of religious reasons, and some "whatever the author felt like being a sane default" for those countries that so far no one has specified the age rating for for this specific song. This could also be added to USDB and similar sites and maybe some scripts could be written to look up data from different public sources.

I personally don't care about syntax (so feel free to adjust me above sample as you see fit), but have strong feelings regarding usefulness and longevity of the format standardization, at least for what of it gets adopted for USDX.

What's wrong with the solution @dgruss proposed right above you? A nested map-like structure does not fit the rest of the format at all IMO. And it seems overburdening to maintain.

It has been mentioned in this thread already, but age is not a good way to think about this. #THRESHOLD works, but surely there is a better english word to encapsulate what we are trying to solve here.

To be exceedingly clear: #AGE/#THRESHOLD/#SUITABILITY/#RESTRICTION is not a general public property of a song. The tag is added manually and locally only for filtering in games. Databases and the like should strip the tag during uploading. All I want is that a (format-compliant) game recognizes the tag, and has a number input for filtering that hides all songs lower than the input value.

[dgruss]

i would be fine with either way. the "default" value that @basisbit proposed would allow for any of these use cases and the extended format would even allow for country-wise limits that are based on actual information out there

[basisbit]

It feels like we may need to find some consent / agree on some solution on this sooner rather than later.

Regulators in a few jurisdictions (for example Brazil, UK, some USA states) are increasing pressure around age signalling / age assurance and age-appropriate access for content and apps. Platform operators tend to (and are actively starting to) pass such requirements down the chain via store policies + platform APIs, and publishers/developers then have to implement enforcement of these.

If/when compliance to this gets enforced, it would be better if the UltraStar ecosystem had a standardized way to represent this in song files (and thus in song creation/management tooling), rather than every game/tool inventing its own local solution. Without a common tag, some implementations might end up taking a strict approach (e.g., hiding/locking songs with no explicit rating for minors), which in my opinion would be worse for compatibility and for users.

[basisbit]

how about something like this?:

A.16. The #AGE Header

The #AGE header indicates the minimum age suitability boundary for a song.
To accommodate both local private use and international legal compliance, the value can be a single integer, or a comma-separated list of age boundaries prefixed by a region or rating authority.

Syntax: age-entry *( comma *WSP age-entry )
age-entry = [ region-or-authority colon ] age-limit
region-or-authority = 2*ALPHA
age-limit = 1*3DIGIT

• age-limit MUST be a positive integer representing the minimum appropriate age in years (e.g., 12, 14, 18).
• region-or-authority SHOULD be an ISO 3166-1 alpha-2 country code (e.g., DE, US, GB) or a recognized rating board (e.g., USK, PEGI).

If an age-entry has no prefix, it serves as the global or local default.

Examples:

• #AGE: 14 (Simple local boundary, game filters anything above 14)
• #AGE: 12, DE:16, US:13 (Default is 12, but legally required to be restricted to 16 in Germany and 13 in the US).

Implementations MAY use these values to filter or hide songs. For multi-region strings, an implementation SHOULD prioritize the age limit that matches the user's localized system settings before falling back to the default value.

[randompersona1]

This may be controversial, but I think implementations SHOULD use the value to filter or hide songs. The user has full control over their songs. In the age of ChatGPT, it is trivial to batch rewrite the age tag for all songs. The syncer and song creation tools will have an explicit option to enable/disable writing the tag. So the only reason the tag would be there is because the user wants to be able to filter their songs.

SHOULD still allows a fully compliant game that doesn't implement this filtering, but the ability to filter should be encouraged IMO.

Edit: although the other filtering headers don't have this sentence at all. Hm.