forum

[Proposal] Official sources should have a priority over the metadata allowance.

posted
Total Posts
19
Topic Starter
Tyistiana
Referred case: Case 1

Greetings.
This proposal suggested changing the Ranking Criteria from,

Ranking Criteria - Metadata allowance wrote:

If a mapset track was contributed to by multiple artists, they may be listed with commas inbetween. If there are 3 or more contributing artists and they are not part of one officially labelled group, Various Artists or other descriptive artist labels may be used instead.


to


Ranking Criteria - Metadata allowance wrote:

If the official sources didn't use any symbol between the multiple artists, they may be listed with commas in between. If there are 3 or more contributing artists and they are not part of one officially labelled group, Various Artists or other descriptive artist labels may be used instead.


Why?
Because the artist's intention should be kept and we should respect it as much as possible. The current wording of Ranking Criteria allows the mapper to use the commas between the multiple artists and making the official metadata sources become one of the variations of choosable artist metadata only as see in Case 1.

Giving a priority to the official metadata sources over the allowance would be a better thing in my opinion. This may correspond to the Ranking Criteria, "Official Sources must be used as references for metadata unless none are available." better too.

---

How does this proposal affect?
Example 1
Map: Cocoa (CV: Sakura Ayane) & Syaro (CV: Uchida Maaya) - Popcorn Happening!
Official metadata source: Source 1
As you see, they're using & between the multiple artists ココア(CV.佐倉綾音)&シャロ(CV.内田真礼)

The current Ranking Criteria makes these sets of metadata acceptable:
  1. Cocoa (CV: Sakura Ayane) & Syaro (CV: Uchida Maaya) - Popcorn Happening!
    This set of metadata following the official metadata source.
  2. Cocoa (CV: Sakura Ayane), Syaro (CV: Uchida Maaya) - Popcorn Happening!
    This set of metadata following the allowance "If a mapset track was contributed to by multiple artists, they may be listed with commas inbetween".

This proposal will make the latter set of metadata (orange text) becomes unacceptable as per rule "Official Sources must be used as references for metadata unless none are available." Thus, the symbol between the multiple artists should be followed by the official sources only. The only acceptable set of metadata according to this proposal is "Cocoa (CV: Sakura Ayane) & Syaro (CV: Uchida Maaya) - Popcorn Happening!" for this example.


Example 2
Map: Petit Rabbit's with beans, Hayami Saori, Kayano Ai - Waai Waai Try!
Official metadata source: Source 1
The official source writes the artist as the following:
ココア(CV.佐倉綾音)チノ(CV.水瀬いのり)
リゼ(CV.種田梨沙)千夜(CV.佐藤聡美)
シャロ(CV.内田真礼)マヤ(CV.徳井青空)
メグ(CV.村川梨衣)青山ブルーマウンテン(CV.早見沙織)
モカ(CV.茅野愛衣)
As you can see, the official source didn't use any symbol between the multiple artists.

In this case, this proposal will allow us to use the commas between the multiple artists and become one of the variations of choosable artist metadata.
ココア(CV: 佐倉綾音), チノ(CV: 水瀬いのり), リゼ(CV: 種田梨沙), 千夜(CV: 佐藤聡美), シャロ(CV: 内田真礼), マヤ(CV: 徳井青空), メグ(CV: 村川梨衣), 青山ブルーマウンテン(CV: 早見沙織), モカ(CV: 茅野愛衣)


---

TL;DR - The aim of this proposal is like, if a mapset track was contributed to by multiple artists, they may be listed with commas when the official sources said so or when the official sources didn't use any symbol between the multiple artists.

The proposal wording will make the official metadata sources has a priority over the allowance for the symbol between multiple artists.


---

That's it. Any kind of feedback is highly appreciated!
Faputa
I support. It was strange that the current RC doesn't have priority on the original source over metadata allowance. I sometimes think that the allowance is supposed to work when in cases where if official sources give vague continuity on its way of listing the artists hypothetically, or if the original source has a long list of artists, but some of them can be combined into officially labelled groups.

This allowance should primarily benefit those with the above case, and not giving a choice other than official source's listing formats. Like Petit Rabbit's with beans, Hayami Saori, Kayano Ai - Waai Waai Try! in the topic post, since some artists are combined to their existing groups in the benefit of fitting all into the artist field, commas make sense for this constructed artist list.
Serizawa Haruki
Agreed, the symbols used by the artist should take priority over the allowance.

The same logic can also be applied to this allowance though:

Current RC wrote:

For songs where the composer(s) and singer(s) are different people, the singer(s) may be listed after the composer(s) or circle/group name following a feat. indicator.

For example, if a song's official metadata source uses "composer & singer", it should not be allowed to use "composer feat. singer".

New RC wrote:

For songs where the composer(s) and singer(s) are different people, the singer(s) may be listed after the composer(s) or circle/group name following a feat. indicator, unless the official sources use a different symbol between them.
pishifat
isn't the point of standardization to not require use of artist's silly symbols? like there's no problem with using & to separate artists, but if it were some stupid separating symbol that makes reading worse, it'd be wrong to make the comma unacceptable imo
Serizawa Haruki
What would an example of a "silly" symbol be? I honestly can't think of any songs with something like that
Nao Tomori
hearts, dots, stars, anything that isn't & or / or + or , lol
Serizawa Haruki
Aren't those already covered by the rule "Special unicode characters must be filtered to their nearest standard equivalent or removed from the romanised fields within a .osu file. ★ ☆ ⚝ ✪ and the likes are substituted to an asterisk. Other special characters are to be romanised or dropped on case-by-case basis." ?

Like, you wouldn't be able to romanize such symbols anyway (except stars, but I think it's not a big problem to have Artist1 * Artist 2 because that's still readable) so in those cases you'd use the allowance. It would need to be included into the wording somehow though, which makes it a bit complicated
pishifat
in cases of "artist [& or / or + or ,] artist", the symbol implies collaboration, while that isnt true for * or anything else that would be romanised differently. it feels backwards to add an exception to the proposed rule to use commas for these because the current rule allows you to use commas freely when the symbol is dumb
Volta
Dumb or not it's the artist's freedom of expression and you can't just allow it to be changed without consent. If you don't want to follow the official sources then don't use their song to map and go find another artist with smarter format.

I mean, for example, multiple artists format like SawanoHiroyuki[nZk]:Gemie might looks dumb af for some people but that's what the artist expressed, and it shouldn't be allowed to be changed to SawanoHiroyuki[nZk], Gemie or SawanoHiroyuki[nZk] feat. Gemie as we please just because it's easier to read imo.
tatatat
I have to disagree. I see the current ruling as useful standardization, just as all TV Size markers are standardized to (TV Size), you could also say that the way the artist writes TV Size is artist expression, but standardization is more important.
Serizawa Haruki
Allowances are not a form of standardization though because they don't apply to all maps in the same way, they're optional. It can even lead to inconsistencies where previous ranked maps are being ignored as you can see in the example above
honne
This could be a possible allowance since it wouldn't be too different from source material (with all respect it should be) but I feel it wouldn't be messing with the artist's intentions most of the time, similar to the example you used with "Cocoa (CV: Sakura Ayane) & Syaro (CV: Uchida Maaya) - Popcorn Happening!" inferring a duet due to which would be more accurate than having commas.

This is just one example of why the standardization rules were in place so that these things would be more simplified and less complicated.
pishifat

Volta wrote:

I mean, for example, multiple artists format like SawanoHiroyuki[nZk]:Gemie might looks dumb af for some people but that's what the artist expressed, and it shouldn't be allowed to be changed to SawanoHiroyuki[nZk], Gemie or SawanoHiroyuki[nZk] feat. Gemie as we please just because it's easier to read imo.
nobody has changed formatting for this artist in maps they promote to ranked before, so im not sure where the problem is. with the current wording, people are given the choice to use an understandable symbol in situations where it'd be better to use a different symbol

regarding op's example of [& vs ,] in a song with 2 artits, i agree that it'd be wrong to change & to a comma because the & makes more sense. a mapper hopefully doesn't have a smooth bowling ball brain and can evaluate the benefit of & over a comma in this case. the artist's choice here makes sense, but doesn't in all cases, which is why ur allowed to use a comma at your discretion. forcing artist's choice isn't the end-all way to handle this
Serizawa Haruki

pishifat wrote:

regarding op's example of [& vs ,] in a song with 2 artits, i agree that it'd be wrong to change & to a comma because the & makes more sense. a mapper hopefully doesn't have a smooth bowling ball brain and can evaluate the benefit of & over a comma in this case. the artist's choice here makes sense, but doesn't in all cases, which is why ur allowed to use a comma at your discretion. forcing artist's choice isn't the end-all way to handle this


The problem is that a mapper could decide to do it and nobody would be able to force them to change it because it's allowed.
pishifat
has this ever happened?
Volta
Well, someone can make it happen.
pishifat
i dont think it's worth it to change the rc to prevent a thing that doesnt need preventing
clayton
just because something is allowed doesn't mean it's the best option. RC isn't here to tell you the best option in every specific case
pishifat
if there's no examples of this causing problems i'll archive
Please sign in to reply.

New reply