Why:
It doesn't do anything. Maps with garbage audio get qualified and ranked on a regular basis. Setting a minimum of 128kbps does actually nothing to enforce any bare minimum of audio quality, because any lower quality audio file such as 96kbps or even 64kbps mp3s can easily be re-saved in a 128kbps or 192kbps mp3 container. Doing so does not actually improve the audio quality whatsoever. All the minimum does is encourage saving files in a bit rate that is not needed for the quality level present.

This just wastes filesize and encourages practices of passing off garbage mp3s as higher quality than they really are.



In addition, I could have sworn there was an old thread on this but can't seem to find it, but other guidelines should be put in place to regulate audio quality minimums, such as by observing the kHz cut off points or whether present clipping is causing distortion in the song. For reference, this guide for checking audio quality exists: https://osu.ppy.sh/community/forums/topics/320007


I'm making this thread because I've noticed over actually checking in the past several months that numerous maps will use audio files that are equivalent to 96kbps mp3s, but are saved at 192. It's... kind of meh to see how prevalent it is.

The issue with basing it on something like kHz cut offs is that while there is a very strong relationship between certain mp3 audio qualities and cut off rates, this is not 100% true for all songs (see https://thesession.org/discussions/19642 for reference)
However it is true enough I think a guideline at the very least could be written on it.

guidey guideline wrote:

Audio files should not cut off at less than 16kHz. Any lower indicates the audio file may be of low quality, and it is strongly encouraged to use a better mp3 unless none can be found.

changed rule wrote:

A beatmapset's audio file must be no higher than 192kbps. Variable bit rate songs must average beneath this amount.

tl;dr the current minimum is useless. let's try to fix it???

yep this makes sense, the issue is that a lot of songs do not have good quality audio releases so the floor might be limiting. however as a guideline it's ok since the exception would be when no better mp3 can be found

lower bitrate files that have been transcoded to meet the 128kbps requirement are a direct attempt to circumvent the rules and i am almost certain people have been slapped for them in the past

if this is happening and is even becoming a regular thing, you need to report any instances of it you find to the NAT so that the BN responsible can be spoken to

can you cite some recent examples of maps with poor quality audio (aka <128kbps transcoded) for context's sake? i'd like to think most people can pick out these sort of things with their ears alone for the most part

A rule that's a bit strict in that case cause some songs literally don't exist in good quality, like https://osu.ppy.sh/beatmapsets/4422#osu/379106
a rule with exceptions is a guideline and should be written in the rc as such. Not allowing exceptions would be making some songs unrankable, and that would suck.

in addition 128kbps itself doesn't really give an indication of what to actually look for to try to determine quality

random examples from qualified and recently ranked maps, just from clicking through randomly and checking stuff. I'll probably report qualified ones later if I can get better audio (edit: rip, one of them ranked when i was trying to do that >_<)

I'd like to also mention most extreme examples I know of I helped to fix and provide better audio for (i.e. this or this or this ) so they now are better, but that doesn't fix the problem that the rule doesn't make crystal clear what the actual issue is or how to even check for it.

https://osu.ppy.sh/beatmapsets/945190#osu/1978280 equivalent to ~112
https://osu.ppy.sh/beatmapsets/868721#taiko/1815749 less than 96 (even ranked standard map has a better quality audio)
https://osu.ppy.sh/beatmapsets/979703#osu/2050364 96
https://osu.ppy.sh/beatmapsets/720588#osu/1521408 like 96 but with the added wonder of regular clipping
https://osu.ppy.sh/beatmapsets/961717#osu/2045276 112
https://osu.ppy.sh/beatmapsets/875024#mania/1885340 112
https://osu.ppy.sh/beatmapsets/958150#osu/2006177 112

about half of those found only fall "slightly" below the threshold but do nonetheless :<

On a side note, it's not technically unrankable but the same issue occurs that transcoding 128 to 192 audio is INCREDIBLY common. A good number of maps fall into this category >_>

i support this, no song should be unrankable due to mp3 issues and this fixes that while not endorsing lowerquality mp3s across the board

uhh 128kbps is a lot easier for the layperson to quantify vs a track with a 16khz shelf. attempting to enforce the latter via a guideline which people will likely ignore, especially if they're already ignoring established precedent by transcoding fringe tracks is clearly not going to do anything.

i picked one random example from your list and it ended up being Testo's billie eilish map, ran them both through spek to check to make sure your appraisals were correct:

supplied mp3 (from the set):


i'm a little skeptical immediately because 128kbps mp3s shelf hard at 15khz. this one is either from the world's noisest encoder one that is inefficient and dropping a lot of frames, possibly an online converter with bad presets?

if i had to guess off this alone, it's from a VBR source. given that it was likely ripped from a youtube video which tends to use AAC and often favors VBR, this makes sense.

supplied mp3 transcoded down to 128kbps:


starting to confirm my suspicions here a little bit.

libmp3lame transcode to 192kbps from lossless flac source:



libmp3lame transcode to 128kbps from lossless flac source:



ffmpeg experimental aac transcode to 96kbps cbr:



ffmpeg experimental aac transcode to vbr q:a target 2 (260kbps~):



from all of this, i can't really agree with your assertion that it's 96. it's clearly not 192kbps and is a transcode and this is bad, though probably not malicious bad but more people not understanding how bitrate works or using services which don't output properly and then not knowing or not bothering to check afterwards.

it looks like a 128->192 transcode, not a 96->192. 96 tends to be audibly poorer to people even with bad hardware.

this seems more like inadequacies in general BN knowledge/care and something better addressed by probation and education versus removing a perfectly serviceable rule and replacing it with a guideline that people are just going to ignore anyway.

Find this a good idea as well, if bitrate is unreliable due to not representing actual audio quality then this is likely the better metric. Shouldn't the upper limit follow suit though? So that minimum and maximum quality can be checked together rather than having to look for 2 different values that try to describe the same thing.

Ephemeral wrote:

I'd like to think most people can pick out these sort of things with their ears alone for the most part

Nope. I have no idea of what to listen for when it comes to judging audio quality, so numbers are 200% more reliable for me. Also something something human error.
I also don't know what you think guidelines are but they are not to be ignored; they function like rules with few exceptions in terms of enforcement.

we can probably just rephrase this to have a rule that states that 'reasonable quality' music should be used, and provide 128kbps as a guideline minimum and 192kbps as a guideline maximum

yaspo wrote:

Find this a good idea as well, if bitrate is unreliable due to not representing actual audio quality then this is likely the better metric. Shouldn't the upper limit follow suit though? So that minimum and maximum quality can be checked together rather than having to look for 2 different values that try to describe the same thing.

The upper limit is for file size reasons, not for audio quality. Otherwise, 320 kbps would be accepted.

@ephemeral the way all of our newer guidelines have been implemented is that they are basically rules except for the express exemptions we provide. so breaking up the thing into "reasonable quality" rule with "nothing worse than x" as a guideline would be unnecessary, it can just be "reasonable quality, such as nothing worse than x" as a guideline and it'd function the same but be easier to read/understand/navigate/etc.

320kbps/lossless wont ever be accepted outside of FA tracks because we're not a lossless audio distribution service and barely anyone has the kit or ears to tell past 192kbps in most cases

VBR should be avoided, CBR is preferable in all instances due to the way osu!'s audio engine library works I believe

does that mean we can use 320 for fa? cuz there has been a lot of back and forth on this point lol.

The minimum being 128kbps can be removed, but having the 192kbps as the maximum should probably stay since there are a number of users on older machines that may lag with mp3s that have a higher bitrate. Also you can easily just re-render the audio to be 192kbps in like 15 seconds.

manmathew wrote:

there are a number of users on older machines that may lag with mp3s that have a higher bitrate.

If the machine is too old, the person is prob using fallback, at which point the client can't submit scores for maps ranked after Fall 2018 anyway.

abraker wrote:

If the machine is too old, the person is prob using fallback, at which point the client can't submit scores for maps ranked after Fall 2018 anyway.

Not necessarily since the performance difference between fallback and stable isn't very large.
Also, having mp3s at large bitrates like 320kbps can cause problems with loading the audio in osu since sometimes osu fails to load the audio and then you can't do anything about it.

Playing a 320kbps mp3 is not a computationally intensive process at all, an average computer from around 2002, or a feature phone from around 2006 should not have a problem with doing that.

whether or not allowing 320kbps would inconvenience certain users isn't even relevant since

Ephemeral wrote:

320kbps/lossless wont ever be accepted outside of FA tracks because we're not a lossless audio distribution service and barely anyone has the kit or ears to tell past 192kbps in most cases

https://github.com/ppy/osu-wiki/pull/2345 reworded things a bit and added something about re-encoding to higher-than-source bitrates

merged

"frequency cutoffs" can *not* be part of the ranking criteria. this is not a valid way to measure audio quality. Depending on encoder, high-frequency (compression) noise may be added to a track which previously had no data there; tracks may be mastered with a low-pass filter. And on top of all this, the specification was stating inaudible (to most people) ranges.

If you can hear issues with quality then raise an issue; if you can't then don't. we are not here to analyse audio spectograms.

I'm removing this for now to avoid confusion.

Uhm

Why remove that and not the other guideline right beneath it "The audio file of a song should not be re-encoded to a bit rate higher than its source file"? This is the main thing people were reporting on maps. Should it be removed? Is there a reason it was left?

(fixed in https://github.com/ppy/osu-wiki/pull/2453 sort of, this thread should be dead tho)