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

[added] [Proposal] Specify quality setting for ogg instead of bitrate

posted
Total Posts
57
sisig
680 posts
Joined August 2018
Topic Starter
sisig
Quoting the official FAQ for Vorbis
"This new scale of measurement [referring to q1 to q10] is not tied to a quantifiable characteristic of the stream, like bitrate, so it's a fairly subjective metric, but provides a more stable basis of comparison to other codecs and is relatively future-proof."

"For now, quality 0 is roughly equivalent to 64kbps average, 5 is roughly 160kbps, and 10 gives about 400kbps. Most people seeking very-near-CD-quality audio encode at a quality of 5 or, for lossless stereo coupling, 6."

The ranking criteria currently states the following:

The audio file of a beatmap must...
...use the .mp3 or .ogg file format.
...have an average bit rate no greater than 192 kbps.

This is somewhat problematic for .ogg as Vorbis uses a subjective metric (since bitrate isn't really the sole indicator of quality for Vorbis). It is also important to note the second quote, "For now, quality 0 is roughly equivalent to 64kbps average". This also means that q6 is not exactly 192kbps average. It basically means that instead of just encoding once with the q6 parameter, people would have to play around with the quality (like changing to q"5.99999") just so it satisfies the "no greater than 192kbps" rule.

From testing*, Ogg sometimes results in slightly higher or lower bitrates when encoding different songs.

*If anyone's interested, these were my results comparing 192 mp3, close to 192 ogg, and q6 ogg

My suggested change is:

The audio file of a beatmap must...
...use the .mp3 or .ogg file format.
...have an average bit rate no greater than 192 kbps if it's mp3.
...be encoded with no greater than the q6 parameter if it's ogg.

Not really sure if the post makes sense but tl;dr

Current rule makes it so q6 ogg (roughly equivalent to 192kbps) would sometimes be rankable or not as it honestly depends on your luck and what song it is. This is because quality in ogg is not tied to bitrate. What I'm proposing is to detach ogg from the arbitrary 192kbps rule that only makes sense for mp3 and specify q6 instead.

I also wanted to propose a rule that forces everyone to share what encoding settings/audio sources they used so audio modding can be obsoleted by people giving actual proof that they're actually exerting effort to use the best quality they can but I digress
Last edited by sisig , edited 1 time in total.
aceticke
Global Moderator
251 posts
Joined August 2016
aceticke
+1
-Flashlight-
Beatmap Nominator
548 posts
Joined February 2017
-Flashlight-
+1
Hivie
osu!taiko Paragon
1,002 posts
Joined March 2019
Hivie
yesplease yessssssssssssss

the amount of q6 oggs i had to downgrade because they were marked a couple bits above 192 is astonishing
Kyuunex
99 posts
Joined November 2016
Kyuunex
+1
lewski
1,346 posts
Joined September 2014
lewski
same as hivie
Ryax
Beatmap Nominator
189 posts
Joined September 2016
Ryax
+1 the era of the ogg q6 is upon us
Drum-Hitnormal
Beatmap Nominator
1,727 posts
Joined March 2011
Drum-Hitnormal
yes pls
change q6 to q5 is annoying. and q6 still smaller than 192 mp3 anyways. peppy dont refuse pls
Ryu Sei
2,900 posts
Joined October 2013
Ryu Sei
A Vorbis file mostly encoded with VBR and this proposal will definitely clear the ambiguity up.

The wording can be better though.
dopaminos
326 posts
Joined June 2015
dopaminos
i agree that q6 would be good to use instead of bitrate limit

but.. oggenc2.exe exists and if you can type commands in terminal, you can easily make ogg q5.9 or q6.9
Ryu Sei
2,900 posts
Joined October 2013
Ryu Sei

dopaminos wrote:

i agree that q6 would be good to use instead of bitrate limit

but.. oggenc2.exe exists and if you can type commands in terminal, you can easily make ogg q5.9 or q6.9
You should be able to look at the target bitrate using tools such as mediainfo to make sure it's targetted to 192 kbps.
Here's how it looks from a file:
Quality 5.9
Audio
ID                          : 1602532132 (0x5F84B324)
Format                      : Vorbis
Format settings, Floor      : 1
Duration                    : 2 min 37 s
Bit rate mode               : Variable
Bit rate                    : 189 kb/s
Channel(s)                  : 2 channels
Sampling rate               : 48.0 kHz
Compression mode            : Lossy
Stream size                 : 3.55 MiB (85%)
Writing library             : libVorbis (Reducing Environment) (20200704 (Reducing Environment))
Quality 6
Audio
ID                          : 1872549022 (0x6F9CD49E)
Format                      : Vorbis
Format settings, Floor      : 1
Duration                    : 2 min 37 s
Bit rate mode               : Variable
Bit rate                    : 192 kb/s
Channel(s)                  : 2 channels
Sampling rate               : 48.0 kHz
Compression mode            : Lossy
Stream size                 : 3.61 MiB (82%)
Writing library             : libVorbis (Reducing Environment) (20200704 (Reducing Environment))
Quality 6.9
Audio
ID                          : 1438203793 (0x55B93F91)
Format                      : Vorbis
Format settings, Floor      : 1
Duration                    : 2 min 37 s
Bit rate mode               : Variable
Bit rate                    : 221 kb/s
Channel(s)                  : 2 channels
Sampling rate               : 48.0 kHz
Compression mode            : Lossy
Stream size                 : 4.15 MiB (84%)
Writing library             : libVorbis (Reducing Environment) (20200704 (Reducing Environment))
I used AIMP to re-encode these files with specific quality value.
I don't see the potential issues with this proposal.
Last edited by Ryu Sei , edited 1 time in total.
defreeyay
191 posts
Joined March 2018
defreeyay
+1 !!!
Shad0wStar
Global Moderator
177 posts
Joined April 2020
Shad0wStar
+ 1 plspls

i love when q6 is 193kbps 💔💔
Last edited by Shad0wStar , edited 1 time in total.
FazlyMR_
13 posts
Joined December 2015
FazlyMR_
After reading what that has been said about it, I would give my +1 on this.

But there are several things that I would like to probably be considered, such as:
  1. Consider setting a standard encoder for a given quality value, since different encoders may have certain differences in how it compresses audio in the Vorbis format*.
  2. Consider ditching MP3 for future ranked beatmaps, due to Vorbis' ability to retain subjective quality better than MP3 at a given bitrate except if the original highest-quality audio available is only in MP3 and converting it to Vorbis would result in worse subjective quality.
  3. Consider setting a small margin of error for the lowest and highest bitrate limit, so cases such as average bitrates higher by 1 or 2 kilobits (such as 126kbps or 194kbps) would not be a problem.
* Personally, I have experienced quite different bitrates given by both the reference Vorbis encoder from Xiph.org and the forked auToV Vorbis encoder for a given quality value thus requiring me to reduce the quality value when encoding with the auToV encoder to match what the bitrate of the reference encoder.
Last edited by FazlyMR_ , edited 7 times in total.
MadBricktree
469 posts
Joined August 2014
MadBricktree
strongly agree
it is often way too much work than necessary to get the average bitrate just within rankable constraints as they can be very unpredictable due to the nature of VBR

though I do think a better approach to wording this would be to simply replace average bitrate with nominal bitrate
eg:
  1. ...have a nominal bit rate no greater than 192 kbps.
  2. ...have a nominal bit rate no lower than 128 kbps, if such a source exists. Otherwise, use the highest quality available.

This way all rankable formats (CBR/VBR mp3/vorbis) are covered without having to add an additional clause, while also accounting for nominal bitrates that are not preset quality levels (eg 180kbps nominal bitrate).
Last edited by MadBricktree , edited 4 times in total.
sisig
680 posts
Joined August 2018
Topic Starter
sisig

FazlyMR_ wrote:

After reading what that has been said about it, I would give my +1 on this.

But there are several things that I would like to probably be considered, such as:
  1. Consider setting a standard encoder for a given quality value, since different encoders may have certain differences in how it compresses audio in the Vorbis format*.
  2. Consider ditching MP3 for future ranked beatmaps, due to Vorbis' ability to retain subjective quality better than MP3 at a given bitrate except if the original highest-quality audio available is only in MP3 and converting it to Vorbis would result in worse subjective quality.
  3. Consider setting a small margin of error for the lowest and highest bitrate limit, so cases such as average bitrates higher by 1 or 2 kilobits (such as 126kbps or 194kbps) would not be a problem.
* Personally, I have experienced quite different bitrates given by both the reference Vorbis encoder from Xiph.org and the forked auToV Vorbis encoder for a given quality value thus requiring me to reduce the quality value when encoding with the auToV encoder to match what the bitrate of the reference encoder.
1. "The latest aoTuV beta6.03 was unified with Xiph.Org's libvorbis1.3.7" from aotuv website. I haven't really come across completely different encoders (like with mp3) so this is probably just added complexity.
2. Huge agree. Though I'm a bit troubled by people transcoding their mp3s to oggs (which is less than ideal). It's probably better to still allow mp3s
3. You can't really account for this since you can have for that ~2 kilobits of variance with q6. (In some cases, q6 might give you 220kbps+ or 111kbps)

MadBricktree wrote:

strongly agree
it is often way too much work than necessary to get the average bitrate just within rankable constraints as they can be very unpredictable due to the nature of VBR

though I do think a better approach to wording this would be to simply replace average bitrate with nominal bitrate
eg:
  1. ...have a nominal bit rate no greater than 192 kbps.
  2. ...have a nominal bit rate no lower than 128 kbps, if such a source exists. Otherwise, use the highest quality available.

This way all rankable formats (CBR/VBR mp3/vorbis) are covered without having to add an additional clause, while also accounting for nominal bitrates that are not preset quality levels (eg 180kbps nominal bitrate).
Nominal is such a tricky word to pin down though, at least compared to average.

From some forums:
"Nominal Bit Rate is = the max bit rate allowable by the encoding process. The bit rate does not have has to be achieved in the encoding process. It is only a max ceiling to ever allow"

"Nominal bitrate is usually the average bitrate for VBR, some programs use the term nominal to mean maximum. If you want a fixed file size use CBR."

"As adjectives the difference between nominal and average is that nominal is of, resembling, relating to, or consisting of a name or names while average is constituting or relating to the average."

Trying to include all formats into one catch-all seems to be making things too simple and would likely fail in most edge cases.

Also, if someone's gonna use VBR mp3 anyway, just use ogg LOL
Last edited by sisig , edited 1 time in total.
MadBricktree
469 posts
Joined August 2014
MadBricktree
The definition for nominal bitrate is pretty unambiguous, and I don't think there are any edge cases where using this term will fail. I do agree that vorbis is superior to mp3 for VBR, but mp3 VBR is rankable (for now) so it would make sense to account for it.
I would recommend referencing oggenc or ffmpeg documentation instead of forum posts as the former are far more reliable
see: https://linux.die.net/man/1/oggenc

However, if this is confusing, I think that the term "target bitrate" could be used in place of "nominal bitrate" as it is a bit more intuitive for the average user. It's not technically wrong to use it either as that's how the bitrate argument is described within oggenc.
Last edited by MadBricktree , edited 3 times in total.
FazlyMR_
13 posts
Joined December 2015
FazlyMR_

sisig wrote:

FazlyMR_ wrote:

After reading what that has been said about it, I would give my +1 on this.

But there are several things that I would like to probably be considered, such as:
  1. Consider setting a standard encoder for a given quality value, since different encoders may have certain differences in how it compresses audio in the Vorbis format*.
  2. Consider ditching MP3 for future ranked beatmaps, due to Vorbis' ability to retain subjective quality better than MP3 at a given bitrate except if the original highest-quality audio available is only in MP3 and converting it to Vorbis would result in worse subjective quality.
  3. Consider setting a small margin of error for the lowest and highest bitrate limit, so cases such as average bitrates higher by 1 or 2 kilobits (such as 126kbps or 194kbps) would not be a problem.
* Personally, I have experienced quite different bitrates given by both the reference Vorbis encoder from Xiph.org and the forked auToV Vorbis encoder for a given quality value thus requiring me to reduce the quality value when encoding with the auToV encoder to match what the bitrate of the reference encoder.
1. "The latest aoTuV beta6.03 was unified with Xiph.Org's libvorbis1.3.7" from aotuv website. I haven't really come across completely different encoders (like with mp3) so this is probably just added complexity.
2. Huge agree. Though I'm a bit troubled by people transcoding their mp3s to oggs (which is less than ideal). It's probably better to still allow mp3s
3. You can't really account for this since you can have for that ~2 kilobits of variance with q6. (In some cases, q6 might give you 220kbps+ or 111kbps)
To respond to your replies one-by-one:

  1. Thanks for the information. I didn't know that. But I think it's more about clarity but your concern on complexity is legit too.
  2. You're right on still allowing MP3s, but at least make it as a last resort if the highest quality source file is already in MP3 of a certain average bitrate, especially low-bitrate MP3. Transcoding to OGG Vorbis is not entirely problematic in itself, as it's only problematic when one transcodes low-bitrate source audio files to OGG Vorbis instead transcoding from a high-quality (high-bitrate lossy like 320kbps MP3s/AACs, or lossless) source.
  3. Hmm, ok then. I actually have nothing more to say about the margin of error issue.
Last edited by FazlyMR_ , edited 1 time in total.
Kyuunex
99 posts
Joined November 2016
Kyuunex
I should add, nominal bitrate is simply the bitrate the encoder was aiming to acomplish. Nominal bitrate is stored in the ogg header, instead of being calculated based on the size and length of the audio stream.

Headers can probably be hex edited too to fake a specific nominal bitrate. As a good rule of thumb, if it's over 224 kbps, it's very unlikely to be q6, so, BNs checking maps would have to make their own encodes and compare the results.
sisig
680 posts
Joined August 2018
Topic Starter
sisig

Kyuunex wrote:

I should add, nominal bitrate is simply the bitrate the encoder was aiming to acomplish. Nominal bitrate is stored in the ogg header, instead of being calculated based on the size and length of the audio stream.

Headers can probably be hex edited too to fake a specific nominal bitrate. As a good rule of thumb, if it's over 224 kbps, it's very unlikely to be q6, so, BNs checking maps would have to make their own encodes and compare the results.
I feel like any doubts about audio quality can be easily cleared up by mappers just giving their encoder settings and how they got audio instead of pasting a spectro in modding discussions. I think audio right now is entirely based on trust and the fact that mapper really did do their best to find the 'best' audio. I personally don't think there's any issue with youtube rips or whatever but if someone gives you objectively better audio I think you'd be obligated to change it (subjective no change is such a shit argument because it literally takes 5 minutes to change audio, with audio modders already doing the bulk of the work)
MadBricktree
469 posts
Joined August 2014
MadBricktree

Kyuunex wrote:

I should add, nominal bitrate is simply the bitrate the encoder was aiming to acomplish. Nominal bitrate is stored in the ogg header, instead of being calculated based on the size and length of the audio stream.

Headers can probably be hex edited too to fake a specific nominal bitrate. As a good rule of thumb, if it's over 224 kbps, it's very unlikely to be q6, so, BNs checking maps would have to make their own encodes and compare the results.
This is true and this is a genuine concern that should be addressed if this proposal is to pass, regardless of if it is to be worded with q6 or with nominal bitrate. There is a chance that someone will maliciously edit the header to input a wrong nominal bitrate and there is no way to verify this with 100% accuracy.

However, I do not think a lot of people will actually know how to do this, and even if they do, if the nominal bitrate used during encoding is significantly different from recorded nominal bitrate there will be a noticeable difference in average bitrate and file size like you mentioned. Considering this, I think the change will be a net positive.
AJT
551 posts
Joined August 2013
AJT
- agree w/ proposal
- wrt people masking way-higher qual as q6: MV can probably atone for this, anything significantly above 192kbps can be flagged which would encourage a check
Protastic101
1,170 posts
Joined July 2015
Protastic101
+1 to the original wording. @MBt, I think introducing nominal bitrate, as others have said, is likely to be more confusing and ambiguous to your average mapper. Clearly specifying the different guidelines to follow depending on file type is better for common understanding.
ikin5050
587 posts
Joined February 2014
ikin5050
community/forums/topics/1323277?n=1 was proposed 2 years ago where people mentioned this community/forums/topics/1123516?n=20 was proposed even before that

Greaper wrote:

Moving this to archived as there is already a thread for the topic. 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.

Just as overview to make sure people are aware of previous discussions that were conducted
Protastic101
1,170 posts
Joined July 2015
Protastic101
Correct me if I'm wrong as I've only heard this and don't have anything to solidly back it up, but isn't .ogg usually a smaller filesize than .mp3? So q6 .ogg would theoretically be of a similar or smaller filesize than a 192kbps .mp3, so the filesize argument seems kind of null.
sisig
680 posts
Joined August 2018
Topic Starter
sisig

Protastic101 wrote:

Correct me if I'm wrong as I've only heard this and don't have anything to solidly back it up, but isn't .ogg usually a smaller filesize than .mp3? So q6 .ogg would theoretically be of a similar or smaller filesize than a 192kbps .mp3, so the filesize argument seems kind of null.
not entirely correct. most of the time ogg is smaller (even with higher bitrates) since a entirely different psychoacoustic model and compression algorithm is use but yeah i agree that the filesize argument doesnt make sense


ikin5050 wrote:

community/forums/topics/1323277?n=1 was proposed 2 years ago where people mentioned this community/forums/topics/1123516?n=20 was proposed even before that

Greaper wrote:

Moving this to archived as there is already a thread for the topic. 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.

Just as overview to make sure people are aware of previous discussions that were conducted
id argue that the shoenen thread isnt entirely relevant as that still associated bitrate with ogg quality (imo you shouldve pushed back against greaper's decision to archive it as its kinda different)

also read some of the stuff there and the consensus seemed to be (at least to me) that there was no real way to check for quality

correct me if im wrong but faking bitrate (from lower to higher) already happens, with some people using the argument of "special encoding parameters" brought up in other modding discussions without providing their actual encoding settings. the only real way to check mp3 and ogg quality has always been to encode a lossless version yourself.

this proposal only aims to make ogg usage easier by getting rid of arbitrary number requirements and to just use a more or less equivalent encoding parameter which is q6 or vbr6 (in relation to mp3, but arguably q4 would probably be closest to 192 mp3 LOL)
Ryu Sei
2,900 posts
Joined October 2013
Ryu Sei
If there were an argument of people maliciously editing the .ogg header so it shows incorrect nominal bitrate, is it entirely possible to double check this by simply re-encoding the same file twice with the quality value targetted with the nominal bitrate? If the size difference is significant, we could conclude that it's bloated.
lewski
1,346 posts
Joined September 2014
lewski
definitely possible as long as you can find something to convert from, i.e. definitely doable as long as the mapper doesn't go "uhhh idk i just found this ogg haha i dont have a higher quality version of the song", although most songs are fairly easy to find even if the mapper doesn't cooperate
Ryu Sei
2,900 posts
Joined October 2013
Ryu Sei
Modifying nominal bitrate in malicious intent is entirely possible, but it's hard from what I experience. I don't see people will bother modifying it just to circumvent nominal bitrate rules. There should be a spectograph tool too to guess whether an audio is bloated, but that's kinda last resort.

(I don't want to give you any ideas, so search yourself how)
Monoseul
Elite Nominator
73 posts
Joined January 2020
Monoseul
+1
people who use q6 will be blown up by me with my mind just saying...
fubuki
116 posts
Joined July 2021
fubuki
+1
gzdongsheng
Nomination Assessment Team / Elite Nominator II
139 posts
Joined July 2016
gzdongsheng
+1
h3oCharles
1,503 posts
Joined July 2016
h3oCharles
Goofy Ahh X.9 quality

agree
Last edited by h3oCharles , edited 1 time in total.
hehe
1,971 posts
Joined November 2012
hehe
+1
[[[[[[
886 posts
Joined August 2019
[[[[[[
+1
Ephemeral
Inland Empire
3,946 posts
Joined April 2009
Ephemeral
This seems reasonable. Surprised we haven't actually formalized the q6 limitation anywhere beforehand.
AJT
551 posts
Joined August 2013
AJT
Should just be a matter of making a PR now?

  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 if .mp3, or Q6 if .ogg.
  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.

idk how to do sub-bullet points cus im inept
Last edited by AJT , edited 11 times in total.
Kyuunex
99 posts
Joined November 2016
Kyuunex
Better way to word it:

  1. ...have an average bit rate no greater than 192 kbps if .mp3.
  2. ...be encoded with a quality preset no greater than q6 if .ogg.
sisig
680 posts
Joined August 2018
Topic Starter
sisig

Kyuunex wrote:

Better way to word it:

  1. ...have an average bit rate no greater than 192 kbps if .mp3.
  2. ...be encoded with a quality preset no greater than q6 if .ogg.
this wording seems neater
Kyuunex
99 posts
Joined November 2016
Kyuunex
One other thing to mention, the ogg encoder has advanced encode options. "These are intended for very advanced users only, and should be approached with caution.".

To the best of my understanding, a quality preset is simply a set of advanced encode options.

Perhaps we could restrict the use of advanced encode options unless the mapper knows what they are doing and if it would benefit the song, and in that case, limit to 192 kbps.

Here's the manual for the oggenc encoder https://man.archlinux.org/man/oggenc.1.en

Let me correct my previous message:

  1. ...have an average bit rate no greater than 192 kbps if .mp3 or when using advanced encoding options with .ogg.
  2. ...be encoded with a quality preset no greater than q6 if .ogg if using a quality preset.
Still the wording does feel kinda off.

EDIT: also, some encoders may use different presets that lead to a different bitrate, perhaps we could standardize on the encoder used?
Last edited by Kyuunex , edited 3 times in total.
sisig
680 posts
Joined August 2018
Topic Starter
sisig

Kyuunex wrote:

One other thing to mention, the ogg encoder has advanced encode options. "These are intended for very advanced users only, and should be approached with caution.".

To the best of my understanding, a quality preset is simply a set of advanced encode options.

Perhaps we could restrict the use of advanced encode options unless the mapper knows what they are doing and if it would benefit the song, and in that case, limit to 192 kbps.

Here's the manual for the oggenc encoder https://man.archlinux.org/man/oggenc.1.en

Let me correct my previous message:

  1. ...have an average bit rate no greater than 192 kbps if .mp3 or when using advanced encoding options with .ogg.
  2. ...be encoded with a quality preset no greater than q6 if .ogg if using a quality preset.
Still the wording does feel kinda off.

EDIT: also, some encoders may use different presets that lead to a different bitrate, perhaps we could standardize on the encoder used?
From what I understood from digging up the source code, the quality parameter is directly correlated with a psychoacoustic model made specifically for that quality. So most likely would not differ from encoder to encoder.

This took me so long to find

If we're looking to standardize though, libvorbis1.3.7 should be it. aoTuV which is pretty much the best encoder out there (according to forums and stuff, i think they did blind tests too?) is already merged with 1.3.7 + its also pretty much official as official encoders get
Ryu Sei
2,900 posts
Joined October 2013
Ryu Sei
Do note that some encoders like what FL Studio use only shows nominal bitrate instead of quality preset. I haven't checked yet if it's CBR or VBR...

EDIT: FL Studio honors VBR encoding of Vorbis. It just not shown as quality preset.
Last edited by Ryu Sei , edited 1 time in total.
AnimeStyle
653 posts
Joined December 2012
AnimeStyle
+1 Can someone finalize what AJT posted how he wanted it to be, thx xoxo
Hivie
osu!taiko Paragon
1,002 posts
Joined March 2019
Hivie
Proposal is currently being sanity-checked internally and may be PR'd soon
YuEast 2018
463 posts
Joined February 2019
YuEast 2018
very good idea.
but i wonder would there be situations that using q6 ogg but bitrate smaller than 192k? then which rule should apply? can i slightly increase the q to reach nearer to 192k?
Last edited by YuEast 2018 , edited 1 time in total.
Ryu Sei
2,900 posts
Joined October 2013
Ryu Sei

YuEast 2018 wrote:

very good idea.
but i wonder would there be situations that using q6 ogg but bitrate smaller than 192k? then which rule should apply? can i slightly increase the q to reach nearer to 192k?
OGG Vorbis and MP3 should use its own respective settings, and cannot be mixed. MP3 uses average bitrate (if it's constant, then the average is same either way), and Vorbis uses quality preset (it's usually represented with the nominal/target bitrate).

This way, even if the average bitrate of a Vorbis is beyond 192K, it doesn't honor MP3 rules because OGG Vorbis is not MP3. We should only look at its nominal/target bitrate given by tools such as Mediainfo or Spek.

As I mentioned earlier, it's possible to "fake" nominal bitrate, but incredibly difficult. It's a net profit anyway since Vorbis doesn't suffer from desync issue than MP3 (though it's a non-issue in lazer, it's just simply superior).
YuEast 2018
463 posts
Joined February 2019
YuEast 2018

Ryu Sei wrote:

YuEast 2018 wrote:

very good idea.
but i wonder would there be situations that using q6 ogg but bitrate smaller than 192k? then which rule should apply? can i slightly increase the q to reach nearer to 192k?
OGG Vorbis and MP3 should use its own respective settings, and cannot be mixed. MP3 uses average bitrate (if it's constant, then the average is same either way), and Vorbis uses quality preset (it's usually represented with the nominal/target bitrate).

This way, even if the average bitrate of a Vorbis is beyond 192K, it doesn't honor MP3 rules because OGG Vorbis is not MP3. We should only look at its nominal/target bitrate given by tools such as Mediainfo or Spek.

As I mentioned earlier, it's possible to "fake" nominal bitrate, but incredibly difficult. It's a net profit anyway since Vorbis doesn't suffer from desync issue than MP3 (though it's a non-issue in lazer, it's just simply superior).
true we allow situation of ogg q6 but over 192, it's a benefit. but i think you missed my point. mine goes for the situation like q6.1 191k in some of the song audio (it can happen), why not a higher quality if file size allows it?
although this can be extremely slight about the difference between stuffs like q6 and q6.1
Last edited by YuEast 2018 , edited 1 time in total.
Ryu Sei
2,900 posts
Joined October 2013
Ryu Sei
I think it's a good trade between quality and file size. Besides, to mirror it with our current RC, it's just logical and easier if we use the current MP3 bitrate values to the equivalent of OGG nominal bitrate, right?
sisig
680 posts
Joined August 2018
Topic Starter
sisig

YuEast 2018 wrote:

very good idea.
but i wonder would there be situations that using q6 ogg but bitrate smaller than 192k? then which rule should apply? can i slightly increase the q to reach nearer to 192k?
the entire point of the proposal is to avoid things like this which makes things more complicated. the amount of improvement given by pushing 191.1kbps to 192~kbps is too small to even be perceived. quality for ogg is not tied to bitrate as it is in mp3 (supposedly), q6 is a sort of subjective metric for "cd quality-ish audio" and differs from audio to audio
lewski
1,346 posts
Joined September 2014
lewski

sisig wrote:

the amount of improvement given by pushing 191.1kbps to 192~kbps is too small to even be perceived. quality for ogg is not tied to bitrate as it is in mp3 (supposedly), q6 is a sort of subjective metric for "cd quality-ish audio" and differs from audio to audio
yeah, for what it's worth any song that's quiet/whatever enough to be significantly under 192kbps (think 170s or low 180s) at q6 is gonna be good enough at that setting to sound identical to even q7 to my admittedly non-audiophile ears
show more
Please sign in to reply.

New reply

0
1 / 57