I think it's time we say goodbye to this way of modding, because it's become a big hassle for both mappers and BNs to filter out "bad quality" audio when it doesn't change anything significantly to fix it. Whilst in some cases bloated files may cause significant file size increase, in most occurrences the difference is hardly notable and in fact fixing/upgrading it can cause an increase in itself without an audible benefit.

I propose a rewording to something like this:

The audio file of a beatmap must...
...use the .mp3 or .ogg file format.
...have an average bit rate no greater than 192 kbps.
...have an average bit rate no lower than 128 kbps, if such a source exists. Otherwise, use the highest quality available.
...not have a significantly artificially increased file size.

(Please give suggestions for better wording because I can't think of much)

The problem is actually most mappers (including myself) have no idea what does count as 'bloated', nor technically know the actual bitrate of the audio files. I used the default export format in my audio editor (OGG quality 5), so we need to enforce the rule when such dispute exist.

When source with optimum bitrate and quality (non-bloated audio) exist, the modders must explain in verbose, and with technical proof on why the said audio is bloated.

Maybe something like this can do:

Allowances
Audio files that are upsampled (e.g 128 kbps resampled to 192 kbps) may be used, as long as there are no audio files with proper bit rate exist.

128 bloated to 192 is almost the biggest possible difference for most cases given that 128 is the lowest you’re meant to use if possible. Thus, it seems like “significantly” is just a thinly veiled attempt to cover almost all likely cases (although ik sometimes he posts about 160-128 and “”96””). It’s simply too vague.

As a side note, Eph seemed to disapprove of this already when I attempted to set a 32kbps limit community/forums/posts/8561142 but on further inspection it seems like we weren’t on the same page and he was thinking of someone downloading a 128 mp3 then re-exporting it at 192, when it’s more like someone downloading the mp3 listed at 192 when it’s actually the quality of 128, the fixing of which is ideally done by providing a better mp3 rather than reencoding it, as lossy-lossy encoding isn’t good. So I’m not quite sure what he’d think of this proposal.

I don’t really care about what happens with this rule but personally I think it’s just not that hard to check the mp3 and avoid these scenarios in the first place lol (although I concede that it’s weird filesize is policed so hard here but not with images or any other audio files that aren’t the song file).

It isn't as much about BNs not checking (which happens but can't do much but ask them to be more attentive) but rather just avoiding re-encoding which feels unnecessary for the majority of cases. When I say significant theoretically for long songs (thinking marathons) it could be a significant increase but I do agree it's weird it isn't policed for any other file in the mapset folder.

AJT wrote:

...I concede that it’s weird filesize is policed so hard here but not with images or any other audio files that aren’t the song file).

using spectrograms to determine audio quality has always been the biggest mistake the mapping/modding community has done in the last year-or-so, because people don't understand that there are different types of encoders used to try and preserve lossless -> lossy audio quality.

people don't even know what to properly look for when posting spectrograms to try to prove their point; they think that just because an mp3 caps at around 16 kHz on the graph, the mp3 must be bloated. this isn't always necessarily the case, and jonathanlfj's post here does a good job at debunking this myth, as well as this other link that explains why an mp3 encoder may omit high-band frequencies: beatmapsets/1533258/discussion/-/generalAll#/3072474/8313589
https://wiki.hydrogenaud.io/index.php?title=High-frequency_content_in_MP3s#Why_MP3s_omit_high-frequency_content

i agree that we should watch out for bloated mp3 files where applicable, but given that almost everybody has no idea what they're talking about, i think it'd be perfectly fine if this rule just died.

Honestly yeah could just do away with this rule.

Doormat wrote:

using spectrograms to determine audio quality has always been the biggest mistake the mapping/modding community has done in the last year-or-so, because people don't understand that there are different types of encoders used to try and preserve lossless -> lossy audio quality.

I mean there's only really one or two people that actually regularly post about audio lol

aceticke wrote:

in most occurrences the difference is hardly notable and in fact fixing/upgrading it can cause an increase in itself without an audible benefit.

I'm (reverse) biased as my audio sucks but I also agree with this: the filesize saved by using a 192kbps mp3 instead of one that says it's 192 but is 128-ish is often negative or none, and for most songs 128kbps is not a bad quality on osu (for me) and I mostly can't tell the difference. Given that we were able to change the rule to make >128kbps optional, it would have seemed logical to also alter the bloating rule, however I'm not really sure how to go about it. Also I will note that even if the rule is changed it's unlikely to stop people (person) posting these mp3 improvement posts anyways, and it'd probably be nice if more people practiced the method of choosing between applying the post or replying once and then ignoring the post after that so that every thread doesn't turn into annoying audio arguments that benefit no-one

Doormat wrote:

i agree that we should watch out for bloated mp3 files where applicable, but given that almost everybody has no idea what they're talking about, i think it'd be perfectly fine if this rule just died.

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. If an original file is 96kbps and it is all that is available, the 96kbps file must be used on its own, as-is, and as per the clause written in the first quoted block. Running a track through encoder grit twice is an objectively worse experience for users.

As I mentioned, I think he said this because he thought I was talking about people manually increasing bitrate instead of just downloading a slightly dodgy (but realistically inconsequential) mp3, so you'll have to see what he thinks about this

The current aceticke phrasing isn't very clear either, so if the rule is altered, the best thing would just be to remove the sentence entirely (e.g. there's no "Image files must not be bloated" type sentence). There might be a way to reword it clearly but I can't think of one atm

Additionally, re-encoding harms the effort of the mappers because if the 'audio fix' mod comes way later, there is always a chance that the modders must re-adjust offset of every single timing points, start and end position of every single notes, and such. This raises another problem of painfully checking every single notes and timing points whether it's snapped or not.

It's always an issue for maps containing a lot of SV changes, BPM change/resets, and SBs.

I can't really think about permitting such 'bloated' audio, or disallowing it. What if the original source of the audio itself already upsampled?

Ryu Sei wrote:

Additionally, re-encoding harms the effort of the mappers because if the 'audio fix' mod comes way later, there is always a chance that the modders must re-adjust offset of every single timing points, start and end position of every single notes, and such. This raises another problem of painfully checking every single notes and timing points whether it's snapped or not.

It's always an issue for maps containing a lot of SV changes, BPM change/resets, and SBs.

Off-topic: Mapping Tools makes this a non-issue.

Project Railgun wrote:

Ryu Sei wrote:

Additionally, re-encoding harms the effort of the mappers because if the 'audio fix' mod comes way later, there is always a chance that the modders must re-adjust offset of every single timing points, start and end position of every single notes, and such. This raises another problem of painfully checking every single notes and timing points whether it's snapped or not.

It's always an issue for maps containing a lot of SV changes, BPM change/resets, and SBs.

Off-topic: Mapping Tools makes this a non-issue.

Agree this isn't really a relevant issue.

Huh, how long am I being outdated then.

If anything, the clause should be changed to...
If that is the case, then this point should be moved to guidelines instead of rules, since the rules enforce, not aid.

Ryu Sei wrote:

Huh, how long am I being outdated then.

If anything, the clause should be changed to...

...should not be encoded upwards from a lower bitrate.

If that is the case, then this point should be moved to guidelines instead of rules, since the rules enforce, not aid.

This really wouldn't solve the issue of people pointing out things which they aren't qualified to be talking about, would just stop the insta DQs but the discussion war rages on.

AJT wrote:

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. If an original file is 96kbps and it is all that is available, the 96kbps file must be used on its own, as-is, and as per the clause written in the first quoted block. Running a track through encoder grit twice is an objectively worse experience for users.

As I mentioned, I think he said this because he thought I was talking about people manually increasing bitrate instead of just downloading a slightly dodgy (but realistically inconsequential) mp3, so you'll have to see what he thinks about this

if this is going to be enforced with a hardline, then there needs to be a better way to educate people on how to determine if an mp3 is bloated. unless we can definitively determine a method to identify bloated mp3s without relying on people's interpretations of a .png file that they probably don't know how to interpret correctly, then i don't see the merit in keeping this enforced.

Slightly disagree at the proposal.

Mainly because me, personally don't feel it's that hard to tell if a audio is bloated or not. It takes like 10 minutes at most to get used into how to deal with it.
(Mania side NAT had once pinged, and told us about bloated audio earlier.
And for the rest of the year, about 6-7 months. I can't memorize one single audio dq case from mania. (I am a BN who always put an eye on #reportfeed

If both BNs and the mapper had really looked into the audio, it won't be pushed into qualified section at all. Sus audio would at least lead to a discussion.

Since audio is a hard rule now, most BNs would at least look into those. As a result, the newer ranked maps have obvious better audio quality than previous years,
At least my ears usually can tell the difference from bloated ones and normal ones. (because bloated mp3 are mostly from 3rd party / media. Some of those ppl / webs might encode the music badly. (not only lead to bloat issue.)

If there's no such rules, I can expect a decrease in audio quality in the future. (because BNs no longer care about those) Which would decrease the players' play experience.

To conclude, I see bigger cons compare to pros allowing this. So disagree.

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?

I'm highly in favor of this proposal