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

+1

Naxess wrote:

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.

I am fine with this with the sole addition of:

Addition wrote:

1. The audio file of a beatmap must...
   
   1. ...use the .mp3 or .ogg file format.
   2. ...be of acceptable listening quality without any basic audio enhancements applied (no bass boosting, excessive amplification)
   3. ...have an average bit rate no greater than 192 kbps.
   4. ...have an average bit rate no lower than 128 kbps, if such a source exists, otherwise use the highest quality available.
   5. ...not be encoded upwards from a lower bitrate.

This doesn't take us very far from what already exists (outside of wording it nominally better, good call there) but does importantly outline the "acceptable quality" requirement for audio, which absolutely needs to stay.

I don't want to see people using crusty rips at the correct bitrates when they're mangled to all heck and arguing with other people over better audio when what they've got is technically correct but actually objectively worse, which will happen.

think it would be better to contextualise the 2nd bullet point in terms of you applying those enhancements yourself rather than them having been done so by the artist, so it doesn't potentially confuse people into lower volume on mp3s that are intentionally "bass boosted" or amplified for effect (e.g. some hyperpop songs, some hardcore artists, etc.)

Agree that the term acceptable can be elaborated more.
To me acceptable audio pretty much means: clear sounds (no muffled or "crusty" quality like in Ephemerals earlier example), no clipping, decent volume (shouldn't require to adjust your system settings in order to get a good listening experience compared to other song audio files)

Maybe we can work out a more detailed wording as a replacement here

forgot the hs part of the original rule

Updated wrote:

1. The audio file of a beatmap must...
   
   1. ...use the .mp3 or .ogg file format.
   2. ...be of acceptable listening quality while avoiding basic audio enhancements such as bass boosting or excessive amplification, unless purposely done by the artist. This applies to hitsound files as well.
   3. ...have an average bit rate no greater than 192 kbps.
   4. ...have an average bit rate no lower than 128 kbps, if such a source exists. Otherwise, use the highest quality available.
   5. ...not be encoded upwards from a lower bitrate.

also slightly reworded eph's addition (assuming i understood it correctly). i understand the problems with using terms like "acceptable" but i also cant think of a scenario where it could cause issues
+ made tiny grammar fix

The reason I removed the "reasonable quality" stuff is that it's way too vague to be in a rule. It also strayed from only being about the song's audio to also hitsounds, and so would probably be best as a separate criterion if anything.

How about this:

New rule 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.

New guideline wrote:

1. The audio file and hitsound files of a beatmap should not feature any audible and unwarranted sound distortions, like clipping, muffling, or crackling that is obviously not intended by the artist. Simply listen to the audio for this and avoid relying on spectrograms or waveforms.

This also spells out that "reasonable quality" means to actually just listen to determine if it sounds ok.

edit: slightly less tutorial-like

^ i'm fine with this, perhaps the wording of the guideline could be tweaked so it sounds less... tutorial-like? idk, but yea in terms of content i think this is where we should be

I agree with Naxess' suggestion and I tried to simplify a little bit so it doesn't sound too nerdy/tutorial-like as ajt mentioned:

New guideline wrote:

1. The audio file and hitsound files of a beatmap should not feature any audible and unwarranted sound distortions, like clipping, muffling, or crackling that is not intended by the artist. Listen to the audio instead of just relying on software to detect these kind of issues.

edit: removed "obviously" from the first sentence too its not needed

Burak wrote:

I agree with Naxess' suggestion and I tried to simplify a little bit so it doesn't sound too nerdy/tutorial-like as ajt mentioned:

New guideline wrote:

1. The audio file and hitsound files of a beatmap should not feature any audible and unwarranted sound distortions, like clipping, muffling, or crackling that is not intended by the artist. Listen to the audio instead of just relying on software to detect these kind of issues.

edit: removed "obviously" from the first sentence too its not needed

Don't think that whole paragraph on listening to the audio is needed.
Aside from that it's gucci

Naxess wrote:

community/forums/posts/8563364

Redrafted slightly, thoughts?

New rule 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.

New guideline wrote:

1. The audio file and hitsound files of a beatmap should not feature any audible and unwarranted sound distortions, like clipping, muffling, or crackling that is [clearly/obviously] not intended by the artist. This is best determined by listening to the audio, rather than using software on its own.

With regards to the adjective in brackets being superfluous or not, I think it could help in terms of indicating that you should just use common sense here rather than going on some CIA research quest to determine what was intentional in every file, although I don't think it makes much of a difference

Latest iteration is S-tier. It is amazing. +1

AJT wrote:

Redrafted slightly, thoughts?

Agree with the [clearly/obviously] stuff, I think that helps to not give people the wrong idea about how strict that part of the rule is.

Can reword slightly in the PR if needed. Let's give this another 24h to see if there's anything we missed before proceeding.

seems good to me here, i would love to see this passes in the current state

+1 agree owo

OK I'll PR at lunch
edit: Naxess saved me from githubbing again

merged!