Currently, the Ranking Criteria (RC) has the terms below that regulate audio file quality:

While the original intentions of explicitly enforcing audio quality were good, I noticed an increasing number of complaints doubting if the quality improvements are significant enough for the majority, especially in the context where the maps are in the Qualified section. After discussions with people who actively work on audio file quality, I noticed that a rewording of current RC terms may be necessary.

Since we share the general idea of "we should leave mappers to decide if minor issues in their Qualified maps are worth fixing", I think it'd be nice to relax the audio file quality requirement and let the mapper decide if they want to change the audio file if the quality improvement is minor.

In particular, I would like to reuse the wording that regulates background image and video quality:

So the updated RC terms for audio quality would become:

Opinions, comments, and wording fixes are welcome. (Update: there're already

agree, not really worth wasting time debate about audio quality when most ppl cant tell the difference

i think keeping the minimum guideline at 128kbps is still good because below that genuinely sounds awful (because most of the time it is an even lower quality source + shitty rip). and 192 should be the recommended standard regardless. i would not want to see people start defaulting to worse youtube rips then point to this guideline to defend using crappy audio.

+1

Nao Tomori wrote:

i think keeping the minimum guideline at 128kbps is still good because below that genuinely sounds awful (because most of the time it is an even lower quality source + shitty rip). and 192 should be the recommended standard regardless. i would not want to see people start defaulting to worse youtube rips then point to this guideline to defend using crappy audio.

+2

the sooner we get rid of these asinine restrictions the better

Putting the minimum bitrate rule to the guideline is a better option than going with arbitary way like background file does. I agree with 128 kbps as minimum on guideline.

Nao Tomori wrote:

i think keeping the minimum guideline at 128kbps is still good because below that genuinely sounds awful (because most of the time it is an even lower quality source + shitty rip). and 192 should be the recommended standard regardless. i would not want to see people start defaulting to worse youtube rips then point to this guideline to defend using crappy audio.

Ryu Sei wrote:

Putting the minimum bitrate rule to the guideline is a better option than going with arbitary way like background file does. I agree with 128 kbps as minimum on guideline.

yes that sounds better. i didn't write this because i believe the majority -- mostly the bns because most of the times we're dealing with qualified maps -- should be able to tell when there's a significant audio quality improvement (usually compared with a really bad audio file). but keeping these can definitely cut down on a lot of unnecessary debates

how does this change anything, guidelines are rules except in exceptional circumstances, and most of these cases just boil down to "it's already qualified and the current one sounds fine so i don't want to waste my time" which doesn't really count as an exceptional circumstance since which is literally true in almost 100% of these cases anyway at which point there's no point even writing that in the rules if everyone will ignore it because they don't want to dq - if something is up to mapper preference to that extent then it doesn't need to be in guidelines or rules

...but when visiting the topic of removing that part I believe Ephemeral said no and that mp3 bloat will always be a rule when we reworked the audio RC last year

Ephemeral wrote:

I presume people refer to a "bloated" mp3 as one that is transcoded to a higher bitrate from a lower quality source (for example, a 128kbps natural mp3 being transcoded up to 192kbps would be considered bloated).

Spectrograms are a common way of identifying some of the shelving and peaking artifacts that this causes in a track, but as outlined in other posts, it isn't an entirely perfect way of detecting them. To my knowledge, short of training an AI to identify this kind of thing, the only semi-reliable way of doing it is to have both the ears and the audio hardware available to tell.

Naturally, modders and mappers respond poorly to claims of perceptual differences without objective evidence to point to, which is part of why spectrograms and other forms of audio visualisation have become common place in these discussions. Worse still, I think a significant proportion of the modding/mapping community completely ignores the opportunity to even educate themselves to a basic threshold on how digital audio quality works for whatever reason, and instead resort to complaining about rules surrounding them or even to intimidate the modders who raise issues like this for consideration.

I'm not even really sure how we begin to address this. It is as trivial as it has ever been to find tracks of an acceptable quality to use in osu! - just find a YouTube video that isn't absolute dogwater in quality and use a utility like youtube-dl or yt-dlp to download it and transcode the track for you, and practically nobody will ever know. If they do, they'll do what these infamous modders often do and likely supply an improved audio file and offset change for you, which you then use Mapping Tools to apply with about a minute or two's work. What is even the issue here?

Ephemeral wrote:

1. A song's audio file must not be encoded to a bit rate more than or equal to 32kbps higher than the original files.

This is not fine. No degree of upward transcoding is permissible.

Oh, right. I forgot to see that. Definitely don't remove the bit of "upwards encoding" rule, bloated audio is NG.

AJT wrote:

how does this change anything, guidelines are rules except in exceptional circumstances, and there's really no reason to use a 192kbps file with lower actual bitrate than it would be if they had sourced the mp3 correctly, unless you consider "it's already qualified and the current one sounds fine" as an exceptional circumstance which is literally true in almost 100% of these cases anyway at which point there's no point even writing that in the rules if everyone will ignore it because they don't want to dq

it is mostly to ensure the audio quality requirement aligns with the mindset of "we should leave the mapper to decide if they want to fix the minor issues in their qualified maps", hence why i borrowed the wording in bg & video guideline. imo the question here is not "is there a reason to use a 192kbps file with a lower actual bitrate", but rather "is it worth changing the audio file in a qualified map if a new 192kbps file doesn't provide significant quality improvement". i think those guidelines (mine & nao's for now) can serve as a lower limit for audio quality, and with the cooperation of bng we can also ensure no one is purposefully fucked up & the idea of "not forcing minor upgrades in the qualified section" can be guaranteed, improving the qol of both mappers & bng.

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

Ephemeral wrote:

(it's too long... its here for the ease of access)

i remember this too, and rereading this i feel i failed to understand why eph insisted on having a no mp3 bloat rule.
so first he stated that "bloated" basically means over-encoded, for example 128kbps -> 192kbps, which i agree. but then he said

which, imo, implies that the bloated audio is only a serious problem that requires immediate action when the original audio file's quality is horrible. however, my proposal is addressing complaints regarding audio files that "sound similar", to which his argument doesn't seem to apply. this also makes his last statement a tad confusing to me -- when the 32 kbps difference is between 160 & 192 kbps, then the audio files should sound similar to the majority, yet eph said it's not fine at the end. the only reason behind such a statement i can imagine is he believes that fixing mp3 quality doesn't take long, as he said:

but here comes the conflict: it is against the aforementioned common ground among bns of "not forcing minor upgrades in the qualified section", and "we should leave the mapper to decide if they want to fix the minor issues in their qualified maps", for both of which i am fairly familiar for years. reiterating -- i think whether an issue should be fixed no matter what or not in a qualified map should be left to the bng/nat to decide collectively, instead of how short these changes can be made; and i think relaxing audio file quality requirements to a direction that minor quality upgrades aren't enforced represents such a community-driven spirit better.

If the reason is that, then the guideline should say something as using highest quality as possible within rules. 128 kbps in MP3 is within bearable amount, with cutoffs on high frequency sounds, but put it on lower priority than using highest quality as possible. Justification to break that is if the audio file is apparently too big to upload it's impossible to upload the full length of the map without downsampling it, or if storyboards restricting the upload size.

There are no reasons to not use better audio other than these. It will also help in deduplication when lazer comes if we unanimously use same audio file for same song length!

The only reason why an audio should be below 128 kbps, is because the best audio possible is literally that bad, and if the original is something like 96 kbps, then encoding up would go pretty much against the idea of file size optimization.

Songs whose original sources are gone, and only low quality reuploads exist are a potential example of this.

honestly i think the main problem here is that most people who are looking into these spectrograms don't understand how to read them properly; almost every argument i see is that "because peak frequency averages around 16khz this means that the audio is over-encoded."

this is not always the case. certain encoders and encoder settings may prioritize preserving audio quality by capping frequency peaks. this doesn't mean that the audio files are bloated.

i think using spectrograms can be a helpful tool to help identify bloated audio, but it doesn't help anyone if people interpret the wrong data from them.

including a clause in the ranking criteria to not include bloated audio does not help if people do not know how to correctly identify when an audio file is bloated. if we can't remove/change the rule as originally proposed, then i think a rewording or an explanation on how to identify audio bloat is necessary in order to minimize confusion and frustration regarding this topic.

As far as I know, the proposal for this ranking criteria change has already been discussed internally. I believe that allowing a leeway of about 20kbps makes sense. This relates to the nature of the LAME audio encoder.

Regarding the differences in various reformatting formats: Variable Bit Rate (VBR) encoding adjusts the bit rate dynamically according to the complexity of the audio being encoded. This means that while targeting a specific average bitrate (like 192kbps), the actual bitrate can fluctuate based on the content, resulting in variations in audio quality compared to constant bit rate (CBR) encoding at the same nominal bitrate.

Normally, the VBR bitrate ranges between 170 and 210. After conducting some tests, there were MP3 files that slightly exceeded the value of 210. In such cases, having a leeway would generally be a better option than a clearly defined limit. This would allow for fluctuations in VBR. However, I disagree with a leeway of 32 kbps, as it raises the value to 224, which is the next higher value in CBR. This contradicts our intention to avoid increasing in bitrate.

AJT wrote:

how does this change anything, guidelines are rules except in exceptional circumstances, and most of these cases just boil down to "it's already qualified and the current one sounds fine so i don't want to waste my time" which doesn't really count as an exceptional circumstance

ye

Ryuusei Aika wrote:

Since we share the general idea of "we should leave mappers to decide if minor issues in their Qualified maps are worth fixing"

strongly disagree with this mentality... maps stay unchanged forever once they enter Ranked, letting even minor issues slip on purpose is unnecessary

Doormat wrote:

...
including a clause in the ranking criteria to not include bloated audio does not help if people do not know how to correctly identify when an audio file is bloated. if we can't remove/change the rule as originally proposed, then i think a rewording or an explanation on how to identify audio bloat is necessary in order to minimize confusion and frustration regarding this topic.

i don't think it's a good idea because it may make a long speech in the RC which is pretty unneeded i believe. if the ban on bloated audio is for the sake of saving storage then i think we can just word it as what we did for bg & video quality, a.k.a. "avoid unnecessary over encoding" bla bla bla.

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

clayton wrote:

Ryuusei Aika wrote:

Since we share the general idea of "we should leave mappers to decide if minor issues in their Qualified maps are worth fixing"

strongly disagree with this mentality... maps stay unchanged forever once they enter Ranked, letting even minor issues slip on purpose is unnecessary

i don't interpret this mentality as we're letting all the minor issues slip on purpose; instead we leave the judgment to the mappers themselves, because it is their maps, not ours, and imo it's not a good idea to enforce our ideals on them. that being said, if the regulations on bloated audio from the dev team is due to some practical reasons (like saving storage) instead of some ideals, then i believe we can still include the related terms in the guideline section just as what we did for bg/video quality.
this is also why i said in #9 that we should let the bng/nat to decide collectively if any minor issue absolutely needs fixing because they should be able to tell not only "where are the minor issues" but also "are these minor issues actually a hassle for the majority that may warrant a dq".

Ryuusei Aika wrote:

clayton wrote:

Ryuusei Aika wrote:

Since we share the general idea of "we should leave mappers to decide if minor issues in their Qualified maps are worth fixing"

strongly disagree with this mentality... maps stay unchanged forever once they enter Ranked, letting even minor issues slip on purpose is unnecessary

i don't interpret this mentality as we're letting all the minor issues slip on purpose; instead we leave the judgment to the mappers themselves, because it is their maps, not ours, and imo it's not a good idea to enforce our ideals on them. that being said, if the regulations on bloated audio from the dev team is due to some practical reasons (like saving storage) instead of some ideals, then i believe we can still include the related terms in the guideline section just as what we did for bg/video quality.
this is also why i said in #9 that we should let the bng/nat to decide collectively if any minor issue absolutely needs fixing because they should be able to tell not only "where are the minor issues" but also "are these minor issues actually a hassle for the majority that may warrant a dq".

I don't understand why the standards for a map should get more lax when it is qualified. intuitively I would have assumed the opposite. "minor issues" shouldn't have to prove that it is "worth the hassle" to fix when you would normally not need to prove this before qualified. this thinking really undermines the purpose of qualified to me, which is to get some final increased exposure on the map before it hits ranked, specifically because minor issues like this may have gone unnoticed in modding

I guess this is getting kind of off-topic but if downgrading this set of rules into a similar guideline is motivated primarily because DQing for minor issues is seen as unnecessary, then I disagree even more, on top of what AJT said

Obtaining high-quality audio is the conflict of interest on its own, so I think leaving that average quality audio of the map as-is should be fine. However, if someone offered an audio file with objectively better quality, the mapper should accept it or justify why they shouldn't. Simply aligning the offset is not a huge problem if that results in better audio.

For me, 128 kbps MP3 still introduces artifacts where I start getting uncomfortable to listen and play. This might be different based on individuals and their PC configuration, so when the mapper is in doubt, they should ask other people first before considering to turn down the offer of better audio file.

agree that there should be some margin of error on the upper limit of bitrate

talked to aika:

- current thing is technically already allowed as otehrs have said
- we should think about making wording there clearer
- we are considering just writing a guide on encoding audio instead and linking that as supplementary material instead of putting all the explanation into the ranking criteria article itself