Guest
home
beatmaps
rankings
community
store
help
forum
  1. Forums
  2. Beatmaps
  3. Mapping Discussion
  4. Ranking Criteria
  5. Finalized/Denied Amendments

[Rule] Maps need a good mp3 to be ranked

posted
Total Posts
47
show more
haha5957
1,433 posts
Joined July 2010
haha5957
You can just simply make 64kbps mp3 file into 192kbp file (and of course the quality still sucks).

Rule like this (stating that the mp3 should be at least 192kbps) wont make anything better...

I honestly had a moment where i had to encode my 96kbps mp3(which was all i had) to 128kbps mp3 because of the rule. (seems like nobody noticed it, LOL, and YES it is ranked)and you know this is kinda stupid.
wetdog123
286 posts
Joined December 2012
Topic Starter
wetdog123

haha5957 wrote:

You can just simply make 64kbps mp3 file into 192kbp file (and of course the quality still sucks).

Rule like this (stating that the mp3 should be at least 192kbps) wont make anything better...

I honestly had a moment where i had to encode my 96kbps mp3(which was all i had) to 128kbps mp3 because of the rule. (seems like nobody noticed it, LOL, and YES it is ranked)and you know this is kinda stupid.

Something like what ziin did could be implemented to auto-detect stuff like this and disallow this from happening.

And that's the main reason i don't play Croatian rhapsody lol
haha5957
1,433 posts
Joined July 2010
haha5957
calling it a main reason when that map actually used decent mp3 file.

good job.
wetdog123
286 posts
Joined December 2012
Topic Starter
wetdog123

haha5957 wrote:

calling it a main reason when that map actually used decent mp3 file.

good job.

Still sounds bad anyway B-)
Ephemeral
Inland Empire
3,936 posts
Joined April 2009
Ephemeral
This is already a rule, as per the audio quality clause cited earlier. It is just not being enforced as well as it should be currently.
Shad0w1and
1,588 posts
Joined April 2011
Shad0w1and
what made you think the mp3 under 192kbps is not acceptable?
http://puu.sh/h891e/79878eba10.mp3
^the current one i am using.
notice that, this is not about bitrate, but about how you coding it and your source. bitrate means nothing and there is no need for RC change to fit your requirement.
you can replace your own mp3 if you know how to trim it with less than 2ms difference. fun? i did some by my own, but i dont even play these songs after i did replace all file to HQ. its a game, who cares?
listen to your own lossless music instead
wetdog123
286 posts
Joined December 2012
Topic Starter
wetdog123

Shad0w1and wrote:

what made you think the mp3 under 192kbps is not acceptable?
http://puu.sh/h891e/79878eba10.mp3
^the current one i am using.
notice that, this is not about bitrate, but about how you coding it and your source. bitrate means nothing and there is no need for RC change to fit your requirement.
you can replace your own mp3 if you know how to trim it with less than 2ms difference. fun? i did some by my own, but i dont even play these songs after i did replace all file to HQ. its a game, who cares?
listen to your own lossless music instead
I was just a little mad at this map https://osu.ppy.sh/s/248876 and went a little too far without knowing as much as i should have known about audio encoding and bitrate, but i think that people should be more careful when acquiring audio files for their beatmap and the quality of audio files should be more strictly enforced during and before qualification of a map.
ziin
2,632 posts
Joined January 2010
ziin

haha5957 wrote:

calling it a main reason when that map actually used decent mp3 file.

good job.

I am speechless.
B1rd
2,974 posts
Joined December 2013
B1rd
Is it really necessary to have the 192kps limit? It's 2015, computer storage space is not at a premium.
ziin
2,632 posts
Joined January 2010
ziin

B1rd wrote:

Is it really necessary to have the 192kps limit? It's 2015, computer storage space is not at a premium.
IIRC osu is not a music hosting service, which is a major reasoning for the hard 192 kbps limit.
B1rd
2,974 posts
Joined December 2013
B1rd
That's right I guess. It's a shame though.
Wafu
1,703 posts
Joined June 2011
Wafu
Well... increasing the bottom limit is not really a good idea. Because, as you maybe know, for example visual novels use sometimes .wav files which are obviously lossless quality, but on the other hand, many of them use 128kbps .ogg files (for example some original うみねこのなく頃に songs), which would be then unrankable. Your ear will recognize difference between 128kbps and lossless, but I think you won't recognize 128kbps and 256kbps unless the encode/rip was wrong.
ziin
2,632 posts
Joined January 2010
ziin

Wafu wrote:

Well... increasing the bottom limit is not really a good idea. Because, as you maybe know, for example visual novels use sometimes .wav files which are obviously lossless quality, but on the other hand, many of them use 128kbps .ogg files (for example some original うみねこのなく頃に songs), which would be then unrankable. Your ear will recognize difference between 128kbps and lossless, but I think you won't recognize 128kbps and 256kbps unless the encode/rip was wrong.
that's the problem. Many of the rips are wrong and have been re-encoded up to 128 kbps mp3.

Also you have it backwards. It's easy to tell the difference between 128 and 256. It's hard to tell the difference between 256 and lossless.
Wafu
1,703 posts
Joined June 2011
Wafu
It's easy to tell difference between 128 and 256, but that depends on a song. High amount of information is not important when the sounds the song is composed with sounds which are not altered by using bitrate of 128. My point was that why the lowest rankable bitrate should be increased, when some songs are done so they don't need more than 128kbps (i.e. poor chiptune or sometimes poor chiptune). You most likely don't recognize 128 vs 256 when the rip is well made. Any distortion signs should be unrankable and these might be caused by wrong encode (most likely) or low bitrate, but that happens mostly only if it's increased to 128kbps from lower volume. Thus the rule should be something like Make sure mp3 is highest quality available unless the bitrate is higher than *new upper limit*. If you re-encoded the mp3, make sure the previous bitrate was not lower than 128kbps and is not distorted.
Lach
1,118 posts
Joined November 2012
Lach

Wafu wrote:

It's easy to tell difference between 128 and 256, but that depends on a song. High amount of information is not important when the sounds the song is composed with sounds which are not altered by using bitrate of 128. My point was that why the lowest rankable bitrate should be increased, when some songs are done so they don't need more than 128kbps (i.e. poor chiptune or sometimes poor chiptune). You most likely don't recognize 128 vs 256 when the rip is well made. Any distortion signs should be unrankable and these might be caused by wrong encode (most likely) or low bitrate, but that happens mostly only if it's increased to 128kbps from lower volume. Thus the rule should be something like Make sure mp3 is highest quality available unless the bitrate is higher than *new upper limit*. If you re-encoded the mp3, make sure the previous bitrate was not lower than 128kbps and is not distorted.
How about instead of a "new rule" you locate a better mp3 for maps before they make it into ranked? Or better yet, before they get into qualified. I''ve done it several times, where the mp3 used was all scratchy and garbage because they were 64kbps upscales which were uploaded to youtube and ripped and then reconverted to 192kbps yet again. Disqualification can and will happen if something sounds like complete arse and you have something better. It's a very simple concept.

Ideally, all tracks should be transcoded from a lossless source, but that's obviously not possible for everything, which is why unless there's a large problem and you can provide something better, leave it alone.
Wafu
1,703 posts
Joined June 2011
Wafu
I did not mean to make a new rule. I just suggested it as if the rule really must be changed, but I can 100% agree with Lach.
Lach
1,118 posts
Joined November 2012
Lach

Wafu wrote:

I did not mean to make a new rule. I just suggested it as if the rule really must be changed, but I can 100% agree with Lach.
It wasn't completely aimed at you nor was it meant to sound overly negative, I just have a habit of doing that. whoops
Wafu
1,703 posts
Joined June 2011
Wafu
Don't worry, I didn't take offensive, just said it to make people know my opinion is not like like: "Make this rule look like this and that", but it was just "make this rule this and that" in case it really needs change, what it doesn't if we take common sense into consideration and also your argument :)
wetdog123
286 posts
Joined December 2012
Topic Starter
wetdog123
I've changed the title and I've modified the contents of the post.

BNs and QATs pretty much need to step up their mp3 game.
Ephemeral
Inland Empire
3,936 posts
Joined April 2009
Ephemeral
Provisions for this already exist within the Ranking Criteria, as stated previously.

The only change to come out of this thread is that the provision is changed to reflect actual audio bitrate, not just container bitrate. This would alleviate issues with transcodes being of technically correct container bitrate, but incorrect audio bitrate.

The song's audio file must be of reasonable quality. Reasonable quality is defined as the actual audio bitrate of a beatmap's audio file being no lower than 128kbps and no higher than 192kbps. Transcoded audio files of a lower actual quality than what their bitrate implies is not allowed. If you are having trouble acquiring an appropriate audio file, contact one of the more audio-savvy BN; they will be more than happy t`o help find an mp3 for you.
ziin
2,632 posts
Joined January 2010
ziin
I'll make a guide on how to tell container quality for the BNs and QATs later this evening. It's not simple.
wetdog123
286 posts
Joined December 2012
Topic Starter
wetdog123

Ephemeral wrote:

Provisions for this already exist within the Ranking Criteria, as stated previously.

The only change to come out of this thread is that the provision is changed to reflect actual audio bitrate, not just container bitrate. This would alleviate issues with transcodes being of technically correct container bitrate, but incorrect audio bitrate.

The song's audio file must be of reasonable quality. Reasonable quality is defined as the actual audio bitrate of a beatmap's audio file being no lower than 128kbps and no higher than 192kbps. Transcoded audio files of a lower actual quality than what their bitrate implies is not allowed. If you are having trouble acquiring an appropriate audio file, contact one of the more audio-savvy BN; they will be more than happy t`o help find an mp3 for you.
Doesnt change the fact that BNs regularly overlook this rule when ranking a map and QATs rarely DQ maps with mp3s that break this rule unless it is pointed out to them.
Last edited by wetdog123 , edited 1 time in total.
ziin
2,632 posts
Joined January 2010
ziin
t/320007

I just posted this, hopefully it will help some people. In case anyone knows more than me on the subject, please help! Hopefully BNs can check for cutoffs below 15k before they bubble. If they have questions on it, they can confer with other BNs and QATs or just bring it to light before it's qualified/ranked.

We're not going to be perfect, but I think that there are some major issues with low quality audio being ranked.
Nathan
Beatmap Nominator
2,144 posts
Joined August 2014
Nathan

ziin wrote:

BNs can check for cutoffs below 15k before they bubble.
Something similar would be much more definite over RC's version of "reasonable quality" imo.
ziin
2,632 posts
Joined January 2010
ziin

sukiNathan wrote:

ziin wrote:

BNs can check for cutoffs below 15k before they bubble.
Something similar would be much more definite over RC's version of "reasonable quality" imo.
I'm a bit worried that
1) nobody knows what the heck the cutoff below 15k is without reading an entire page
2) there are reasonable exceptions to the "rule" that 15khz cutoff is unrankable, such as recorded audio.
3) bad encodes could still be audible but not exactly visible.
Lach
1,118 posts
Joined November 2012
Lach
The problem is that if people start witch hunting frequency cutoffs, it's going to be as awful as metadata discussion. And NOBODY wants that. The audio "modding" side of things should stick to "Here's a better mp3, please replace your current one." and not "Well, as you can see, the frequencies cut off below xxkhz."
Wafu
1,703 posts
Joined June 2011
Wafu
Exactly as I said, there is an issue with for example chiptune and fake chiptune songs. This is Cave Story+ theme, original, best quality available.

SPOILER
ziin
2,632 posts
Joined January 2010
ziin
Hmm, is Cave Story+ theme different frome the Cave Story theme? http://www.cavestory.org/download/music.php I recorded this from the original ORG files released here...
cave story op

Chiptunes usually have full spectrums, they just compress really well due to the low bitrate.

@Lach,
Hopefully anyone modding suggesting that the mp3 be replaced will also provide a better quality mp3, but having visual proof of poor quality is always a good thing. I also don't like the way you use "witch hunt" because ranked maps should be perfect, and quality should be checked by the BNs prior to a bubble. I think hhjkl let the cat out of the bag here, then I drop kicked it out when it wasn't sure if it was going out or in.
Wafu
1,703 posts
Joined June 2011
Wafu
Yes, Cave Story+ theme is different, it is remastered. And whole game is a bit smoother and so on. Also just checked some piano songs which were also original (I even got them with EAC) and their frequency was low too. Just trust it or not, but some songs just don't have high frequencies even in their original form, so it is definitely not that much reliable. Idea was definitely not the worst, but the rule, in my opinion might be this to prevent some issues:

Audio file must be reasonable quality. Its bitrate should be between 128kbps and *something*kbps. There must not be any encoding error and audio spectrum must be compared with original or highest available quality music file in external program (for example Spek), if there is a big difference in frequencies, it most likely might be an encode error and you have to replace the mp3 with better quality.

We just cannot say: "This song has low frequencies thus it cannot be used, no matter the original is same and it is suppose to be like that", that would not make sense.

Also some Umineko songs seem to have lower frequencies and the higher quality just doesn't exist, so this definitely has to be consulted.
69653863
1,818 posts
Joined January 2012
69653863
I remember seeing a rejection over "use high(er) quality mp3 for beatmaps" feature request somewhere, since it might turn this site into some kind of "mp3 download site" or something like that. But hey, nothing's wrong with a good audio quality in maps, right?
Lust
osu! Alumni
2,667 posts
Joined January 2013
Lust
Since there is already a provision for this in the ranking criteria, I will proceed to flame this. If you wish to have a new rule dealing with the actual audio bitrate as opposed to the container bitrate, please proceed to create a new thread with the appropriate wording.
Please sign in to reply.

New reply

0
17 / 47