forum

[Proposal/Discussion] MP3 Rules

posted
Total Posts
67
Topic Starter
AJT
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:
  1. 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.

Proposal:
  1. 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 to avoid filesize bloat.
  2. Audio files at the maximum allowed bit rate (192kbps) do not require improvements, provided they are not overencoded. Minor quality improvements between audio files (e.g. whose bitrates are within around 20kbps of each other) are optional.
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.
UberFazz
nice and simple clarification as to what's essentially already been accepted (and just makes sense), +1
Kite
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.
Topic Starter
AJT
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
Kite
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.
Topic Starter
AJT
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
Ikikaera
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.
Topic Starter
AJT
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
Hivie
Good adjustment, +1
wafer
Agree

+1
Cynplytholowazy
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
Basensorex
agree, +1
Topic Starter
AJT

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
Doormat
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
Cynplytholowazy

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
Topic Starter
AJT

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
Noffy
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.
Cynplytholowazy

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
Noffy
The 192 rule is seperate and not being changed in this discussion, so it's not affected by the proposal at all
Topic Starter
AJT

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:

  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 or equal to 32kbps higher than the original files.
Noffy
That version sounds good to me

+1
Reform
Agree +1
Cynplytholowazy
+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
riffy
+1, that's a pretty welcome change in the RC
Maxus
Really proud of how this turns out, definitely +1 from me!
show more
Please sign in to reply.

New reply