READ THE DRAFT HERE

Hi!

In our effort to update the RC to be more relevant and easier to comprehend we rearranged this section quite a bit.

1. The draft is ordered by target field or category that each rule, guideline, allowance applies to
2. We took the existing criteria as a base and added explanations to edge cases where appropriate (everywhere) (real)

As the draft contains formatting that cannot be replicated in BBCode, please read the draft on GitHub. We focused on providing more examples to explain the more esoteric cases.
Most of the examples came out hilarious while illustrating the point clearly, we hope to keep them around if possible

Please leave comments, suggestions and questions over here!
This draft has, to my knowledge, no dependencies on other sections as far as its formatting and content is concerned.

Nice-to-have Stuff we don't have yet

We want to include a guide & flowchart for the primary sources article, or alternatively a guide on which hoops to jump through to find metadata. If you want to help with that feel free to reach out!

Feedback

Please use this forum thread to drop feedback on the draft! Alternatively, for smaller questions and such join the RC discord instead!
First round of revision starts either when feedback on this thread dies down or two weeks from now on 2024-03-23 (yyyy-mm-dd)

Thanks for reading!

ToDo list currently empty

thank you oko \o/

very nice formatting making it clear to understand

from what i see on new RC, it seems to say Inori Minase is allowed, Minase Inori is not allowed because theres official romanization for her


is this correct?

im against this idea cuz it makes name look weird when theres multiple arists and name order is diffetent despite they all japanese

also artist may get official romanisation after maps are ranked making it inconsistent with past ranked

Drum-Hitnormal wrote:

very nice formatting making it clear to understand

from what i see on new RC, it seems to say Inori Minase is allowed, Minase Inori is not allowed because theres official romanization for her


is this correct?

im against this idea cuz it makes name look weird when theres multiple arists and name order is diffetent despite they all japanese

also artist may get official romanisation after maps are ranked making it inconsistent with past ranked

It's a guideline based off what's commonly seen and recognized, so if it's debatable for any reason that should ideally be decided on per case. Not a hard set rule right there

Drum-Hitnormal wrote:

very nice formatting making it clear to understand

from what i see on new RC, it seems to say Inori Minase is allowed, Minase Inori is not allowed because theres official romanization for her


is this correct?

im against this idea cuz it makes name look weird when theres multiple arists and name order is diffetent despite they all japanese

also artist may get official romanisation after maps are ranked making it inconsistent with past ranked

“Aim to match Ranked or Loved beatmaps. Follow what is most recent and common, then verify that metadata is correct and fix as needed.”

Because of this guideline, you wouldn't be required to use Inori Minase. Furthermore, she uses both regularly which function as two official romanisations, there is no requirement to use either.

Drum-Hitnormal wrote:

from what i see on new RC, it seems to say Inori Minase is allowed, Minase Inori is not allowed because theres official romanization for her

Hmm I think it can work woth ways, we had a talk in BN server about it a few weeks prior here.

Which makes me disagree with the Artist name order rework since it will cause situations like what Doormat said, I think there should be some sort of leniency with it in some cases like (CV: Minase Inori) as an example. I personally think the current RC about this is fine.

Edit:

Noffy wrote:

It's a guideline based off what's commonly seen and recognized, so if it's debatable for any reason that should ideally be decided on per case. Not a hard set rule right there

It's clearly stated as a Rule in the draft though, therefore it should either be stated as a guideline or be taken as something to follow 100% of the times no?

Oh I see it now, I'll put that on the to-fix list because we covered it as an optional but extremely encouraged item like 3 other times O.o

E: gist should now be fixed to remove the contradictory statement, /o/

Noffy wrote:

Oh I see it now, I'll put that on the to-fix list because we covered it as an optional but extremely encouraged item like 3 other times O.o

E: gist should now be fixed to remove the contradictory statement, /o/

Yea, the draft had this



which is slightly different and more shitposty but fixed now, as it was clearly a communication error

Uhh... what's the difference?

they could be interpreted as errors or typos but clearly are stylistic choices

Okoratu wrote:

they could be interpreted as errors or typos but clearly are stylistic choices

I see... okay understandable

1) "Any form of feat., feat, ft., featuring, etc. that are indicating an artist featured in the song must be written as feat."

Having "feat." at the beginning looks like a typo not gonna lie

2) I'm very happy to see the Marker part of the RC be clarified more but I think the wording could be a little bit better. Maybe something like this

Before: (Game Ver.) "Use this when there is an existing length marker such as ~Game Size~, (Game Size), game OP edit, OP Version."

After: (Game Ver.) "Songs from a video game with existing markers such as ~Game Size~, (Game Size), game OP edit, OP Version. must be standardised to (Game Ver.)

^ Same would apply to Movie Ver. perhaps, added "must" instead because it's something that should be followed always I believe

Also may I ask what's gonna happen with (Short Ver.) Markers? So far we still are using it including some FA songs that were licenced that have that metadata. e.g beatmapsets/2121497

This might be edited with more questions/suggestions as I go

Looks amazing so far, so much better than what we have right now.

THOUGHTS:

1.
For the symbols table in the "Handling Symbols" field, this is in the table right below "Recommended Romanisation":

- "When multiple options exist, the one used for romanisation depends on context."

It's minor but having this in the same box as "recommended romanisation" is a little stuffed. It's probably for emphasis, but as a reader we tend to read what the row means, and any extra info is somewhere else. It's a bit counterintuitive.
I feel like that info should be put somewhere below the table instead of the same box that defines the row it's in. More cohesive.

-
2a.

Under "Rules" in the Artist segment, there's:

- Commas must have a trailing space unless intentionally stylised otherwise.

Add a comma after "space" pls xD it's easy to gloss over text without a punctuation for a pause.

2b.
Also under the Artists segment, in "Marker Rules" there's:

- Any form of vs., versus, etc. indicating collaboration between artists must be written as vs..

Should the first "vs." be "vs"? This repeats twice (second time at the end.)

-
3.
Under the Guidelines for Artists:

- For doujin circles, you should use any of the following options:

Just a little confused with this one. The word choice implies it's up to the mapper's choice to pick one of these, which sounds like potential for an inconsistent metadata mess :')
If it's a case-by-case basis kind of thing, I'd replace "any" with "one". One word change but it helps avoid this I think.

momoyo wrote:

1) "Any form of feat., feat, ft., featuring, etc. that are indicating an artist featured in the song must be written as feat."

Having "feat." at the beginning looks like a typo not gonna lie

2) I'm very happy to see the Marker part of the RC be clarified more but I think the wording could be a little bit better. Maybe something like this

Before: (Game Ver.) "Use this when there is an existing length marker such as ~Game Size~, (Game Size), game OP edit, OP Version."

After: (Game Ver.) "Songs from a video game with existing markers such as ~Game Size~, (Game Size), game OP edit, OP Version. must be standardised to (Game Ver.)

^ Same would apply to Movie Ver. perhaps, added "must" instead because it's something that should be followed always I believe

Also may I ask what's gonna happen with (Short Ver.) Markers? So far we still are using it including some FA songs that were licenced that have that metadata. e.g beatmapsets/2121497

Added a small extension to Game Ver
i think movie ver is fine as is

Short ver folds into #### Ver, but i think it's common enough to justify having

Monoseul:
1) will add some form of clarification
2a done
2b clarified and moved around

re momoyo short ver: fixed

Sounds good now I have nothing else to mention I think

I'm back again part 2

Monoseul wrote:

3.
Under the Guidelines for Artists:

- For doujin circles, you should use any of the following options:

Just a little confused with this one. The word choice implies it's up to the mapper's choice to pick one of these, which sounds like potential for an inconsistent metadata mess :')
If it's a case-by-case basis kind of thing, I'd replace "any" with "one". One word change but it helps avoid this I think.

Didn't get any response from this, could double check this one

4.
Under "Guidelines" in the Source section.

- If a track...

> was first released and later featured or tied to a piece of media, using the source field is optional.
> has been featured in multiple pieces of media, any option can be used as the source. Website names are only valid sources, if the song...
> and website are tied to specific cultural phenomena such as Newgrounds, etc.
> was composed as a website theme or background song.

I'm confused about the formatting between the second and third points. The 2nd point cuts off and 3rd seems to be a continuation, not sure if this is a mistake or it's intentional but it's pretty confusing atm when reading through the current format.

-
5.
Under "Cyrillic Writing" for Romanisation.

> Use the BGN/PCGN System.
> Е and е to ye if it stands alone or after a, e, ё, и, о, у, ы, э, ю, я, й, ъ, ь. In other cases, use e.
> ё to o if it comes after ж, ч, ш, or щ. In other cases, use yo.
> Ignore any other rules in the file provided, as these are either irrelevant or would not help in the game.
> For other characters, refer to the first page of this document

Third point is a little confusing. If it's referring to the document below it I think the 3rd and 4th point should be switched - reader can easily assume it was referring to the first point but that's just a wiki page of the system.
Also, pedantic but, would change "refer to the first page of this document" to "refer to the first two pages of this document" since the characters list last for two pages. Clarity :')

-
Other than that I don't have much else to say :-) anything about the content itself I don't really have a comment on. Hope this gets through at some point~

Monoseul wrote:

I'm back again part 2

Monoseul wrote:

3.
Under the Guidelines for Artists:

- For doujin circles, you should use any of the following options:

Just a little confused with this one. The word choice implies it's up to the mapper's choice to pick one of these, which sounds like potential for an inconsistent metadata mess :')
If it's a case-by-case basis kind of thing, I'd replace "any" with "one". One word change but it helps avoid this I think.

Didn't get any response from this, could double check this one

Nah. The choice is up toe the mapper and what's most recognizable here and what the doujin circle commonly uses - it's how doujin music has been handled historically. People have been arguing for the formatting that looks "neatest" and we dont want to take that away

Monoseul wrote:

4.
Under "Guidelines" in the Source section.

- If a track...

> was first released and later featured or tied to a piece of media, using the source field is optional.
> has been featured in multiple pieces of media, any option can be used as the source. Website names are only valid sources, if the song...
> and website are tied to specific cultural phenomena such as Newgrounds, etc.
> was composed as a website theme or background song.

I'm confused about the formatting between the second and third points. The 2nd point cuts off and 3rd seems to be a continuation, not sure if this is a mistake or it's intentional but it's pretty confusing atm when reading through the current format.

it's not supposed to be like that, fixed...

Monoseul wrote:

-
5.
Under "Cyrillic Writing" for Romanisation.

> Use the BGN/PCGN System.
> Е and е to ye if it stands alone or after a, e, ё, и, о, у, ы, э, ю, я, й, ъ, ь. In other cases, use e.
> ё to o if it comes after ж, ч, ш, or щ. In other cases, use yo.
> Ignore any other rules in the file provided, as these are either irrelevant or would not help in the game.
> For other characters, refer to the first page of this document

Third point is a little confusing. If it's referring to the document below it I think the 3rd and 4th point should be switched - reader can easily assume it was referring to the first point but that's just a wiki page of the system.
Also, pedantic but, would change "refer to the first page of this document" to "refer to the first two pages of this document" since the characters list last for two pages. Clarity :')

-
Other than that I don't have much else to say :-) anything about the content itself I don't really have a comment on. Hope this gets through at some point~

oops yea switched these around

The structure is way better and easier to understand overall. I just have some minor corrections and suggestions:

General -> Rules:
- Metadata fields, except for tags, over 81 characters must be shortened.

I think it would sound more natural to change the order within the sentence like this: Metadata fields over 81 characters, except for tags, must be shortened.

General -> Guidelines -> When multiple metadata options are available:
Aim to match Ranked or Loved beatmaps. Follow what is most recent and common, then verify that metadata is correct and fix as needed.

The exception "This does not apply if the artist intentionally uses a different alias for different song or album releases." should probably be added here.

General -> Guidelines -> When multiple metadata options are available:
- Official romanisations/translations are preferred for romanised fields, so long as they are easily found and commonly recognised.

I tried bringing this up before but it was never addressed so I'll say it again: Official translations should not be preferred for romanised fields because unofficial translations don't exist (or at least are not allowed) so the only thing they can be preferred over are unofficial romanisations, which doesn't make much sense because it's called romanised field after all so giving priority to translations is not very logical, they should be optional.
This point also conflicts with the sentence under the Romanisation section "If the metadata has an official translation or romanisation, it is allowed to be used as-is in the romanised fields instead of romanising it yourself." because that sounds like an allowance and not like a preference/priority.

General -> Allowances -> For remixes, covers, or performances:
- The original artist may be used in the artist field, as long as the title field is modified to show that the song is not the original version. This marker should be in parentheses and contain the remix/cover artist or the performer as well as a descriptor. For example, the track triangles composed by cYsmix covered by mocha4life can be formatted as cYsmix - triangles (mocha4life Cover).

The explanation regarding the formatting is ambiguous because first it says "This marker should be..." and then "can be formatted as...", if it's an allowance it should probably just be "can/may" and not "should", right?

Handling Symbols

This could just be simplified to "Symbols" to make it more consistent with the other headers.

Handling Symbols -> Rules:
- The following Unicode Symbol subsets should have leading and trailing spaces when they can be romanised:
Supplemental Arrows-A, Supplemental Arrows-B, Miscellaneous Symbols and Arrow
Dingbats
Miscellaneous Symbols

This does not apply if the artist purposefully uses symbols in ways that do not suggest spaces. Other character sets are handled on a case-by-case basis.

Why are these specific subets of symbols listed here? Are there other categories where this rule doesn't apply?

Artist -> Marker Rules

The term "marker" here isn't ideal because it's also used for Title -> Markers where it refers to different things. It would probably be clearer if a different term was used here or if the other markers are labaled as "Length/Version Markers" to distinguish them.

Artist -> Marker Rules -> Character (CV: Voice Actor) and Character (VO: Voice Actor):
- If other artist(s) use a similar marker, such as c.v., CV., ~cv~, etc., replace it with this format.

This could be written in an easier way like "Similar markers, such as c.v., CV., ~cv~, etc., must be replaced with this format."
Was the point about "For live action, credit the voice actor only." left out intentionally?

Artist -> Allowances:
- Artists may be simply listed with ,, & or + in between each artist.

Instead of "+" I'd use "x" here because it's much more common. Also, I assume this is not supposed to be an exhaustive list of symbols, therefore "etc." should be added to indicate that.

Title -> Rules -> When a track is made of two or more songs you must do either one of the following:
- List the titles clearly with a dividing symbol in-between such as ,, &, +, /, etc.

Again I'd replace "+" with a more common symbol/term, in this case "vs.", for example used in beatmapsets/325158 and beatmapsets/707380.

Markers

Is the reason why some of them are listed under Rules and some under Guidelines because the first group is always added and the second group only in case the song already has the marker is some form? I can't think of a concrete term but maybe there's a clearer way to indicate that these are 2 separate lists because right now they're both just labeled as "Marker Categories". I get that each of them is within the Rules and Guidelines section respectively, but still.

Markers -> Rules:
- Songs with length markers must fully replace them with the standard marker.

Perhaps change this to "Songs with existing length markers must fully replace them with the relevant marker from the list below." to make it clearer.

Markers -> Rules:
- Songs without a length marker that fit a rules marker category must add the corresponding one at the end.

This one also took me a few times of re-reading it to understand what it means, it could be changed to something like this to explain it better: "Songs without a length marker that fit one of the marker categories below must add the corresponding one at the end.

Markers -> Rules -> (Cut Ver.)

I think it would be a good idea to add "Songs that are a full loop of a looping track will not be considered cut." as clarification.

Markers -> Guidelines

The 2 sentences at the beginning should be listed with bullet points because they're guidelines themselves, not just an explanation for this section.
It would also be nice if the order of (Short Ver.) and (Game Ver.) was reversed so that they're in order from most common to least common.

Markers -> Guidelines -> Marker Categories -> (Game Ver.):
- Commonly found in video game songs. Use this marker when there is an existing length marker such as ~Game Size~, (Game Size), game OP edit, OP Version.

The part about "Commonly found in video game songs" could be removed entirely because it should be obvious and also doesn't really provide useful information for the guideline.
I'm also not sure about "OP Version" because this is different from the others in the sense that it doesn't include the word "Game" at all. Are there examples where this has been changed to (Game Ver.)?

Markers -> Guidelines -> Marker Categories -> (Short Ver.):
- Usually used in game openings to signal that a longer version actually exists.

Similarly, this part seems rather unnecessary and could be omitted.

Markers -> Guidelines -> Marker Categories -> (##### Ver.):
When song titles already have a length marker not covered above, it should be changed to a descriptive (#### Ver.) marker using title case.

What does "descriptive" refer to here?
There should be an additional "#" here to be consistent with the first mention of this marker.
I also think it would be important to add an example for this one to make it easier to understand the use cases.

Markers -> Guidelines -> Marker Categories -> (##### Ver.):
Exceptions would be for when the length marker is so stylised it is considered part of the title, such as Pippiquest (Pippi x Mocha Romantic Movie Remix Edition)

Is this strictly about stylisation or just having an extravagant version naming? Assuming it's the latter, I don't really see why it wouldn't still fall under the same guideline since you could very well just replace "Edition" with "Ver." without ruining the naming scheme. Stylisation would be more related to things like formatting (the entire point of standardized markers is to make formatting consistent) and capitalisation (which is already addressed in the allowance of this section).

Markers -> Allowances:
- Alternate casing for markers may be used if the rest of the song title is stylised to fit the formatting.

"Alternate" should probably be changed to "Alternative" to match the previous instance of this allowance.

Sources -> Rules:
The Source field must be precise. Use the most specific source instead of series or project names, unless multiple sources within a series apply.

The word "general" could be added before "series or project names" to emphasize that it's an umbrella term.

Sources -> Guidelines

Bullet points should be added before "If a track..." and "Website names are only valid sources, if the song...".

Tags -> Rules -> Tags must include the following items when applicable:
- Guest difficulty creators, storyboarders, skinners, and hitsounders.

I'd reword this to "Guest difficulty, hitsound, storyboard and skin creators." because "skinners" sounds strange and it's more consistent this way.
It could be useful to add this sentence from the current ranking criteria because it's something a lot of people don't know or get wrong often: "Usernames in tags containing single characters separated by spaces must have the spaces replaced with underscores."

Tags -> Rules -> Tags must include the following items when applicable -> At least one song genre and one language tag:
- If the lyrics in the song have no meaning, use other as the language tag.

I don't think putting "other" in the tags is useful, in this case it would be better to just use "gibberish" or something like that.

Tags -> Rules -> Tags must include the following items when applicable:
- Tags must be related to the beatmap. Describing the style, song, storyboard, video, or background content is fine.

The "is fine" part sounds a bit weird here, it could be simplified to "Tags must be related to the beatmap, such as describing the style, song, storyboard, video, or background content."
Maybe also add the part about tags not being misleading from the current RC?

Tags -> Guidelines -> Tags should include the following items when applicable:
- Easily searched versions of difficult-to-write parts of the metadata.

I suggest adding "... such as contractions with the apostrophe removed" since it's a common example.

Tags -> Guidelines -> Tags should include the following items when applicable

Another bullet point mentioning things like album/EP/single name could be added.

Romanisation -> Language and Writing-system Romanisation Rules -> Japanese:
- ā to aa, ū to uu, ē to ee

Shouldn't there also be "ī to ii" here (even if it's rare)?

Romanisation -> Language and Writing-system Romanisation Rules -> Chinese:
For other dialects: Left to mapper's discretion, contacting a native speaker is recommended.

In my opinion this would sound better as a complete sentence like "For other dialects, it's left to the mapper's discretion. Contacting a native speaker is recommended."

Romanisation -> Language and Writing-system Romanisation Rules -> Other languages or systems not covered:
- Use a system common and recognisable.

I'd change the order around to "Use a common and recognisable system." to make it sound more natural.

Thanks for all the work! This is definitely a huge improvement. Some questions here. Indeed many of them are not raised from this rewrite, but I hope them being clarified at this chance (I guess many of them already have consensus in practice so they only require clarification):

Handling Symbols -> Rules

The following Unicode Symbol subsets should have leading and trailing spaces when they can be romanised:

What does the "can be romanised" mean? How to tell if a Unicode Symbol can be romanised? I think it meant "if it's not removed in the romanised field" (which, if I understand correctly, can be a mapper's preference in some cases)?


Source -> Rules

The Source field must be used, if the song...
directly originates from or is tied to a piece of media, except for albums and hosting websites.

I kinda like the original RC where some examples of "media" is listed (such as a video game, movie, series, event, etc.) since "media" itself is a very abstract concept

Tags -> Rules

Tags must include the following items when applicable:
At least one song genre and one language tag.
For instrumental tracks, instrumental is the language tag.

Could we have a definition/guideline on what is an "instrumental" track? e.g. which is correct, beatmapsets/1807003 , beatmapsets/1501157 , or either is fine? btw, I didn't see any mention of the genre and language setting on the website?

Romanisation -> Rules

Loan words must use the source language's spelling when romanised.

what qualifies for a "loan word"? e.g. should 上海/シャンハイ be Shanhai or Shanghai(上海 in Chinese)，トンネル be tonneru or tunnel? (tbh idk how this could be imposed in practice since languages borrow words from each other like every year, and it can be hard to tell if a word is borrowed or already "localized")

When the song uses repeat words in the title or artist where one is unicode, and the other is a romanisation, the romanised field must use the romanisation only and remove the duplicate word.

what does this mean? Let's say a song is named "にゃん! Nyan!", should it be romanised to "Nyan!", or "Nyan! Nyan!", or "! Nyan!"(wtf)? idk but I guess this rule is intended for very specific cases and not used in this way?

Japanese
Capitalise following title case1, ...

it would be nice if there are examples on common words in Japanese that should not be capitalized.

https://gist.github.com/Okorin/25240445fdbce1febc603553e5eb94ae#marker-categories-1
(##### Ver.)
When song titles already have a length marker not covered above, it should be changed to a descriptive (#### Ver.) marker using title case.

second (####) has to have 5 (five) hashtags, this is so broken

Serizawa Haruki wrote:

The structure is way better and easier to understand overall. I just have some minor corrections and suggestions:

General -> Rules:
- Metadata fields, except for tags, over 81 characters must be shortened.

I think it would sound more natural to change the order within the sentence like this: Metadata fields over 81 characters, except for tags, must be shortened.

went with
**Metadata fields over 81 characters must be shortened.** This does not apply to the tags.

Serizawa Haruki wrote:

General -> Guidelines -> When multiple metadata options are available:
Aim to match Ranked or Loved beatmaps. Follow what is most recent and common, then verify that metadata is correct and fix as needed.

The exception "This does not apply if the artist intentionally uses a different alias for different song or album releases." should probably be added here.

No idea what that adds. A sentence like that seems fairly implied all around, maybe good to have. Will keep this for more discussion

Serizawa Haruki wrote:

General -> Guidelines -> When multiple metadata options are available:
- Official romanisations/translations are preferred for romanised fields, so long as they are easily found and commonly recognised.

I tried bringing this up before but it was never addressed so I'll say it again: Official translations should not be preferred for romanised fields because unofficial translations don't exist (or at least are not allowed) so the only thing they can be preferred over are unofficial romanisations, which doesn't make much sense because it's called romanised field after all so giving priority to translations is not very logical, they should be optional.
This point also conflicts with the sentence under the Romanisation section "If the metadata has an official translation or romanisation, it is allowed to be used as-is in the romanised fields instead of romanising it yourself." because that sounds like an allowance and not like a preference/priority.

I disagree. Translations are often more recognizable and that's the only job the metadata section has. to make sure people remember the song...

The phrasing "official translations" was chosen to make it very obvious that fan translations are not primary sources. which is in the context of the draft self-evident but not always when reading through

the "official translation" bit was just to make this clearer again. I don't really see the conflict here.

Will need further deliberation from the others

Serizawa Haruki wrote:

General -> Allowances -> For remixes, covers, or performances:
- The original artist may be used in the artist field, as long as the title field is modified to show that the song is not the original version. This marker should be in parentheses and contain the remix/cover artist or the performer as well as a descriptor. For example, the track triangles composed by cYsmix covered by mocha4life can be formatted as cYsmix - triangles (mocha4life Cover).

The explanation regarding the formatting is ambiguous because first it says "This marker should be..." and then "can be formatted as...", if it's an allowance it should probably just be "can/may" and not "should", right?

The second sentence having guideline wording i think makes sense here. If you choose to follow the allowance, which you're free not to, you SHOULD really follow it like a guideline...

Maybe more opinions would be good too.

Serizawa wrote:

Handling Symbols

This could just be simplified to "Symbols" to make it more consistent with the other headers.

Handling Symbols -> Rules:
- The following Unicode Symbol subsets should have leading and trailing spaces when they can be romanised:
Supplemental Arrows-A, Supplemental Arrows-B, Miscellaneous Symbols and Arrow
Dingbats
Miscellaneous Symbols

This does not apply if the artist purposefully uses symbols in ways that do not suggest spaces. Other character sets are handled on a case-by-case basis.

Why are these specific subets of symbols listed here? Are there other categories where this rule doesn't apply?

The symbol subsets listed contain all the symbols I could find that we actually care about. The idea of the last sentence is to allow for flexibility and adding future sets to this if we find them relevant.

Most other unicode subsets do not in fact contain symbols but letters and thus dont really apply, yes

Serizawa wrote:

Artist -> Marker Rules

The term "marker" here isn't ideal because it's also used for Title -> Markers where it refers to different things. It would probably be clearer if a different term was used here or if the other markers are labaled as "Length/Version Markers" to distinguish them.

Artist -> Marker Rules -> Character (CV: Voice Actor) and Character (VO: Voice Actor):
- If other artist(s) use a similar marker, such as c.v., CV., ~cv~, etc., replace it with this format.

This could be written in an easier way like "Similar markers, such as c.v., CV., ~cv~, etc., must be replaced with this format."
Was the point about "For live action, credit the voice actor only." left out intentionally?

Hm. not really. it is implied through "Use this format when an animated character is credited as the singer of a song.", but i added it as a second bullet point as it can't hurt

Serizawa wrote:

Artist -> Allowances:
- Artists may be simply listed with ,, & or + in between each artist.

Instead of "+" I'd use "x" here because it's much more common. Also, I assume this is not supposed to be an exhaustive list of symbols, therefore "etc." should be added to indicate that.

Instead i added another "etc.", i dont think the symbol of choice matters and should be restricted

Serizawa wrote:

Title -> Rules -> When a track is made of two or more songs you must do either one of the following:
- List the titles clearly with a dividing symbol in-between such as ,, &, +, /, etc.

Again I'd replace "+" with a more common symbol/term, in this case "vs.", for example used in beatmapsets/325158 and beatmapsets/707380.

stop hating the plus lol. added `vs.` to this list as for song compilations that makes sense. for artist linking that should be a direct choice instead i think

Serizawa wrote:

Markers

Is the reason why some of them are listed under Rules and some under Guidelines because the first group is always added and the second group only in case the song already has the marker is some form? I can't think of a concrete term but maybe there's a clearer way to indicate that these are 2 separate lists because right now they're both just labeled as "Marker Categories". I get that each of them is within the Rules and Guidelines section respectively, but still.

That's the idea yes didn't find a better way to do this. Will take into consideration for rework

Serizawa wrote:

Markers -> Rules:
- Songs with length markers must fully replace them with the standard marker.

Perhaps change this to "Songs with existing length markers must fully replace them with the relevant marker from the list below." to make it clearer.

yea

Serizawa wrote:

Markers -> Rules:
- Songs without a length marker that fit a rules marker category must add the corresponding one at the end.

This one also took me a few times of re-reading it to understand what it means, it could be changed to something like this to explain it better: "Songs without a length marker that fit one of the marker categories below must add the corresponding one at the end.

ok

serizawa wrote:

Markers -> Rules -> (Cut Ver.)

I think it would be a good idea to add "Songs that are a full loop of a looping track will not be considered cut." as clarification.

added "This marker can be dropped if the full song consists of multiple fully looping parts. Often applies to background music that loops twice."

Serizawa wrote:

Markers -> Guidelines

The 2 sentences at the beginning should be listed with bullet points because they're guidelines themselves, not just an explanation for this section.
It would also be nice if the order of (Short Ver.) and (Game Ver.) was reversed so that they're in order from most common to least common.

sure

Serizawa wrote:

Markers -> Guidelines -> Marker Categories -> (Game Ver.):
- Commonly found in video game songs. Use this marker when there is an existing length marker such as ~Game Size~, (Game Size), game OP edit, OP Version.

The part about "Commonly found in video game songs" could be removed entirely because it should be obvious and also doesn't really provide useful information for the guideline.
I'm also not sure about "OP Version" because this is different from the others in the sense that it doesn't include the word "Game" at all. Are there examples where this has been changed to (Game Ver.)?

"OP Version": if it's the game version then i think it should be changed to (Game Ver.) yes
removed the sentence that said the floor is made of floor

Serizawa wrote:

Markers -> Guidelines -> Marker Categories -> (Short Ver.):
- Usually used in game openings to signal that a longer version actually exists.

Similarly, this part seems rather unnecessary and could be omitted.

Disagree, that is helpful information as to why the marker is a thing

Serizawa wrote:

Markers -> Guidelines -> Marker Categories -> (##### Ver.):
When song titles already have a length marker not covered above, it should be changed to a descriptive (#### Ver.) marker using title case.

What does "descriptive" refer to here?
There should be an additional "#" here to be consistent with the first mention of this marker.
I also think it would be important to add an example for this one to make it easier to understand the use cases.

Markers -> Guidelines -> Marker Categories -> (##### Ver.):
Exceptions would be for when the length marker is so stylised it is considered part of the title, such as Pippiquest (Pippi x Mocha Romantic Movie Remix Edition)

Is this strictly about stylisation or just having an extravagant version naming? Assuming it's the latter, I don't really see why it wouldn't still fall under the same guideline since you could very well just replace "Edition" with "Ver." without ruining the naming scheme. Stylisation would be more related to things like formatting (the entire point of standardized markers is to make formatting consistent) and capitalisation (which is already addressed in the allowance of this section).

- Long version, extended mix, extended ver., etc.
- fixed the amount of hashtags differing
- we should really add an example to make it clear that anything about versions would fall in here yes i agree will take into consideration

Serizawa wrote:

Markers -> Allowances:
- Alternate casing for markers may be used if the rest of the song title is stylised to fit the formatting.

"Alternate" should probably be changed to "Alternative" to match the previous instance of this allowance.

alternate is the NA version of that vword sometimes oops yea

Serizawa wrote:

Sources -> Rules:
The Source field must be precise. Use the most specific source instead of series or project names, unless multiple sources within a series apply.

The word "general" could be added before "series or project names" to emphasize that it's an umbrella term.

sure

Serizawa wrote:

Sources -> Guidelines

Bullet points should be added before "If a track..." and "Website names are only valid sources, if the song...".

yea

Serizawa wrote:

Tags -> Rules -> Tags must include the following items when applicable:
- Guest difficulty creators, storyboarders, skinners, and hitsounders.

I'd reword this to "Guest difficulty, hitsound, storyboard and skin creators." because "skinners" sounds strange and it's more consistent this way.
It could be useful to add this sentence from the current ranking criteria because it's something a lot of people don't know or get wrong often: "Usernames in tags containing single characters separated by spaces must have the spaces replaced with underscores."

reworded to something like urs
second point to be discussed, generally yeah i think we just lost that information and it should still stay i think. Tags / rules is what i was thinking

serizawa wrote:

Tags -> Rules -> Tags must include the following items when applicable -> At least one song genre and one language tag:
- If the lyrics in the song have no meaning, use other as the language tag.

I don't think putting "other" in the tags is useful, in this case it would be better to just use "gibberish" or something like that.

We can do that, but i was thinking about online search with that one i dunno if other as the category will show up that way....

will take to discussion to maybe add nonsense lyrics or gibberish to the tags

serizawa wrote:

Tags -> Rules -> Tags must include the following items when applicable:
- Tags must be related to the beatmap. Describing the style, song, storyboard, video, or background content is fine.

The "is fine" part sounds a bit weird here, it could be simplified to "Tags must be related to the beatmap, such as describing the style, song, storyboard, video, or background content."
Maybe also add the part about tags not being misleading from the current RC?

sure
added another sentence to just outright sya the same thing again

Serizawa wrote:

Tags -> Guidelines -> Tags should include the following items when applicable:
- Easily searched versions of difficult-to-write parts of the metadata.

I suggest adding "... such as contractions with the apostrophe removed" since it's a common example.

disagree i dont wanna describe contractions.
listed examples instead that refer back to our funny cysmix nonsense

serizawa wrote:

Tags -> Guidelines -> Tags should include the following items when applicable

Another bullet point mentioning things like album/EP/single name could be added.

Added that but with a disclaimer for songs that are re-released over and over

Romanisation -> Language and Writing-system Romanisation Rules -> Japanese:
- ā to aa, ū to uu, ē to ee

Shouldn't there also be "ī to ii" here (even if it's rare)?dunno. will have to bring it up

serizawa wrote:

Romanisation -> Language and Writing-system Romanisation Rules -> Chinese:
For other dialects: Left to mapper's discretion, contacting a native speaker is recommended.

In my opinion this would sound better as a complete sentence like "For other dialects, it's left to the mapper's discretion. Contacting a native speaker is recommended."

dunno disagree on that one but also dont really care for changing it let's see what the rest thinks

serizawa wrote:

Romanisation -> Language and Writing-system Romanisation Rules -> Other languages or systems not covered:
- Use a system common and recognisable.

I'd change the order around to "Use a common and recognisable system." to make it sound more natural.
[/quote]
sure

this sentence was very human

Dude fuck the quote formatting i will not go back and fix it this is literally unreadable in this editor

I will answer in gold instead

-infinite- wrote:

Thanks for all the work! This is definitely a huge improvement. Some questions here. Indeed many of them are not raised from this rewrite, but I hope them being clarified at this chance (I guess many of them already have consensus in practice so they only require clarification):

Handling Symbols -> Rules

The following Unicode Symbol subsets should have leading and trailing spaces when they can be romanised:

What does the "can be romanised" mean? How to tell if a Unicode Symbol can be romanised? I think it meant "if it's not removed in the romanised field" (which, if I understand correctly, can be a mapper's preference in some cases)?

media, except for albums and hosting websites.

I kinda like the original RC where some examples of "media" is listed (such as a video game, movie, series, event, etc.) since "media" itself is a very abstract concept

[color="goldenrod"]>>>>> should add a list for something, sure[/color]

Tags -> Rules

Tags must include the following items when applicable:
At least one song genre and one language tag.
For instrumental tracks, instrumental is the language tag.

Could we have a definition/guideline on what is an "instrumental" track? e.g. which is correct, beatmapsets/1807003 , beatmapsets/1501157 , or either is fine? btw, I didn't see any mention of the genre and language setting on the website?

[color="goldenrod"]>>>>> website stuff will be its own section and not covered here, as for definition of instrumental dunno will need deliberation[/color]

Romanisation -> Rules

Loan words must use the source language's spelling when romanised.

what qualifies for a "loan word"? e.g. should 上海/シャンハイ be Shanhai or Shanghai(上海 in Chinese)，トンネル be tonneru or tunnel? (tbh idk how this could be imposed in practice since languages borrow words from each other like every year, and it can be hard to tell if a word is borrowed or already "localized")

[color="goldenrod"]>>>>> tbh this is just written out what has been going on and i dont think there's been problems with it... will bring it up in the revision though[/color]

When the song uses repeat words in the title or artist where one is unicode, and the other is a romanisation, the romanised field must use the romanisation only and remove the duplicate word.

what does this mean? Let's say a song is named "にゃん! Nyan!", should it be romanised to "Nyan!", or "Nyan! Nyan!", or "! Nyan!"(wtf)? idk but I guess this rule is intended for very specific cases and not used in this way?

[color="goldenrod"]>>>>> no, more like カケラ～Kakera～ where one part of the title is just the reading of the first[/color]

Japanese
Capitalise following title case1, ...

it would be nice if there are examples on common words in Japanese that should not be capitalized.
[color="goldenrod"]>>>>> true, should add that.[/color]IT REMOVES COLOR FOM QUOTES

AAAAAAAAAAAAAAAAAAAAAAAAA

in the symbol section , can we add a list of commonly used symbols and how many spaces required for each?
for the single symbol usage, not when its used with 2 symbol and grouping stuff

majority of people dont have english as their 1st language and it becomes very subjective if a symbol needs 0, 1 or 2 spaces

example: \ | ~ - # & % etc

Drum-Hitnormal wrote:

in the symbol section , can we add a list of commonly used symbols and how many spaces required for each?
for the single symbol usage, not when its used with 2 symbol and grouping stuff

majority of people dont have english as their 1st language and it becomes very subjective if a symbol needs 0, 1 or 2 spaces

example: \ | ~ - # & % etc

I think that is a good idea in general, added it to the talking points

For the (Live ver.), what do you think about allowing specific name of lives in the markers? For example, beatmapsets/2095125/discussion/-/generalAll#/4246722/11308302 would be (CANDY LIVE Ver.) or like Taylor Swift - Blank Space (The Eras Tour Ver.)

achyoo wrote:

For the (Live ver.), what do you think about allowing specific name of lives in the markers? For example, beatmapsets/2095125/discussion/-/generalAll#/4246722/11308302 would be (CANDY LIVE Ver.) or like Taylor Swift - Blank Space (The Eras Tour Ver.)

sure. maybe this should be clearer.

wrote down the open points as clearly as i could: https://gist.github.com/Okorin/80f6134493088fd04b6ab1a44d78204b

also included all open proposals and a quick prelim opinion on them to go with as an agenda for revision

One thing the current RC is kind of unclear about is how to use the "other" tag, and I don't think that gets fully addressed in this writeup.

• 
  At least one song genre and one language tag.

1. For instrumental tracks, instrumental is the language tag.
2. For tracks in artificially created languages add conlang to tags and use its name as the language tag.
3. If the lyrics in the song have no meaning, use other as the language tag.

If we need to select "other" as the genre or language, should we be adding "other" to the tags or not? For example, if the map is a country song, should the tags field contain "other country" or just "country"?

Likewise, if the song is in Turkish, should the tags contain "other turkish" or just "turkish"?

My interpretation has always been not to actually put "other" in the tags because it doesn't make sense in terms of searchability, then to just put in the actual relevant genre/language.

1. If the lyrics in the song have no meaning, use other as the language tag.

This point also gets a little confusing considering the "other" debacle. In situations where songs have meaningless or minimal lyrics or vocals, my intuition has been to stick with "instrumental" as the language tag.

Example: the "Somebody scream" sample is a "meaningless" English lyric, but Galaxy collapse is pretty clearly an instrumental tack, not an "other" track.

I think it would be best to leave the language as "instrumental" if the vocals/lyrics are "meaningless"

sure, can clarify.

current draft is clear though in the sense that usage of other is only even suggested if no "other" label fits.

I think i disagreed with that but was kinda outvoted lol because searching for "other" is kinda weird as you'd just get the umbrellaterm with like no real upside out of search results as it's so imprecise

i brought up that i tagged it on beatmapsets/1051145#osu/2196797 alongside gibberish cuz the song isi sung in gibberish and abstract nonsense. people generally preferred to have that in tags over "other", too. so i agree we should probably make it clearer

will put on the agenda

Hey guys,

Several of us in the RC server just went through the to-do list quoted below and implemented proposals that got notable support and did not conflict with our current draft, as well as a number of other updates based on the feedback we've gotten.

The updated draft with revision history can be viewed at our gist https://gist.github.com/Okorin/25240445fdbce1febc603553e5eb94ae

We'll work on doing a final update either in 2 weeks (April 7th) or when the thread dies, whichever comes first.

Okoratu wrote:

achyoo wrote:

For the (Live ver.), what do you think about allowing specific name of lives in the markers? For example, beatmapsets/2095125/discussion/-/generalAll#/4246722/11308302 would be (CANDY LIVE Ver.) or like Taylor Swift - Blank Space (The Eras Tour Ver.)

sure. maybe this should be clearer.

wrote down the open points as clearly as i could: https://gist.github.com/Okorin/80f6134493088fd04b6ab1a44d78204b

also included all open proposals and a quick prelim opinion on them to go with as an agenda for revision

All difficulties in a beatmap set must have identical title, artist, tag, source, and beatmapsetid fields.

(continuing convo from the google doc) I don't think beatmapsetid needs to be here, but if it will be included, then I also don't think Metadata is the right page for it. it's not a setting you can change in game and almost nobody will need to interact with this for the purpose of ranking a map. to be exhaustive, something like this would be the actual "rule" if you want to regulate everything a mapper can possibly mess with here...

All difficulties in a beatmap set must have identical title, artist, tag, source, and beatmapsetidand source fields.
The BeatmapID and BeatmapSetID options in every beatmap file must be set to the correct online values.

---------------------------------

Metadata fields over 81 characters must be shortened.

just making sure, this intentionally applies to Source as well?
(and technically your wording makes it apply to tags, but it's pretty hard to misunderstand this when the tag limit rule comes right after it)

---------------------------------

When a remix or cover appears to havehas a typo in the song name compared to the original track, use the original spelling instead, unless the typo is an intentional stylisation. If it is unclear, a discussion should be held to come to a consensus on which to use. Below are examples with a song calledremix of a song titled triangles:
- triangls should be changed to triangles
- triANGELS (angelic remix) should be left as triANGELS (angelic remix)as-is
- 3angle5 should be left as 3angle5as-is

---------------------------------

when this draft says "a discussion should be held" (in a few places), does it mean in the casual sense like, whoever is willing to contribute, or is there some kind of process built for this that BN/NAT use? does this need to be clarified?

---------------------------------

If the music artist is the beatmap host, they may adjust the title freely.

this obviously makes sense if they're releasing the song on osu, but is it a problem if it's already well-known by another name? or what if it already has a different name in an FA listing? I don't feel strongly either way but these seem relevant questions to consider

Krimek's comments in discord convinced me that this whole allowance is unnecessary. the artist themselves is a primary source and so the other rules already cover how to handle the metadata they provide

---------------------------------

This does not apply if the artist purposefully uses symbols in ways that do not suggest spaces.

honestly I just don't know what you mean by this, maybe an example would help. the way I'm reading it currently, I could argue that any artist did not "suggest spaces" if there's not already a literal space

---------------------------------

→ and similar arrows | -> or -->
← and similar arrows | <- or <--

---------------------------------

*Note: These points also apply for any artist credits present in the title field.*

doesn't rly matter, just suggesting because it's a wiki convention

---------------------------------

Use a trailing space for markers such as vs., feat., or CV:, etc. when marking artists. If a word comes before the marker, a leading space must also be used.

---------------------------------

Marker Rrules

---------------------------------

for each of the 3 marker rules, I think the top bullet can be discarded, and just use the first sub-bullet as the main bullet instead. so it will end up something like...

1. Any form of vs, versus, Vs, etc. indicating collaboration between artists must be written as vs..
2. Any form of feat, ft., featuring, Feat., etc. that are indicating an artist featured in the song must be written as feat..
3. Use the Character (CV: Voice Actor) or Character (VO: Voice Actor) format when an animated character is credited as the singer of a song.
   
   1. Similar markers...
   2. For live action...

---------------------------------

the doujin circle options probably shouldn't all be in code style like that, because only one ("feat.") is demonstrating a format. I think it can be rewritten as a single sentence, where only the 3rd example makes use of a code style format (and maybe even that is not necessary)

---------------------------------

If the combined artist is too long and no official group name is available, a descriptive artist label may be used in the artist fields instead. If nothing fits, use Various Artists instead.

I would like an example of a "descriptive artist label" cuz I'm not sure exactly what would pass for this

---------------------------------

When a character's voice actor is credited as the singer of a song sung in-character, the (CV: Voice Actor) format is allowed toCharacter (CV: Voice Actor) format may be used.

---------------------------------

will finish later o// reviewed up to "Markers" heading

Did most of this stuff, except for crossing out the etc. when it would lose information. We also added examples when possible, some of them are really funny.

we did not reformat the markers section to use more words as the point was making it easier to parse.

Unfortunately I couldn't attend the last meeting so I don't exactly know what has and hasn't been discussed but I'll respond to the open points from my previous post to make sure nothing is missed.

Okoratu wrote:

Serizawa Haruki wrote:

General -> Guidelines -> When multiple metadata options are available:
- Official romanisations/translations are preferred for romanised fields, so long as they are easily found and commonly recognised.

I tried bringing this up before but it was never addressed so I'll say it again: Official translations should not be preferred for romanised fields because unofficial translations don't exist (or at least are not allowed) so the only thing they can be preferred over are unofficial romanisations, which doesn't make much sense because it's called romanised field after all so giving priority to translations is not very logical, they should be optional.
This point also conflicts with the sentence under the Romanisation section "If the metadata has an official translation or romanisation, it is allowed to be used as-is in the romanised fields instead of romanising it yourself." because that sounds like an allowance and not like a preference/priority.

I disagree. Translations are often more recognizable and that's the only job the metadata section has. to make sure people remember the song...

The phrasing "official translations" was chosen to make it very obvious that fan translations are not primary sources. which is in the context of the draft self-evident but not always when reading through

the "official translation" bit was just to make this clearer again. I don't really see the conflict here.

Will need further deliberation from the others

If the purpose of the "official translation" wording was merely to imply that "fan" translations are not allowed, this is probably not the best way to do it and should be explicitly written out if anything. And yes, translations are sometimes more recognizable, but not always, so they shouldn't automatically take precedence. This topic was discussed previously here: community/forums/posts/8876767

Okoratu wrote:

Serizawa Haruki wrote:

Title -> Rules -> When a track is made of two or more songs you must do either one of the following:
- List the titles clearly with a dividing symbol in-between such as ,, &, +, /, etc.

Again I'd replace "+" with a more common symbol/term, in this case "vs.", for example used in beatmapsets/325158 and beatmapsets/707380.

stop hating the plus lol. added `vs.` to this list as for song compilations that makes sense. for artist linking that should be a direct choice instead i think

I'm not sure adding an extra bullet point for the "vs." mentioning mashups is ideal here because mashups often use other symbols like "x" or "/" as well so it's a little misleading because it implies these symbols in the line above are not used for mashups. For the sake of simplicity, I'd just add "vs." to that list above (or leave it out completely if you think it's unnecessary).

Okoratu wrote:

Serizawa Haruki wrote:

Markers -> Rules -> (Cut Ver.)

I think it would be a good idea to add "Songs that are a full loop of a looping track will not be considered cut." as clarification.

added "This marker can be dropped if the full song consists of multiple fully looping parts. Often applies to background music that loops twice."

Ok, but it also needs to be specified that it can only be dropped if the cut is one full loop since a cut of only half of it would still need to be labeled as such. I think the second sentence is kind of unnecessary but it doesn't really matter I guess.

Serizawa Haruki wrote:

Markers -> Guidelines -> Marker Categories -> (##### Ver.):
Exceptions would be for when the length marker is so stylised it is considered part of the title, such as Pippiquest (Pippi x Mocha Romantic Movie Remix Edition)

Is this strictly about stylisation or just having an extravagant version naming? Assuming it's the latter, I don't really see why it wouldn't still fall under the same guideline since you could very well just replace "Edition" with "Ver." without ruining the naming scheme. Stylisation would be more related to things like formatting (the entire point of standardized markers is to make formatting consistent) and capitalisation (which is already addressed in the allowance of this section).

This wasn't replied to I think, and I still don't really understand how this exception would work or why it needs to be there, could this be clarified?

Okoratu wrote:

Serizawa Haruki wrote:

Tags -> Guidelines -> Tags should include the following items when applicable

Another bullet point mentioning things like album/EP/single name could be added.

Added that but with a disclaimer for songs that are re-released over and over

Seems good, just a small suggestion to say the same thing in a more general sense: "If a song is re-released multiple times, tagging just one of them is fine."

Okoratu wrote:

Serizawa Haruki wrote:

Romanisation -> Language and Writing-system Romanisation Rules -> Japanese:
- ā to aa, ū to uu, ē to ee

Shouldn't there also be "ī to ii" here (even if it's rare)?

dunno. will have to bring it up

Was this discussed by any chance? If there's no particular reason not to include it, adding it would be good for the sake of completeness.

Okoratu wrote:

Serizawa Haruki wrote:

Romanisation -> Language and Writing-system Romanisation Rules -> Chinese:
For other dialects: Left to mapper's discretion, contacting a native speaker is recommended.

In my opinion this would sound better as a complete sentence like "For other dialects, it's left to the mapper's discretion. Contacting a native speaker is recommended."

dunno disagree on that one but also dont really care for changing it let's see what the rest thinks

I suppose it doesn't matter but the reason why I brought it up is because other points are generally written as whole sentences too.



--------------------------------------------------------------------------------------------------------------------

A few things regarding what has been added/changed in the latest draft version, as well as some new things:

General -> Allowances -> For remixes, covers, or performances:
If the music artist is the beatmap host, they may adjust the title freely.

I agree with clayton that this allowance is unneeded, as the music artist they are already allowed to adjust the title as they see fit, no matter if they're the beatmap host or not.

Title -> Markers

What is the reasoning for things like (Extended Ver.) and (Long Ver.) to be part of a guideline and not a rule like (Short Ver.) and (Game Ver.)? Basically, -Short Version- must be standardized to (Short Ver.) but -Long Version- only should be standardized?
It's also a bit strange that the "Rules", "Guidelines" and "Allowances" headers are smaller compared to elsewhere. I know that they are sub-headers of "Markers" here, but I think it would be easier to do it like you did with the Artist section where you named it "Marker rules" instead and kept it on the same level.
Another thing I noticed is that the term "length marker" is often used in this section, but I don't think this includes all the possibilities as some markers might indicate different versions of a song that don't differ in length but in some other aspect such as language or composition. Therefore I think "length/version marker" or even just "version marker" would be more accurate.

Title -> Markers -> Rules:
Unofficial versions that match an official version in terms of content, order, and length are considered official and must add the appropriate marker.

This should probably be updated to reflect the recently added/adjusted clause in the current RC: "Songs that are intentionally edited to recreate an official version are not considered cut/extended versions/edits. This only applies if the audio is nearly indistinguishable from the official version."

Title -> Markers -> Rules -> Markers you must add when appropriate

Could you switch the order of the first 2 bullet points around so it matches the corresponding ones under "Markers that you must standardise, but not always add" (the first one being for songs with existing markers and the second for songs without markers?)
The wording of these is also structured differently across the two sections, for example the Rules have "Songs with/without length markers..." while the Guidelines have "If there are similar/no markers..." so it would be nice to standardize it.

Title -> Markers -> Rules -> Markers you must add when appropriate:
Only songs that also increase the pitch of the audio can use (Nightcore Mix). Otherwise, use (Sped Up Ver.).

So this was changed after all? I'm not sure keeping this type of distinction makes sense considering like 99 % of sped up songs also use a pitch increase, meaning almost only (Nightcore Mix) would still be used.
While we're on that topic, what are people's opinions on Nightcore "Ver." as opposed to "Mix"? Is there a good reason for using Mix other than it being the most common choice in osu! historically?
Also, what about slowed down edits of songs? They're becoming more popular lately so they could perhaps warrant their own marker.

Title -> Markers -> Rules -> Markers that you must standardise, but not always add -> (Movie Ver.):
Use this when there's an existing marker like Movie EDIT, ~movie size~, Movie Cut, (Movie Version).

Wouldn't it make sense to do this similarly to (Game Ver.) where it includes "for tracks used in games."?

Tags -> Rules:
Names with spaces between single characters like -[M o c h a]- need to be tagged as -[M_o_c_h_a]-

I suggest explaining the rule fully first and then making an example, right now it's a mix of both so it's weird. Maybe change it to something similar to the old RC wording "Usernames containing single characters separated by spaces must have the spaces replaced with underscores. For example, the username -[M o c h a]- has to be tagged as -[M_o_c_h_a]-."

Tags -> Rules -> Tags must include the following items when applicable -> At least one song genre and one language tag.:
- If the lyrics in the song have no meaning, the language tag is not required.
- If the genre and language are not obvious, include as many as applicable.

The first one is still somewhat ambiguous because lyrics can technically not make sense and still consist of words that clearly belong to a language (like singing random words without any context or connection between them). It should be less about making sense and more about whether the song's lyrics can be assigned to a certain language or not (including conlang).
The second one is less clear to me, I understand that some songs don't fall into any specific genre but are more like a combination of different genres but what kind of examples would this tackle in terms of language, songs with more than one language?



In some places (see below), examples are mentioned without naming them as such, while in most others they are preceded by "for example", "like" or "such as". Adding something like that would be good for consistency.

Tags -> Guidelines:
Remixes, arrangements and mashups should tag their specific genres as well as the original song's genres. If an Anime song is remixed to become mostly Electronic, tag both.

Tags -> Guidelines -> Tags should include the following items when applicable -> Easily searched versions of difficult-to-write parts of the metadata:
- don't, you're and the like should tag dont, youre.
- 3angle5 by cYsm1X should add triangles and cYsmix.
- Differences between American and British English, such as color and colour.

Romanisation -> Rules:
When the song uses repeat words in the title or artist where one is unicode, and the other is a romanisation, the romanised field must use the romanisation only and remove the duplicate word. ソレイユ -Soleil- would become just Soleil and ピポピポ -People People- would become People People.

From community/forums/posts/8876767 (last paragraph): The source field is different from the other fields due to the lack of a separate romanised field. However, romanisations and translations are still used there sometimes. Should that continue to be the case or would it be more consistent to always use the original unicode source and put the rest in the tags? Is this something that will change with lazer?

Haven't formed opinions/responses on the rest, but regarding

"ī to ii"

for whatever reason, beyond me i don't know why, ī is only used as a romanisation when foreign words are involved for modified hepburn, and never native words unlike the other extended vowels that normally end up with macrons either way.

the thing is, in osu! we already change foreign loan words to their original spelling, like ビール would be Beer, not Bīru , so because of this, ī would never come up in the first place when romanising japanese yourself following osu's standards. As a result, it would be redundant and potentially misleading to mention it.

Noffy wrote:

Haven't formed opinions/responses on the rest, but regarding

"ī to ii"

for whatever reason, beyond me i don't know why, ī is only used as a romanisation when foreign words are involved for modified hepburn, and never native words unlike the other extended vowels that normally end up with macrons either way.

the thing is, in osu! we already change foreign loan words to their original spelling, like ビール would be Beer, not Bīru , so because of this, ī would never come up in the first place when romanising japanese yourself following osu's standards. As a result, it would be redundant and potentially misleading to mention it.

Not an expert in Japanese, but it seems that sometimes ー can be used in native Japanese words in certain circumstances, like そーっと (as a variant of そっと) listed in that pdf (https://www.loc.gov/catdir/cpso/romanization/japanese.pdf). Also a real example: beatmapsets/586877#osu/1454384: if following the rule of that pdf ほっしーの would become hosshī no (Long i vowels are always romanized as ii (double i), except when long i is written with a lengthening bar (ー). In that case, it is romanized with a macron (ī)).

In addition, even if the ー in a word actually come from a loan word, it still could be unclear how it should be handled. As a random example, how to romanise ビー玉? Shall we consider ビー a loan word (comes from ビードロ(vidro)), and if so, what should it be converted to?

Personally I think it would be clearer if we abandon the concept of ā, ū, etc., but instead convert ー to a kana and do kana-by-kana conversion. But maybe that's only my own opinion.

btw, should そーっと be converted to sootto or soutto?

agree with the arguments in favour of including "ī to ii"

-infinite- wrote:

btw, should そーっと be converted to sootto or soutto?

personally, I find sootto much more intuitive; the chouonpu is just lengthening the そ instead of replacing a vowel of an established word (both そおっと and そうっと seem widely used so can't decide based on that)

-infinite- wrote:

how to romanise ビー玉? Shall we consider ビー a loan word (comes from ビードロ(vidro))

too mangled to be converted in any sensible way imo, just romanise normally

We'll add the funny umlaut i to cover any edge cases where it exists then (never encountered this in 8 years of metadata though). I think writing an entire new romanisation system is out of scope.


Haruki wrote:
> Wouldn't it make sense to do this similarly to (Game Ver.) where it includes "for tracks used in games."?

Games are very clearly defined media, and it needs to be clear when (Op ver) turns into (Game Ver.) or not, which is specifically when it's from a game.

Movies are not as clear-cut of a media between special long episodes, OVA releases, etc, there are a lot of gray areas for longer form video media. So we'll just do it when they explicitly say some kind of MOVIE edit in the existing title.



Oko will post in a bit with other items. Most of the wording clarity I believe the current writing is pretty clear what do you and don't do, even if it's not written identically every time. If any are unclear from grammar issues it should get covered with the wiki PR in the future.

OK replying in order u posted points in

1. > official translation
the topic u linked was u writing a wall and no one reacting to it meaningfully... anyways i dont think this matters since it's not been a problem so including it is just clutter?

2. > vs. mashups
just changed the sentence order to make this clearer.

3. > drop cut ver for full loops
we reworded this a bit; didnt like either suggestion for this as it was super word salad

4. > #### ver
if the marker is part of the title to a point that dropping it would remove information, which the example clearly illustrates, you can keep it. thats what the example is there for

5. > album / ep / single blah
did somethign similar

6. > aaaa i i ii i japanese
done

7. > complete sentence in chinese
we dont think it matters, plus that whole section reads like a checklist + wiki guys will force us to abide by whatever wiki mojo we didnt think of anyways so we'll just wait an see

8. > allowance is useless
disagree, allowances are there to begin with to prevent asking "is this allowed" so they'll be redundant in almost all cases. they're there for clarity

9. > title extendo version
idk i think you've been reading an outdated version of this draft, the only thing in guidelines is #### ver atm. the headings are smaller cuz they are subheadings
did the version / length whatever thing though. some of them are gone now, some are length / version, some are just version depending on context now


10. > add sentence from last change that was supposed to take 3 days
yea

11. > switch order for marker rules
the order reflects the order you check this stuff in and i think it reads worse if you swap it around

12. > sped up version dies now
i think thats fine and the people who care about the distinction can fight the RC on it if it is a problem
nightcore mix has similar usage as tv size which is why the marker is mix and not Ver. also Nightcore mix is the main choice outside of osu, not just in osu lol

13. > for tracks used in games
what is and isnt a game is way clearer than what is and isnt a movie. plus for games it was added to clarify the OP Version to contextualise or something

14. > mocha
OK but like writing it down as a rule is such a braintwister that just giving the example as an instruction works way better tho

15. > Language menainglessnesss :
- we tried rewording it but i think if there is no meaning tagging a language just cuz some words / samples are in there is misleading and just shouldnt be done lol so current works
> language not obvious
- added example

16. > soruce in source lang
i think that should remain up for preference as long as both are there it doesnt really matter

im not gonna comment on lazer

Okay I have no idea if this metadata thing is being talked about anymore, but I had a possible suggestion of what if a marker called “(Slower Ver.)” (or something similar) was made for songs that are slowed down since sometimes those types of songs are really popular?

Would that be under the “Extended Exit” category or could that be its own new thing?

hm. I think it would be analogous to (Sped Up Ver.) I assume it would be (Slowed Down Ver.) / (Slowed Ver.) as a logical counterpart. That or (Daycore Mix) as i think that's what the opposite of the Nightcore mod is called?

Okoratu wrote:

hm. I think it would be analogous to (Sped Up Ver.) I assume it would be (Slowed Down Ver.) / (Slowed Ver.) as a logical counterpart. That or (Daycore Mix) as i think that's what the opposite of the Nightcore mod is called?

I think I like the idea of having it be (Slowed Down Ver.) since it's pretty much the opposite of (Sped Up Ver.).

Also yeah (Daycore Mix) would make sense as it is the opposite to Nightcore.

I have started a PR for this: https://github.com/ppy/osu-wiki/pull/11563

as for including slowed down ver in it at the moment; after thinking about it for a bit it would already be covered by (#### Ver.) guideline in the draft. We can revisit taht point if they become popular enough that labeling them is a concern i think

Sure, sounds good.

I still think there are some points that need to be adjusted or at least discussed further before this is finalized because they seem inconsistent, unclear or inaccurate. But there's no point in going back and forth between the same 2-3 people, so I won't go into detail right now. More opinions would be needed since there wasn't a lot of contribution in this thread.

I'm not sure what you mean to say with that.

Pretty sure we cleared your last comments up in the draft (community/forums/posts/9511326). If you feel that is insufficient i think you should elaborate

Okoratu wrote:

I'm not sure what you mean to say with that.

Pretty sure we cleared your last comments up in the draft (community/forums/posts/9511326). If you feel that is insufficient i think you should elaborate

It's not really about clearing things up, but rather about the fact that as far as I'm aware only a handful of people actually checked this draft and considering it includes actual rule/guideline changes and not only a different wording/formatting, it doesn't seem enough to make sure everything is in order. Perhaps this could be posted in the BN server or somewhere for better visibility?

Here's what I think is still an issue (but other people might have other concerns):

Okoratu wrote:

1. > official translation
the topic u linked was u writing a wall and no one reacting to it meaningfully... anyways i dont think this matters since it's not been a problem so including it is just clutter?

Maybe I wasn't clear enough but the thread I linked was mostly to provide additional reasoning as to why giving priority to translations is not a good idea, especially point 1) of Quenlla's post: community/forums/posts/8876323

It does matter because it means that for songs that happen to have an official translation you're forced to use that instead of a romanisation which seems arbitrary. You should be able to choose what to use based on what is more well-known etc.

Nothing needs to be included, only the word "translations" should be removed and that's it, so there is no clutter here.

(I also have my reservations about always prioritizing official romanisations over self-made ones but that's less of an issue.)

Okoratu wrote:

4. > #### ver
if the marker is part of the title to a point that dropping it would remove information, which the example clearly illustrates, you can keep it. thats what the example is there for

I'm confused, the guideline this exception is part of doesn't say anything about dropping markers entirely, it just says to standardize them, like (Extended Version) becomes (Extended Ver.). In the case of (Pippi x Mocha Romantic Movie Remix Edition) it just becomes (Pippi x Mocha Romantic Movie Remix Ver.) which doesn't remove information in my eyes.

Okoratu wrote:

8. > allowance is useless
disagree, allowances are there to begin with to prevent asking "is this allowed" so they'll be redundant in almost all cases. they're there for clarity

I guess it doesn't matter if it's kept, but wouldn't this only reinforce things like the Krfawy situatuon you complained about?

Okoratu wrote:

9. > title extendo version
idk i think you've been reading an outdated version of this draft, the only thing in guidelines is #### ver atm. the headings are smaller cuz they are subheadings

No, I'm definitely looking at the up to date version on github. Yes, only (#### Ver.) is under guidelines but (Extended Ver.) and (Long Ver.) are part of that guideline, which is why I said it's inconsistent with (Short Ver.) and (Game Ver.) which are under rules.
I know they're subheadings but bringing them to the header level above would make things more consistent, as I mentioned you did it that way in the Artist section.

Okoratu wrote:

11. > switch order for marker rules
the order reflects the order you check this stuff in and i think it reads worse if you swap it around

It actually shouldn't matter in which order you check the rules stuff since the result is the same so I don't see how it's worse but I guess this is just a small detail so nothing too important.

Okoratu wrote:

12. > sped up version dies now
i think thats fine and the people who care about the distinction can fight the RC on it if it is a problem
nightcore mix has similar usage as tv size which is why the marker is mix and not Ver. also Nightcore mix is the main choice outside of osu, not just in osu lol

I just feel like many people are not even aware this is changing, especially when the dedicated proposal for it was closed/archived. Sure, they could make a new proposal to revert the change but that seems like an unnecessary waste of time and maps that get ranked in the meantime would cause inconsistencies. I'm fine with Nightcore Mix, I just think it's important to make sure this should be used in almost all cases.

Okoratu wrote:

14. > mocha
OK but like writing it down as a rule is such a braintwister that just giving the example as an instruction works way better tho

Maybe, but it's still technically wrong to do it this way. I don't think it's that complicated to write out in a general sense, plus the example explains it anyway so it shouldn't do any harm.

Okoratu wrote:

15. > language not obvious
- added example

I figured this is what you meant, but I think the word "obvious" is not the right choice here because it implies the languages are not known or ambiguous, which isn't the case. If a song is half in English and half in Japanese I don't see why tagging both should not be done?

Okoratu wrote:

16. > soruce in source lang
i think that should remain up for preference as long as both are there it doesnt really matter

In that case it contradicts the very first point (about translations). This should be handled consistently, if the source is up for preference so should the romanised fields.

This proposal has been merged, subsequent edits should go through separate threads now!

wiki/en/Ranking_criteria/Metadata

✅

Okoratu wrote:

This proposal has been merged, subsequent edits should go through separate threads now!

wiki/en/Ranking_criteria/Metadata

✅

So you asked me to elaborate only to completely ignore my post?
Pushing RC changes like this without double and triple checking with several people is risky and will inevitably lead to misunderstandings, inconsistencies and pointless discussions.

there may be further edits to do on it that were already mentioned here or in discord or on the google doc, but no review was happening for months; hopefully pushing it was still an improvement over what was already there. not ideal situation obv but I think that was a fair call for now with general activity on this project being very low atm and most of its contributors having already approved of the draft

clayton wrote:

there may be further edits to do on it that were already mentioned here or in discord or on the google doc, but no review was happening for months; hopefully pushing it was still an improvement over what was already there. not ideal situation obv but I think that was a fair call for now with general activity on this project being very low atm and most of its contributors having already approved of the draft

So should I make a new thread for all those things (and possibly more) I listed above? I'm not sure if it makes sense if there's not going to be much activity there either.