This amendment concerns the general ranking criteria audio section.

Current rule: "A beatmapset's audio file must use the .mp3 or .ogg file format and have an average bit rate no greater than 192kbps."

Rule modification proposal: "A beatmapset's audio file must use the .mp3 or .ogg file format. Its quality must obey a maximum limit of 192kbps constant bitrate for .mp3 and VBR6 level for .ogg"

Given that the .ogg file format has seen a steady rise in popularity and is more common every day as the format of choice for beatmapsets, revising the audio bitrate rule seems only logical. This rule is inheritly flawed for analyzing .ogg files and therefore an update is long overdue.

This proposal changes nothing for .mp3 files and rankability regarding their bitrates.

In this proposal we will be considering audio files exported from Audacity as this is by far the most common audio manipulation program used by mappers and BN/NAT members alike.

An .ogg is a file format that does not use an explicit constant bitrate. Rather it uses a quality setting from 0-10 which roughly corresponds to an average bitrate in mp3 as described by Audacity . The problem with this is that the .ogg quality setting 6 (from now on referred to as VBR6) is supposed to correspond to a 192kbps bitrate, but in practice the bitrate can be slightly different. This can be seen as highlighted in this example.

In the example above the currently rankable options would be an mp3 with a lot of clipping or an .ogg VBR5 file which corresponds to an average bitrate of 162kbps. By allowing VBR6 to be rankable we would allow greater quality audio in some scenarios at near-negligable filesize changes. As shown in the linked post the difference in filesize is negligable (on a 2 minute song there is a difference of 0.11MB).

peppy's reasoning for enforcing a 192kbps limit initially in the ranking criteria was: "Note that the bitrate rules are NOT for legal reasons as people may have incorrectly stated, but to ensure downloads size is within acceptable limits (especially important as we push forward with mobile platforms)."

This will change audio moderation during the ranking process as we can simply be concerned with finding the highest quality audio format and not have to compromise on .ogg quality due to a fundamentally flawed rule.

I am for this

But ogg seems to add a relatively significant overhead to the data...

Comparison of reports between vorbis (libvorbis), mp3 (lame) 192k and mp3 (lame) vbr3:

> ffprobe "M1LLI0N PP.flac"
Input #0, flac, from 'M1LLI0N PP.flac':
  Metadata: *omitted*
  Duration: 00:07:10.86, start: 0.000000, bitrate: 1263 kb/s
    Stream #0:0: Audio: flac, 44100 Hz, stereo, s16
    Stream #0:1: *album cover*
    Metadata:
      comment         : Cover (front)
> ffmpeg -i "M1LLI0N PP.flac" -q:a 6 -vn Mpp.ogg
> ffprobe Mpp.ogg
Input #0, ogg, from 'Mpp.ogg':
  Duration: 00:07:10.86, start: 0.000000, bitrate: 217 kb/s
    Stream #0:0: Audio: vorbis, 44100 Hz, stereo, fltp, 192 kb/s
    Metadata: *omitted*
> ffmpeg -i "M1LLI0N PP.flac" -b:a 192k -vn Mpp_cbr.ogg
> ffprobe Mpp_cbr.mp3
Input #0, mp3, from 'Mpp_cbr.mp3':
  Metadata: *omitted*
  Duration: 00:07:10.92, start: 0.025057, bitrate: 192 kb/s
    Stream #0:0: Audio: mp3, 44100 Hz, stereo, fltp, 192 kb/s
    Metadata:
      encoder         : Lavc58.91
> ffmpeg -i "M1LLI0N PP.flac" -q:a 3 -vn Mpp_vbr.mp3
> ffprobe Mpp_vbr.mp3
Input #0, mp3, from 'Mpp_vbr.mp3':
  Metadata: *omitted*
  Duration: 00:07:10.92, start: 0.025057, bitrate: 170 kb/s
    Stream #0:0: Audio: mp3, 44100 Hz, stereo, fltp, 170 kb/s
    Metadata:
      encoder         : Lavc58.91

Filesize (in bytes):

PS> ls
-a---           5/15/2021 11:10 AM       10342846 Mpp_cbr.mp3
-a---           5/15/2021 11:10 AM        9197181 Mpp_vbr.mp3
-a---           5/15/2021  9:00 AM       11737176 Mpp.ogg

Hi,

The whole point of this proposal is to stop using bitrate to judge files and instead look at filesize so perhaps the info on filesize of comparing a 192kbps mp3 to a VBR6 ogg file would be more appropriate here from your end?

Pasted filesize information.

An about 1.5MB increase in filesize for audio of that length is no way significant compared to the the about 1.6 increase caused by 320kbps I suppose?

Hi, this proposal was already discussed some months ago. In hope to help people have a greater view of the subject and don’t repeat the same discussion, i’ll link the old discussion. I also hope it will help this discussion.

community/forums/topics/1123516?start=7762828

Moving this to archived as there is already a thread for the topic as Shoenen mentioned. Besides this, their comes quite some extra technicality if you want to support VBR6 (as the kbps can be ~192-224 somewhere in this range).

The hard cap of 192kbps will most likely not change any time soon as Peppy already said this was for file size purposes.