forum

[Proposal] Re-Organizing the Audio Section of the General Criteria

posted
Total Posts
8
Topic Starter
Noffy
After reviewing the current RC, I felt that the current audio section has a lot of different elements blended together. It switches between hitsounding, song compilation rules, and technical file things a few times. It made some topics more difficult to find or reference. I was thinking it could be organized differently.

>>> Click here for my Proposal Document <<<


If you like commenting on the document directly here is a copy for that.

Do I want proofreading: Yes | Do I want to compress it more if possible: Yes, ideas are welcome.


Also worth discussing that isn't fixed yet in the proposal document: Didn't have any support, so will not be pushing the suggestion in the box below. Focus on just the documents for now, thank you c:

removed suggestion
Currently it says:
"beatmaps must be hitsounded ... mania is exempt."

Uhhh taiko doesn't need hitsound additions in the same way as catch and standard do either, so that type of exception is a bit misleading. Like yes taiko is technically using hitsounds under the hood but they're not "adding" to the sound of the map that way, it's literally what key you have to hit.

I was thinking it could change to be
osu! and osu!catch beatmaps must incorporate hitsounding. Hitnormals give feedback to the player, and additions (whistles, claps, and finishes) accent the most important parts of the music.

This could possibly be seperated into the mode-specific RCs for osu! and osu!catch, with some rewording to reflect that. "Hitsounds must be audible" is already a separate rule, so the base level of feedback is still covered for all modes even with this change.

_______________________________________________________

There is no specific timeline on this yet, but if you have any interest any feedback on current audio rc or ideas is welcome.
Bloxi
If a song can not be found in high quality, use the highest quality available without *up-encoding.*

I prefer the old wording about encoding from a lower bitrate since it makes it more obvious what that actually means without prior knowledge?

The reference table is nice but it would be even better if it included pictures of examples of a "good" mp3 and a "bad" mp3 and mention spek bitrates etc.

Beatmaps of songs which are artificially extended must apply spread rules and guidelines based off of the song’s original length, instead of the extended length.

Will potentially run into issues in the future with "Slowed Ver." songs getting more popular with TikTok I'm telling you. The future generation of mappers will dislike this :P

Some two-song combinations are also exempt, as long as the tracks are closely related.

What does this mean?? Examples pls??

Hitsounds must be audible. Hitsounds with low volume or samples that blend with a song's samples are unacceptable. Specific game modes list exceptions to this rule on their respective ranking criteria.

I prefer the old wording with "the purpose is to provide feedback" here, going back to the "Beatmaps must be hitsounded" rule now makes it sound like additions are necessary now for a map to be properly "hitsounded".

As someone who loves doing older style hitsounds without any additions, the normal-hitnormal gives plenty of feedback already and this almost invalidates that interpretation?
Decku
I do genuinely agree that the ranking criteria here does need to be updated a little to be modernized with the changes and overall uniqueness. But in saying that, shouldn't hitsounds be it's own thing then in the general RC like the same as Audio, although it being a type of Audio, it in itself is a big aspect of Ranking Criteria and can either have it's own section, or as suggested its own sub-section in the wiki.

I genuinely feel like the table is useless in this case as well Blaxi. If we REALLY wanted to generally summarize how audio works and examples, an entirely new osu!wiki page should be created in order to accommodate this rather than trying to add more into the General RC. A completely new document explaining the differences between the audio bitrates or better yet, img links to examples would be great to help the overall viewer gain some insight on the spot rather than just clicking on an entirely new link.

Noffy wrote:

osu! and osu!catch beatmaps must incorporate hitsounding. Hitnormals give feedback to the player, and additions (whistles, claps, and finishes) accent the most important parts of the music.
About this it would sound a lot more weirder if it was just those two modes. I understand that Taiko is just feedback hitsounds that basically is the map, but in the end of the day it's still hitsounds and shouldn't be lenient based on the relativity of the music. Mania is different for the reasons we all know and should be kept that way.
The hitsounding section can always be applied to osu!taiko's ranking criteria if it hasn't already been placed in it.

I did ask Irone OSU about it and this is what they stated:


I do believe everything else seems okay. But in general messing around with the arrangement of the General RC can always come in with some problems.
Okoayu
welcome Blaxi, Bloxi's evil twin

- change do not beatmap to `do not map`
- ensures instant feedback ... should be positioned to apply to both previous points

Deleted combinations of 2 songs should be clearly related as all the exceptions with regards to draintime rules are already handled with marathons & compilations
Topic Starter
Noffy
Went through this a little bit with Okoayu as well while looking at the feedback so far, updated the documents.


A comment on the google doc brought up:

Regarding audible distortions in audio ->
"What if intended distortions and such (or even intended loudness) breaks the content guidelines for being "excessively loud / obnoxious"?"

If it breaks the guidelines, that's up to moderators to comment on. However Oko took some time to reword this guideline for better clarity now.

Updated other things based off the feedback, and won't go through changing the otcm hitsounding mode-specific rule brought up in my forum post.


About adding more to the reference table ->
I can remove it or make any other changes, but I don't think I can add spek or khz guidelines to this. The reason why is I tried before and I was very strongly told no. See community/forums/topics/923648?n=22 .
Topic Starter
Noffy
- Decided to remove reference table, may be better for a guide somewhere else.

- Added a new requirement based on community/forums/topics/1768985?n=1
- Added a new requirement for sampling rate, as higher values will cause lazer to shit bricks.
Leviathan

Noffy wrote:

About adding more to the reference table -&gt;
I can remove it or make any other changes, but I don't think I can add spek or khz guidelines to this. The reason why is I tried before and I was very strongly told no. See community/forums/topics/923648?n=22 .
then why is there a rule against encoding upwards when theres no information on what that is and how to tell? no average person is going to tell just by listening unless its obviously incredibly low (in fact 99% of bloated audio files are because of bad youtube rips and people not being able to tell because they sound fine to them) and i dont think having to rely on people who know more is a good thing -.-
Topic Starter
Noffy

Leviathan wrote:

Noffy wrote:

About adding more to the reference table -&gt;
I can remove it or make any other changes, but I don't think I can add spek or khz guidelines to this. The reason why is I tried before and I was very strongly told no. See community/forums/topics/923648?n=22 .
then why is there a rule against encoding upwards when theres no information on what that is and how to tell? no average person is going to tell just by listening unless its obviously incredibly low (in fact 99% of bloated audio files are because of bad youtube rips and people not being able to tell because they sound fine to them) and i dont think having to rely on people who know more is a good thing -.-
Well
1. Don't encode upwards: Same ideals of saving on filesize as many other optimization related rules

2. Not adding that guidance: Better suited for guides than RC. RC gets taken as law, so even things written to be helpful can be misunderstood as very strict if it's included. Hence why my original table was only summarizing rules, not adding information. Guides like community/forums/topics/1731264?n=1 or https://railgun.site/guides/audio/ exist in a simple search too.

3. Many common visuals for spektro is based of LAME encoded mp3s. While that's the most common method, mp3s encoded with other methods may lead to entirely different spectograms, so ears are the best check.

Not that I am keen on the current mixture, but I also don't want to literally do the exact things I've already been told not to do before when other resources exist too.
Please sign in to reply.

New reply