forum

[invalid] [Metadata] Standardisation for official short/game/extended versions

posted
Total Posts
12
Topic Starter
Okoratu
Songs with naturally occuring long versions are rare and use whatever modifier they originate with. Moreover if there's more than one version, be it long or short or game, standardizing them makes little sense as you lose information as to which version you're actually on about

So I propose the following:
If a song title contains short, game, extended or long version markers, the markers must be standardised to (Short Ver.), (Game Ver.), (Extended Ver.) and (Long Ver.) respectively. If more than one short / game / long version exists, the original markers should be used to differentiate the specific version for each song. If a potentially conflicting version already has standardised Ranked beatmap set, that version's standardisation should be followed.

this should provide more context to the extended ver standardization for unofficial edits mentioned in the other thread

Discuss?
Ryu Sei
If this were approved, how do we deal with this and similar cases?



Both has extended (long version) markers, yet both are different in extension structure.
Topic Starter
Okoratu
should probably move this to its own rule then to clarify that this only works if there's one longer version for a song then?

I don't see how we could keep it the way i originally proposed while making sure that the standardization uniquely identifies a song
Ryu Sei
I thought the same thing. Though, we can put it under one or few umbrella rules if said original song has multiple short, game, or long version, so it falls back to the original marker given. But that's probably out of this topic and requires new proposal to keep it in line.

Longer version of a song is somewhat common in rhythm game songs. Standardising the marker is a good idea, either way.

That being said... there are always edge cases where official long/extended doesn't adhere with regular "Song title (Long Ver.)" format.
SaltyLucario
from what i saw over the years, (long ver.) and (extended ver.) / (extended mix) are equally common markers when it comes to official extensions of the song, so if i understand correctly this change would standarize all official edits that use (extended ver.) to (long ver.)? don't really agree with that

and as ryu sei mentioned, edgy long ver. markers exist as well. standarizing them to just (long ver.) would suck but writing exception would just be mess, and idk if it's worth considering they're not that common

so yeah, i don't really think rc would benefit from this change
Serizawa Haruki

SaltyLucario wrote:

from what i saw over the years, (long ver.) and (extended ver.) / (extended mix) are equally common markers when it comes to official extensions of the song, so if i understand correctly this change would standarize all official edits that use (extended ver.) to (long ver.)? don't really agree with that
To address this issue I think it would be possible to use both (Long Ver.) and (Extended Ver.) depending on what the official song title says, similar to (Short Ver.) and (Game Ver.) which are both used. This would still distinguish official extensions from unofficial ones if the other proposal is implemented because the intention is to use (Extended Edit) for unofficial extensions (which are very rare anyway).
Topic Starter
Okoratu

SaltyLucario wrote:

words to the effect of allow both (Extended Ver.) and (Long Ver.)

Serizawa Haruki wrote:

words to the effect of agree while pointing out we can just do the same as (Short Ver.) and (Game Ver.) are doing
OK sure why not, worked that in

updated wording to clarify what I think should happen in case of conflicts (affects both the existing Short Ver and Game Ver markers and the new thing)

Changed thread title as it's pretty early in the discussion anyways
Ryu Sei
If a potentially conflicting version already has standardised Ranked beatmap set, that version's standardisation should be followed.
This should fall under guidelines rather than rule. Also, instead of "should" on multiple version conflicts, use "must" since rules must apply.
Serizawa Haruki
Regarding the "Exclude multiple versions of same length group from standardisation" part:

If more than one short / game / long version exists, the original markers should be used to differentiate the specific version for each song. If a potentially conflicting version already has standardised Ranked beatmap set, that version's standardisation should be followed.
Although it's very rare/unlikely, I think this approach isn't ideal because it could lead to inconsistencies in some edge cases:
  1. The mapper/modders/BNs might not always be aware that more than one version exists, especially for obscure songs/versions
  2. A new, different version might be released at a later point in time, altering the previous version's correct metadata
It's also kind of weird to standardize some "special" markers (if only one version exists) but not others (if more than one version exists).

Therefore I suggest a slightly different approach, I don't have a proper phrasing in mind right now but the basic idea is this: If markers contain additional information and/or specific designations, these should not be removed when applying standardization, regardless of how many versions exist (which would theoretically make things easier). However, these markers should not be completely exempt from standardization. The formatting would still be standardized, but the extra information/desgination would be retained. This way each version can be distinguished while still following RC formatting conventions.

Some examples:
  1. fallen shepherd feat. RabbiTon Strings - ENDYMION (long edit) -> ENDYMION (Long Ver.)
  2. Tatsh - reunion <Platinum Long Version> -> reunion (Platinum Long Ver.)
  3. BlackY - AlphaOmega (Evolutionary Extended ver.) -> AlphaOmega (Evolutionary Extended Ver.)
  4. Camellia - #1f1e33 (#00102g version) -> #1f1e33 (#00102g Ver.)
  5. Camellia - #1f1e33 (Another long ""#ant1p01e"" Version) -> #1f1e33 (Another Long ""#ant1p01e"" Ver.)
  6. Rita - Little Busters! ~TV animation ver.~ -> Little Busters! (TV animation Ver.)
  7. Rita - Little Busters! -Ecstasy Ver.- -> Little Busters! (Ecstasy Ver.)
  8. THEATRE BROOK - Uragiri no Yuuyake -TV Size Long Ver.- -> Uragiri no Yuuyake (TV Size Long Ver.)
Topic Starter
Okoratu
@Ryu Sei, I'm aware but we can always split that up later once we settled on something - I prefer keeping it together for now for the sake of clarity

Serizawa Haruki raises some interesting points, but I'm not sure if that makes it easier or harder for the average joe to understand what to do

Also your TV Size examples would probably just use TV Size, no; even the (TV Size Long Ver), not the (TV animation Ver)...

I like the idea of using the descriptors if possible, but i'd suggest dropping filler words like "Another" (Long ""#ant1p01e"" Ver.)

I disagree with not showing it's a longer version of a shorter song in stuff like (Ecstasy Ver.), that kinda feels like it's missing the point

I generally do like the direction, though I'll work an alternate wording into the OP whenever i come up with it so we can compare both "solutions" to this and decide which one is better
Jonarwhal
+1

for the same reason that users prefer to see (Cut Ver.) on shortened songs so they know it's shorter, these game versions are the one exception where players do not see that this is a shorter version of the song rather than the full version
Topic Starter
Okoratu
I have since abandoned this idea after extensive discussion with the other metadata people. It mostly boiled down to
-> we cant know waht the artist is gonna do in the future
-> their version naming should take precedence over some standard and should make it clear enough what sort of version it is
-> artists sometimes make different versions of the same song (like longer versions) which would inevitably force clashing names and just a very clunky way to actually mark the song

(i.e. camellia's first long version is just Extended Ver or whatver and then the next version gets the correct, specific label and that's m.....eh)
Please sign in to reply.

New reply