+1 the era of the ogg q6 is upon us
forum
[added] [Proposal] Specify quality setting for ogg instead of bitrate
posted
Total Posts
57
yes pls
change q6 to q5 is annoying. and q6 still smaller than 192 mp3 anyways. peppy dont refuse pls
change q6 to q5 is annoying. and q6 still smaller than 192 mp3 anyways. peppy dont refuse pls
A Vorbis file mostly encoded with VBR and this proposal will definitely clear the ambiguity up.
The wording can be better though.
The wording can be better though.
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
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.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
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
I used AIMP to re-encode these files with specific quality value.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 don't see the potential issues with this proposal.
+ 1 plspls
i love when q6 is 193kbps 💔💔
i love when q6 is 193kbps 💔💔
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:
But there are several things that I would like to probably be considered, such as:
- 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*.
- 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.
- 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.
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:
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).
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:
- ...have a nominal bit rate no greater than 192 kbps.
- ...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).
Topic Starter
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.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:* 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.
- 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*.
- 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.
- 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.
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)
Nominal is such a tricky word to pin down though, at least compared to average.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:
- ...have a nominal bit rate no greater than 192 kbps.
- ...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).
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
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.
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.
To respond to your replies one-by-one:sisig wrote:
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.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:* 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.
- 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*.
- 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.
- 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.
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)
- 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.
- 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.
- Hmm, ok then. I actually have nothing more to say about the margin of error issue.
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.
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.
Topic Starter
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)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.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.
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.
- 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
- 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
+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.
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
Just as overview to make sure people are aware of previous discussions that were conducted
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
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.
Topic Starter
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 senseProtastic101 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.
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)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 thatGreaper 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
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)
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.
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
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)
(I don't want to give you any ideas, so search yourself how)
+1
people who use q6 will be blown up by me with my mind just saying...
people who use q6 will be blown up by me with my mind just saying...
+1
Goofy Ahh X.9 quality
agree
agree
+1
This seems reasonable. Surprised we haven't actually formalized the q6 limitation anywhere beforehand.
Should just be a matter of making a PR now?
idk how to do sub-bullet points cus im inept
- 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 .mp3, or Q6 if .ogg.
- ...have an average bit rate no lower than 128 kbps, if such a source exists. Otherwise, use the highest quality available.
- ...not be encoded upwards from a lower bitrate.
idk how to do sub-bullet points cus im inept
Better way to word it:
- ...have an average bit rate no greater than 192 kbps if .mp3.
- ...be encoded with a quality preset no greater than q6 if .ogg.
Topic Starter
this wording seems neaterKyuunex wrote:
Better way to word it:
- ...have an average bit rate no greater than 192 kbps if .mp3.
- ...be encoded with a quality preset no greater than q6 if .ogg.
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:
EDIT: also, some encoders may use different presets that lead to a different bitrate, perhaps we could standardize on the encoder used?
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:
- ...have an average bit rate no greater than 192 kbps if .mp3 or when using advanced encoding options with .ogg.
- ...be encoded with a quality preset no greater than q6 if .ogg if using a quality preset.
EDIT: also, some encoders may use different presets that lead to a different bitrate, perhaps we could standardize on the encoder used?
Topic Starter
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.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:Still the wording does feel kinda off.
- ...have an average bit rate no greater than 192 kbps if .mp3 or when using advanced encoding options with .ogg.
- ...be encoded with a quality preset no greater than q6 if .ogg if using a quality preset.
EDIT: also, some encoders may use different presets that lead to a different bitrate, perhaps we could standardize on the encoder used?
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
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.
EDIT: FL Studio honors VBR encoding of Vorbis. It just not shown as quality preset.
+1 Can someone finalize what AJT posted how he wanted it to be, thx xoxo
Proposal is currently being sanity-checked internally and may be PR'd soon
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?
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).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?
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?Ryu Sei wrote:
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).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?
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).
although this can be extremely slight about the difference between stuffs like q6 and q6.1
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?
Topic Starter
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 audioYuEast 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?
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 earssisig 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
on the issue of doing q6.1 when q6 goes under 192 kbps, I am unsure how fractional presets work. My assumption is they just further tune the preset, so, q5.9 is just q5 preset with some adjustments to use up more data, while q6 is another preset and makes use of the available data budget differently, even if they would end up very similar in size. So, based on my assumption, I think doing q6.1 when under 192 kbps is unnesasary.
Still unsure but we would need a more in-depth look at the source code for a more clear answer.
Still unsure but we would need a more in-depth look at the source code for a more clear answer.
to not keep everyone in the dark: we're discussing internally about allowing up to 208kbps nominal (since this is reportedly the upper bounds of what ogg q6 will go bitrate-wise) on ogg tracks only, with extra provisions added to ensure that ogg files do not also contain video or album art metadata (since they can do this).
this should negate the need for people to use third party tools (as windows properties would be sufficient to pick up the bitrate listed above) to check for this and also keeps it simple. detecting basic q6 is not a trivial (or a solved) task, so we're probably going to have to lean on something "good enough" here instead
this should negate the need for people to use third party tools (as windows properties would be sufficient to pick up the bitrate listed above) to check for this and also keeps it simple. detecting basic q6 is not a trivial (or a solved) task, so we're probably going to have to lean on something "good enough" here instead
let's not get terminology mixed. nominal is simply the bitrate the encoder is trying to accomplish, which should always be 192 kbps.
also, 208 is not the upper bounds for q6. i have a q6 ogg with 222.632449 kbps for example
also i would like to share the bitrates of last 50+ q6 oggs i have made over the last 2 years
most of these are encoded with audacity, only recently i started using oggenc directly
also, 208 is not the upper bounds for q6. i have a q6 ogg with 222.632449 kbps for example
ogginfo
$ ogginfo 1.01.\ Headhunter\ \(V2.0\).ogg
Processing file "1.01. Headhunter (V2.0).ogg"...
New logical stream (#1, serial: 05173f93): type vorbis
Vorbis headers parsed for stream 1, information follows...
Version: 0
Vendor: Xiph.Org libVorbis I 20200704 (Reducing Environment)
Channels: 2
Rate: 44100
Nominal bitrate: 192.000000 kb/s
Upper bitrate not set
Lower bitrate not set
User comments section follows...
ARTIST=Front 242
TITLE=Headhunter (V2.0)
DISCOGS_RELEASED=1988
TRACKNUMBER=01/4
Band=Front 242
STYLE=Industrial
Part of a set=1/1
DISCOGS_VOTES=16
DISCOGS_RATING=4.31
ALBUM=Headhunter (WAX CDV 053)
GENRE=Electronic
DISCOGS_LABEL_ID=953
DISCOGS_ARTIST_ID=4655
DISCOGS_CATALOG=WAX CDV 053
DATE=1988
DISCOGS_RELEASE_ID=1466330
DISCOGS_COUNTRY=US
DISCOGS_MASTER_RELEASE_ID=25203
DISCOGS_LABEL=Wax Trax! Records
Vorbis stream 1:
Total data length: 5369889 bytes
Playback length: 3m:12.959s
Average bitrate: 222.632449 kb/s
Logical stream 1 ended
$ also i would like to share the bitrates of last 50+ q6 oggs i have made over the last 2 years
most of these are encoded with audacity, only recently i started using oggenc directly
here you go
$ ogginfo *.ogg | grep "Average bitrate"
Average bitrate: 197.392729 kb/s
Average bitrate: 180.220228 kb/s
Average bitrate: 192.950073 kb/s
Average bitrate: 174.502402 kb/s
Average bitrate: 196.152223 kb/s
Average bitrate: 173.812092 kb/s
Average bitrate: 193.673712 kb/s
Average bitrate: 176.858084 kb/s
Average bitrate: 207.504557 kb/s
Average bitrate: 186.560651 kb/s
Average bitrate: 179.931218 kb/s
Average bitrate: 193.895712 kb/s
Average bitrate: 188.491357 kb/s
Average bitrate: 180.570427 kb/s
Average bitrate: 179.582664 kb/s
Average bitrate: 192.333671 kb/s
Average bitrate: 180.164604 kb/s
Average bitrate: 177.743996 kb/s
Average bitrate: 200.314585 kb/s
Average bitrate: 187.173836 kb/s
Average bitrate: 201.842008 kb/s
Average bitrate: 201.506415 kb/s
Average bitrate: 199.169113 kb/s
Average bitrate: 181.397192 kb/s
Average bitrate: 208.055042 kb/s
Average bitrate: 175.153821 kb/s
Average bitrate: 209.057230 kb/s
Average bitrate: 205.186814 kb/s
Average bitrate: 222.632449 kb/s
Average bitrate: 212.488544 kb/s
Average bitrate: 184.025038 kb/s
Average bitrate: 198.302556 kb/s
Average bitrate: 177.918441 kb/s
Average bitrate: 188.567693 kb/s
Average bitrate: 207.795620 kb/s
Average bitrate: 213.135834 kb/s
Average bitrate: 188.560423 kb/s
Average bitrate: 189.686174 kb/s
Average bitrate: 217.382349 kb/s
Average bitrate: 194.471645 kb/s
Average bitrate: 195.119720 kb/s
Average bitrate: 192.209035 kb/s
Average bitrate: 183.735931 kb/s
Average bitrate: 193.348265 kb/s
Average bitrate: 200.646282 kb/s
Average bitrate: 176.654272 kb/s
Average bitrate: 187.063315 kb/s
Average bitrate: 186.881334 kb/s
Average bitrate: 184.294724 kb/s
Average bitrate: 182.004837 kb/s
Average bitrate: 179.425439 kb/s
Average bitrate: 180.896773 kb/s
Average bitrate: 214.721070 kb/s
Average bitrate: 179.454790 kb/s
Average bitrate: 189.680735 kb/s
Average bitrate: 191.038322 kb/s
Average bitrate: 200.334648 kb/s
Average bitrate: 201.197887 kb/s
$ Detecting a nominal bitrate for an OGG is almost too difficult without external tools (at least a media player). Using the table of quality-to-nominal bitrate values and third-party tools like Spek or VLC, we can immediately able to check the nominal bitrate of the audio.Ephemeral wrote:
this should negate the need for people to use third party tools (as windows properties would be sufficient to pick up the bitrate listed above) to check for this and also keeps it simple. detecting basic q6 is not a trivial (or a solved) task, so we're probably going to have to lean on something "good enough" here instead
Of course, the average bitrate in practice might be above or beyond the nominal bitrate. And that should be fine.
If you convert from a lossless format (actual lossless, not simply reencoded to lossless) to OGG Vorbis, the spectrum shown in Spek should be very similar with almost no visible cutoffs at all (it will be more obvious on q4). The most common cutoffs seen in Spek are the characteristics of MP3.
still not a fan of simply raising it to 208. as I mentioned in my previous post, it can go up to 224.Hivie wrote:
https://github.com/ppy/osu-wiki/pull/9266
also we do have tools that tell you what settings it was encoded with, `ogginfo`. nominal bitrate is stored in the ogg header and is exactly what the bitrate the encoder was trying to acomplish and is directly related to the q preset.
have a look at this table https://en.wikipedia.org/wiki/Vorbis#Technical_details
is merged
re: above, refer to my answer to kyuunex here https://github.com/ppy/osu-wiki/pull/9266#issuecomment-1534341374
re: above, refer to my answer to kyuunex here https://github.com/ppy/osu-wiki/pull/9266#issuecomment-1534341374