Seen a lot of discontent with the current MP3 legislation but no one seems to want to actually open discussion about it, so I will attempt to do so

Current rule:

Proposal:
Alternative proposal in this reply: community/forums/posts/8560832

Changes:
- Added an explanation for why MP3s should not be overencoded as there seemed to be confusion over the purpose of the rule
- Added an addendum to specify that improvements are not necessary when the MP3 is good enough, or if the suggested MP3 is similar to the current one (open to discussion)

Feel free to use this thread to discuss any other concerns with the current rules if you have any.

nice and simple clarification as to what's essentially already been accepted (and just makes sense), +1

I agree this rule needs to be adjusted.

Some points I would like to bring up:

These rules are for mappers, from a technical point of view it's asking a bit much.
The most important thing is the audio file being of reasonable quality, anyone should be able to tell a bad quality file from a decent quality sounding file without taking a look at the bitrate or khz peaks.
Often times people can't tell the difference on files with decent quality due to lacking hardware / equipment, this shouldn't be a limitting factor when it comes to mapping.

I'd like to see more focus on the very first sentence of the rule whereas the rest would be moved to a guideline instead.

Although some people cannot really tell the difference audibly between files above 128kbps due to their ears or their hardware (me included), I have heard people with more acute ears/better hardware complain about this, and given that it would improve some people’s experience I don’t think there’s really any reason to not upgrade from 128kbps to 192kbps if someone is providing you the new MP3 and offset (or even cutting it so the offset is the same) as it doesn’t take much effort or punish the BNs at all.

I had been thinking about lowering the threshold in the proposal for not needing to update the MP3 to about 160kbps, but I wanted more opinions so that’s why I put open to discussion

Also, I have reservations about moving it to a guideline rather than just being more clear: defining what constitutes a good enough reason to ignore the guideline would be tough (since guidelines too should be followed unless there are exceptional circumstances), and scenarios where a mapper refuses to upgrade for example a 128 to a 192 when other people can hear the difference simply because they can’t on their own hardware - it would just become a lot of he said she said so I think it’s better to have an actual limit or something of the sorts. I suppose you could let vetoes handle those cases if someone cares enough, but it just seems really messy to me

If a better quality file is provided it should be used, yeah I agree, since it's in the best interest of the mapper to improve their mapset as much as possible.
However the osu mapping environment by default is not a place for audiophiles due to the 192kbps limit, so I am not sure if it's the right step to cater in that direction via rules.

My issue lies mostly with making it mandatory to update a qualified mapset instead of leaving the decision to the mapper.
Many people lack the understanding for this topic and wouldn't see a lot of reason if they are forced to change something they can't tell the difference for on their setup.

We should avoid cases where this could happen in the first place, but honestly this is a very difficult topic.


Perhaps it's for the best to just find a clear definition of what's considered "reasonable" quality, bitrate matters little compared to the audible impression you get, khz peaks matter only for those who have the right equipment.

Edit:
Overall I agree with your proposal since it's a lot more clear.

there's obviously a point of diminishing returns where it's literally not worth upgrading the mp3, me and apollo were thinking about doing a blind survey with several different genres of songs shown in 128, 160 and 192 and asking the participant to rate them in quality, and seeing how many people get them right - if enough responses are obtained this could give an accurate threshold as to where it's actually worth upgrading the mp3 on average and hence where to place a limit if there would be one (whilst still giving people the option to do minor upgrades if they actually want to regardless of what the rules are) <- probably not necessary to at least move forward but will prob do it anyways in like june

also, i'm open to suggestions on the last part - the intention behind it is that you shouldn't be required to upgrade from a 128 to a slightly better 128, a 160 to a slightly better 160, a 192 to a slightly better 192, etc., and that it should be optional

"Quality improvements between audio files within 32 bitrate of each other are optional, assuming the current mp3 is not overencoded."

^ this currently means that you wouldn't have to upgrade from 128 to 160, or 160 to 192, unless you want to, but you would need to upgrade from 128 to 192 if suggested

also open to wording suggestions to make it less complicated, kind of hard to talk about bitrate without getting technical but it seems necessary if establishing any limit or threshold

I've talked with AJT and we came to the conclusion that changing it into a 20kbps margin would still help a lot while also preventing any bad actors from abusing it for trolling purposes.

Reasons for that is that it'll still encompass VBR encodings of a target bitrate of 192kbps which can, depending on the song, still dip to the 180s or even upper 170s despite being virtually the same audio quality as a 192kbps CBR.
But it'll make sure that it'll still be mandatory for a 160kbps CBR to be improved to one at ~192kbps.

Generally, it's incredibly rare for someone to be able to get their hands on a 160kbps without being able to get a 192kbps, there aren't really any services that upload audio at around that bitrate.
Most of those cases are really new anime releases where episodes haven't been shared in a high enough quality yet, but this would be protected by the rule of only using the highest quality audio available since that's all that's available.

But yeah, I'm also of the opinion that changes from 192kbps to 192kbps are extremely silly and shouldn't need to be done.
Nobody would be able to hear a difference between different compressors that were used at the same quality, no matter how well trained your ears are.

Do keep suggestions for changes rolling though.

there was another discussion in the BN server just now, there was some support for the conjection that 128->192 isn't discernible for most players. regardless, i've heard several people notice that difference easily and if the difference in quality is that big then i'd say you should upgrade, however it does bring up scope for the current ~20kbps range to be increased a bit, so still open to opinions there

since there do seem to be two different camps in this regard i probably will end up conducting the survey/questionnare that i mentioned earlier to actually determine where most people stop hearing audio improvements and hence what to do with that. as i said personally i rarely hear the difference but i have ear problems and a laptop with cheap earphones so i think to make any change regarding mp3s there'd need to be a lot of contextual data

Good adjustment, +1

Agree

+1

Suggest changing the "Try to find the highest quality source file available" to "Try to find higher quality source file available". Given the context is to stress the "rather than ripping a file from a streaming video website", make it clearer that it is to make sure the rule is interpreted more on the stress of not ripping from video sites instead of letting anyone confuse they have to find the highest quality source

+1 on the proposal as well tho

agree, +1

Cynplytholowazy wrote:

Suggest changing the "Try to find the highest quality source file available" to "Try to find higher quality source file available". Given the context is to stress the "rather than ripping a file from a streaming video website", make it clearer that it is to make sure the rule is interpreted more on the stress of not ripping from video sites instead of letting anyone confuse they have to find the highest quality source

+1 on the proposal as well tho

do you mean smth like "Try to find a high quality source rather than ripping a file from a streaming video website."?

i agree the intention of that rule is prob just to get a high quality and not the absolute best cutoff 192 mp3, although i think the extra wording at the bottom might already solve this? i think changing to "high quality source" would be sensible too tho

Agreed +1

Also worth considering, you might want to add an addendum that says not to rely too much on spectrograms like spek. Different masterings/encoding settings can yield completely different spectrograms despite the audio quality being pretty much fine, e.g. anti-aliasing. It's always been pretty ridiculous how some people try to say that acceptable audio is trash just because of a jpeg of a graph; I prefer to determine audio quality with my ears, not my eyes

AJT wrote:

Cynplytholowazy wrote:

Suggest changing the "Try to find the highest quality source file available" to "Try to find higher quality source file available". Given the context is to stress the "rather than ripping a file from a streaming video website", make it clearer that it is to make sure the rule is interpreted more on the stress of not ripping from video sites instead of letting anyone confuse they have to find the highest quality source

+1 on the proposal as well tho

do you mean smth like "Try to find a high quality source rather than ripping a file from a streaming video website."?

i agree the intention of that rule is prob just to get a high quality and not the absolute best cutoff 192 mp3, although i think the extra wording at the bottom might already solve this? i think changing to "high quality source" would be sensible too tho

Yep that would sound better, just do "try to find a high quality source" should be enough

Doormat wrote:

Agreed +1

Also worth considering, you might want to add an addendum that says not to rely too much on spectrograms like spek. Different masterings/encoding settings can yield completely different spectrograms despite the audio quality being pretty much fine, e.g. anti-aliasing. It's always been pretty ridiculous how some people try to say that acceptable audio is trash just because of a jpeg of a graph; I prefer to determine audio quality with my ears, not my eyes

iirc the main RC avoids mentioning external tools, but I think this could be covered in the recently added "tools" section at the start of the general RC:


so perhaps a mention/link to spectro/spek could be added there instead
realistically spectrographs only need to be used for overencoding purposes

Writing a bunch of stuff like "reasonable" or "optional" in a rule is a mistake to begin with to be honest, they're not enforceable as a hard rule, besides applying it all the time, so it defeats the point of that phrasing.

It has the same problems as the current one

... I'm getting flashbacks to when I got told off when PRing a meta change for the same issue ahah

So I'd think we'd really need to re write it to avoid that kind of phrasing as much as possible.



- For better context:
The OLD old rule specified minimum 128kbps max 192 kbs. However this REQUIRED over encoding songs which did not have at least 128 quality audio in existence. This was changed to "reasonable" quality to avoid such contradictory practices but it looks like bad actors are making that backfire. Oof.

propose noffy wrote:

1. A song's audio file and hitsound files must be of reasonable quality. When possible, a song's audio must be at least 128kbps in quality. When the minimum is not possible, use the highest sub-128kbps quality audio available.
2. A song's audio file must not be encoded to a bit rate more than 20kbps higher than the original files.

Reinstated 128 as general minimum, gets rid of reasonable quality all together. As long as they hit that minimum they're fine. This way the minimum exists without the old contradictory practice of up encoding songs that don't exist in at least 128.


Separates over encoding into its own rule so that it's easier to find and can be better specified.

Noffy wrote:

Writing a bunch of stuff like "reasonable" or "optional" in a rule is a mistake to begin with to be honest, they're not enforceable as a hard rule, besides applying it all the time, so it defeats the point of that phrasing.

It has the same problems as the current one

... I'm getting flashbacks to when I got told off when PRing a meta change for the same issue ahah

So I'd think we'd really need to re write it to avoid that kind of phrasing as much as possible.



- For better context:
The OLD old rule specified minimum 128kbps max 192 kbs. However this REQUIRED over encoding songs which did not have at least 128 quality audio in existence. This was changed to "reasonable" quality to avoid such contradictory practices but it looks like bad actors are making that backfire. Oof.

propose noffy wrote:

1. A song's audio file and hitsound files must be of reasonable quality. When possible, a song's audio must be at least 128kbps in quality. When the minimum is not possible, use the highest sub-128kbps quality audio available.
2. A song's audio file must not be encoded to a bit rate more than 20kbps higher than the original files.

Reinstated 128 as general minimum, gets rid of reasonable quality all together. As long as they hit that minimum they're fine. This way the minimum exists without the old contradictory practice of up encoding songs that don't exist in at least 128.


Separates over encoding into its own rule so that it's easier to find and can be better specified.

Is it still planned to hard cap audio to 192kbps cuz it looks like there isn't a hard cap on the file size on your proposal

do think it's a good idea to separate overencoding rule cuz it will be more clear that way to enforce it

The 192 rule is seperate and not being changed in this discussion, so it's not affected by the proposal at all

Noffy wrote:

Writing a bunch of stuff like "reasonable" or "optional" in a rule is a mistake to begin with to be honest, they're not enforceable as a hard rule, besides applying it all the time, so it defeats the point of that phrasing.

It has the same problems as the current one

... I'm getting flashbacks to when I got told off when PRing a meta change for the same issue ahah

So I'd think we'd really need to re write it to avoid that kind of phrasing as much as possible.



- For better context:
The OLD old rule specified minimum 128kbps max 192 kbs. However this REQUIRED over encoding songs which did not have at least 128 quality audio in existence. This was changed to "reasonable" quality to avoid such contradictory practices but it looks like bad actors are making that backfire. Oof.

propose noffy wrote:

1. A song's audio file and hitsound files must be of reasonable quality. When possible, a song's audio must be at least 128kbps in quality. When the minimum is not possible, use the highest sub-128kbps quality audio available.
2. A song's audio file must not be encoded to a bit rate more than 20kbps higher than the original files.

Reinstated 128 as general minimum, gets rid of reasonable quality all together. As long as they hit that minimum they're fine. This way the minimum exists without the old contradictory practice of up encoding songs that don't exist in at least 128.


Separates over encoding into its own rule so that it's easier to find and can be better specified.

- agree with "reasonable" being a bad word to use, i don't think "optional" has the same pitfall since to me it seems to categorically be specifying that you can't force a minor upgrade if the mapper doesn't want to, but regardless i think your suggested wording works to that end as well, so:
- regarding your proposal, I agree with the first part, i think if you're going to change the 2nd encoding rule to that then it makes more sense to change it back to 32 since it's not really about minor improvements anymore but more about exporting at the wrong bitrate, and it's easier to recognise as well using the 128-160-192 threshold instead of requiring that precision

hence this is where i land:

That version sounds good to me

+1

Agree +1

+1

any plan to keep the "try to avoid ripping from video streaming site" line for some guidance to newer mappers, feels like it would add more information to it

+1, that's a pretty welcome change in the RC

Really proud of how this turns out, definitely +1 from me!

Reinstating a minimum sounds like a good idea to avoid any RC ambiguities and shenanigans.
+1

this adjustment sounds great to prevent a number of loopholes. +1

Guys no don't do it the 14 year old will lose his job. +1

Sounds fair to me, especially to prevent constant endless discussions.

to the end of random people popping up every 6 month posting audio "issues" on every single qfd map, hurrah! +1

sounds perfect +111 this is a really needed change after the recent unnecessary reports on qualified maps

also speaking of audio rc changes, can we just delete the word "video" as well? so it will make less confusing because streaming isnt always about video, but audio as well (for example, soundcloud, spotify, youtube music, etc...) and to avoid loopholes about site that should be used to get audio

so the proposal would be like this

Proposal:

changes: only remove word "video"

1. A song's audio file and hitsound files must be of reasonable quality. When possible, a song's audio must be at least 128kbps in quality. When the minimum is not possible, use the highest sub-128kbps quality audio available.

This is mostly fine. It is important to note that bitrate does not guarantee sound quality, so adding in a 128kbps minimum will not absolve people of the responsibility of needing listen and judge the tracks to actually be at that generally expected level of quality.

It may be better practice to split off the sub-128kbps clause into its own guideline to highlight it better, but I honestly don't think this will crop up a lot.

I think a lot of people in this thread think this will stop the spate of disqualifications over audio quality in its tracks - it might slow some of it down, but it definitely isn't going to stop the notion from happening again.

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.

+1 to the changes you talked about

One more point I'd like to raise is the mentioning of streaming services in the rule. Inherently it's not bad to rip from them given you use proper tools and have the required know-how. YT-DL can get you good quality files, in some cases it even got me better ones than I was able to acquire through other means.

Might probably be in the best interest to remove that part to not bloat the rule itself? If people use online converters you will still be able to tell due to the lack of quality so covering these cases specifically feels a bit redundant.

yt-dlp and other associated tools are fine to use in my view so long as the source content is not overtly crusty or obviously modified (bass boosted, etc). This is of course straight transcoding and will incur some quality loss, but I doubt most people will notice.

Crusty example: https://www.youtube.com/watch?v=bmnCU_9nHHs

Less crusty (acceptable) example: https://www.youtube.com/watch?v=BqijsweJzFQ

Hopefully that illustrates what I'm getting at. This all being said, using a lossless source for your transcode is ideal practice, but I understand that not everybody knows how to access that kind of stuff.

Yeah those two examples are pretty clear when it comes to quality.

Edit:
This is also the standard I want to promote, your acceptable example would be perfectly fine for ranking. Any further improvements should be optional for the mapper.

Yes, we need this rule clarification.

By the way there is a need to expand the bit rate article on wiki: wiki/en/Bit_rate about other additional metrics/methodologies to assess audio quality rather than a bit rate (such as spectrum and frequencies etc) and for this rule in RC in the future maybe better to have an hyperref to that articile for a more fine-grained guide if people are additionally interested in audio quality assessment.

+1 from me too. This just makes everyone's life easier, plus it doesn't force meddling with audios of older songs that could be enhanced with new tech.

+1 agree

+1

frozz wrote:

also speaking of audio rc changes, can we just delete the word "video" as well? so it will make less confusing because streaming isnt always about video, but audio as well (for example, soundcloud, spotify, youtube music, etc...) and to avoid loopholes about site that should be used to get audio

i've had bad experiences with soundcloud but from experience stuff like spotify and the auto-generated youtube videos for most songs are completely fine. i think the clause for streaming services generally doesn't need to exist, esp for platforms in where official sources (i.e. the original artist/s) have their music uploaded (spotify in particular since it is the king of popularity in the streaming space). Any time it is an issue is almost 100% of the time due to the source coming from a channel not associated with the music act. I've had exactly 1 example of spotify not providing a good mp3, and that was for olivia rodrigo's good 4 u.

On a different note, the "normalised to original level" should probably be changed to "normalized to 0db". while that's... usually the case; i've had ocassional official sources end up being too quiet to be practical. And also, if this were to stay, it would, at least literally mean any kind of rip from an anime should be left at it's original, stupidly quiet volume.

There's also the examples of really, really loud songs that probably should be turned down for the sake of the player's ears, and also for the sake of having hitsounds be audible at all (a lot of spyair songs tend to have this kind of thing) and leaving that as is can really make it odd to get jumpscared by a loud-ass mp3 then having to turn down the music, only to turn it up again since other songs tend not to be as loud.

I think setting a set general rms range for loudness would be better than trying to go for the original all of the time, just because of how people play the game and for people not as well versed to get a gist for what most maps should generally be like

proposal:

Crux seems to be having improvement be optional after a certain point. 1st part of Noffy's proposal solves that.

I'd suggest rewording and combining that as follows for simplicity / coherency:

Old rules wrote:

1. A beatmap's audio file must use the .mp3 or .ogg file format and have an average bit rate no greater than 192kbps.
2. A song's audio file and hitsound files must be of reasonable quality. Try to find the highest quality source file available rather than ripping a file from a streaming video website. Songs should be normalised to their original release volumes and should not be encoded to a bit rate higher than their original files.

->

New rules wrote:

1. The audio file of a beatmap must...
   
   1. ...use the .mp3 or .ogg file format.
   2. ...have an average bit rate no greater than 192 kbps.
   3. ...have an average bit rate no lower than 128 kbps, if such a source exists, otherwise use the highest quality available.
   4. ...not be encoded upwards from a lower bitrate.

^ this sounds fine

@xandit with regards to normalising, some songs are intentionally loud or quiet (e.g. camellia songs), so forcing people to lower the volume there doesn’t really match up with what the artist wanted. At the same time, I personally don’t think it’s very harmful to raise audios volume (below the clipping point) if it’s abnormally quiet and seemingly unintentionally, but it is a trade off in terms of quality and it’s a hard line to draw, I don’t think your current wording works for that

Ephemeral wrote:

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.

i don’t know if we were talking about the same thing here since i wasn’t necessarily talking about exporting a file then exporting it again in a higher bitrate, i was kind of just talking about obtaining the file and then exporting it (i.e. because the “listed” bitrate is more than 192) in a higher bitrate than the song data actually supports (unless you’re referring to the first being run through an encoder as what occurred before the obtaining of the MP3 in the first place) i.e. all of the encoding issues getting DQed for are likely accidental rather than anyone actually thinking increasing the bitrate in audacity increases the quality (so it’s people not downcoding the bitrate when they should rather than them increasing it)

Regardless, that sounds fine to me under naxess’ proposal. The reason that was conjected was because of the only options for encoding above 128 in the most popular services being in 32kbps intervals, and a 10kbps overencode for example being very unrealistic and tedious to expect BNs to check for. Naxess’ phrasing is more hardline which should still get the job done, but I really doubt people are going to go and search for overencodes less than that value anyway (no-one does currently)

furthermore there was actually sizable discontent over the current overencoding rule since people weren’t actually sure what it was for and expressed that mp3s sounded exactly the same to them before and after fixing (which makes sense, since the same amount of data in the song would exist after lowering it, but with less wasted filesize) and hence it was understood that it was intended to limit filesize bloat rather than actually affect anyone’s gameplay experience, but I wouldn’t call myself an expert on the matter so

@frozz I don’t think that’s what the rule was meant to do, it’s implying to not use yt rips (YouTube to MP3 website converter type beat), which is already slightly outdated since you can rip in decent quality with command lines as kite has explained. Regardless, that part isn’t even in the current proposal anymore so yeah

[quote=“Ephemeral”]

I think a lot of people in this thread think this will stop the spate of disqualifications over audio quality in its tracks - it might slow some of it down, but it definitely isn't going to stop the notion from happening again. [/quote]

^ hard agree, can’t stress this enough. overencoding will still be a thing that people could QAH for, and people may still suggest upgrading to 192 quality if the map is using 128 - if these scenarios occur I don’t want there to be any harassment or spamming on either side since that just makes these threads way more of a headache than necessary.

sounds great, easy +1 from me!

should be fine so that no one is policing a completely fine audio while remaining the overencoded rule in place, +1.

gud 👍
+1

+1

+1 agree

+1 owo

+1 then

+1 nice