forum

[Rule] Maps need a good mp3 to be ranked

posted
Total Posts
47
Topic Starter
wetdog123
It's actually retarded when BNs qualify maps with bad mp3s

It's not like it's hard to get a good mp3 for a beatmap either, and it shouldn't be tolerated when somebody uses a mp3 that sounds like im listening to it on shitty $12 speakers from 3 rooms over. It should be required that BNs provide good mp3s when bubbling a map and QATs should dequalify maps for having low quality Mp3s.

Example of a map with low quality mp3 in qualified: https://osu.ppy.sh/b/635679
Example of a map with high quality mp3 in qualified: They're pretty much all good right now, but i'm 100% sure a BN will rank a map with a bad mp3 pretty soon.

Also mappers should be half arsed when they get their mp3s, if you're ready to put the effort in to ranking a map, you should at least get a good mp3.

13/04/15 3:46pm - changed title from [Rule] Atleast 192kbps mp3 on ranked maps to [Rule] Maps need a good mp3 to be ranked, also changed my post to something harsher.
peppy
192kbit is fine if encoded properly. That said, we likely don't have good enough measures in place to avoid bad encodings from slipping through. Need more users to report bad MP3s during the ranking process.
Topic Starter
wetdog123

peppy wrote:

192kbit is fine if encoded properly. That said, we likely don't have good enough measures in place to avoid bad encodings from slipping through. Need more users to report bad MP3s during the ranking process.

Do you think it would be a good idea to disqualify maps with low quality mp3s?
Bara-
Size will be too big then
We have a max filesize, and mp3 can easily break it
I disagree due to this
-Maus-
Yeah, I made a mania 320 kbps map, it's like 13 MB big lol
Kodora

baraatje123 wrote:

We have a max filesize, and mp3 can easily break it
30 mb mp3s for tv size songs? please
Topic Starter
wetdog123
While 320kbps may be out of the question due to filesize (it's not even that big tho lol), properly encoded 192kbps is still pretty good, small in file size and should be enforced on ranked maps.
Gumpy

hhjkl wrote:

(it's not even that big tho lol)
If you have hundreds of songs 13mb files can easily take up way more than needed. That's not including a bg and video.
Bara-

Kodora wrote:

baraatje123 wrote:

We have a max filesize, and mp3 can easily break it
30 mb mp3s for tv size songs? please
More then 10 is only for video right?
Topic Starter
wetdog123

Gumpyyy wrote:

hhjkl wrote:

(it's not even that big tho lol)
If you have hundreds of songs 13mb files can easily take up way more than needed. That's not including a bg and video.

hhjkl wrote:

properly encoded 192kbps is still pretty good, small in file size and should be enforced on ranked maps.
Frim4503

baraatje123 wrote:

More then 10 is only for video right?
is only for video and SB
3 min map filesize, average is 5MB
if including vidoe and SB it can 20MB
Bara-
Wait
Shouldn't this be posted in Ranking Criteria Forum?
If so, can this be moved and changed according o the format of that forum
Or someone could create a new thread there and then this one should be marked invalid (as it's a rankablilty issue)
Lust

hhjkl wrote:

Do you think it would be a good idea to disqualify maps with low quality mp3s?
From the ranking criteria,
The song's audio file must be of reasonable quality. Try and source mp3 files yourself; ripping them from a streaming video site often results in low quality audio with high file sizes. The bitrate of a beatmap's audio file must be no lower than 128kbps and no higher than 192kbps. If you are having trouble acquiring an appropriate audio file, contact one of the more audio-savvy BN; they will be more than happy to help find an mp3 for you.
So yes, if the audio quality is very poor we will disqualify a mapset accordingly. 128kbps is a fine minimum in my eyes; however since you would like to see a 192 minimum I shall move this to the correct subforum where you can appropriately direct your efforts.
lolcubes
In most cases, really bad sounding mp3s are actually bad from the source (a bad rip most usually). It has rarely something to do with the bitrate itself.
There are very few songs which actually sound bad as 192kbps, due to the bitrate itself.
ziin

Top left: source ogg
Top right: 128 kbps mp3 from source ogg
Bottom left: beatmap audio
Bottom right: youtube video audio Note the names are virtually the same.

I can almost guarantee that the source (best quality I could find was the ogg submitted to the contest) was not used. Instead the 96 kbps mp4 audio stream from the video was used and encoded to 128 kbps resulting in the cutoff at 15kHz (which is expected of an mp3 at 96kHz).

It would be good to use a spectrum analyzer during the qualification process to confirm that the cutoff is above 16kHz (128 kbps mp3). The upper limit would be 19kHz for 192 kbps, but that's not important for obvious reasons. This is supposed to come out during modding, but clearly this is getting missed as it is a tedious process such as checking for metadata consistency prior to automation via AIMod and AIBat. It could be automated, but I sincerely doubt that anyone has the time or energy to figure something like this out. I wasn't able to find a simple program to do this automatically without visual inspection.
Topic Starter
wetdog123

Lust wrote:

hhjkl wrote:

Do you think it would be a good idea to disqualify maps with low quality mp3s?
From the ranking criteria,
The song's audio file must be of reasonable quality. Try and source mp3 files yourself; ripping them from a streaming video site often results in low quality audio with high file sizes. The bitrate of a beatmap's audio file must be no lower than 128kbps and no higher than 192kbps. If you are having trouble acquiring an appropriate audio file, contact one of the more audio-savvy BN; they will be more than happy to help find an mp3 for you.
So yes, if the audio quality is very poor we will disqualify a mapset accordingly. 128kbps is a fine minimum in my eyes; however since you would like to see a 192 minimum I shall move this to the correct subforum where you can appropriately direct your efforts.

Ok.. I think a better alternative to straight up making people use 192kbps would be for BNs and QATs to strictly enforce the use of properly encoded mp3s.
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.
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
calling it a main reason when that map actually used decent mp3 file.

good job.
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
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
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
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

haha5957 wrote:

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

good job.

I am speechless.
B1rd
Is it really necessary to have the 192kps limit? It's 2015, computer storage space is not at a premium.
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
That's right I guess. It's a shame though.
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

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

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.
show more
Please sign in to reply.

New reply