Skip to main content

Notice

Please note that most of the software linked on this forum is likely to be safe to use. If you are unsure, feel free to ask in the relevant topics, or send a private message to an administrator or moderator. To help curb the problems of false positives, or in the event that you do find actual malware, you can contribute through the article linked here.
Topic: Opus encoder with "q" setting? (Read 7699 times) previous topic - next topic
0 Members and 1 Guest are viewing this topic.

Opus encoder with "q" setting?

Well, title pretty much says it all.
Is there any such encoder or plans for it?
I was surprised opusenc doesn't have it, since vorbis had it even in the RC releases.

Opus encoder with "q" setting?

Reply #1
A while ago on the IRC:
Quote
[11 nov 12 00:53:15] * Nekit1234007 * When you guys will start working on “-q” based encoding?

[11 nov 12 01:22:07] * jmspeex * Nekit1234007: Here you go:
[11 nov 12 01:22:10] * jmspeex * #!/bin/sh
[11 nov 12 01:22:10] * jmspeex * opts=`echo $* | perl -ne 'if (/(.*)-q ([0-9]+)(.*)/) {print $1, " --bitrate ", $2*16, $3} else {print $_}'`
[11 nov 12 01:22:13] * jmspeex * opusenc $opts
[11 nov 12 01:22:21] * jmspeex * Now you have a "-q" based encoder

[11 nov 12 02:04:06] * Nekit1234007 * jmspeex, Vorbis doing it the same way? I doubt.
[11 nov 12 02:04:44] * jmspeex * Nekit1234007: Yes, that is what Vorbis does
[11 nov 12 02:05:03] * jmspeex * (+/- the fundamental differences between the Vorbis and Opus bit-streams)

Opus encoder with "q" setting?

Reply #2
hah, a shellscript. I can tell it's a shell script, but I don't know enough to tell what that does, plus I'm on windoze and use foobar2000 as my main encoding frontend.
I wonder if this is intended as a temporal solution or a way of saying there will never be a q setting xD.

Anyway, does this mean you can craft a "q" of sorts through commandline? I ask because, even if I can't decode that perl code, I can tell it's just generating an arguments string for opusenc, so what's it doing anyway?

Opus encoder with "q" setting?

Reply #3
hah, a shellscript. I can tell it's a shell script, but I don't know enough to tell what that does, plus I'm on windoze and use foobar2000 as my main encoding frontend.
I wonder if this is intended as a temporal solution or a way of saying there will never be a q setting xD.

Anyway, does this mean you can craft a "q" of sorts through commandline? I ask because, even if I can't decode that perl code, I can tell it's just generating an arguments string for opusenc, so what's it doing anyway?


EDIT: I think I understand it a bit better now. If it has the -q setting it will print out all the previous parameters + will calculate the bitrate q [0-9.999 ect] * 16 (starts at 0 and ends at 144, increases by 16 every integer, it appears to me), otherwise it will just print the previous parameters to the encoder.

EDIT2: I'm not sure what the "+" does but I think it increases the q by 1, i.e. if the user input -q 0, then it would really be -q 1.
So that would mean it would start at 16kbs since 0 would encode it at 96kbs. Well technically it could go from 16-175.998 kbs since it would be (9.999+1) * 16...

Opus encoder with "q" setting?

Reply #4
Basically i tells you that the opus encoder works in quality (-q) mode already if you use the --bitrate command and vbr.

The shell script just translates the arbitrary q value to the --bitrate command and starts the normal encoder. So using the bitrate value is just a general guess  of the developer what the bitrate result could be and the whole process is full vbr.

Opus encoder with "q" setting?

Reply #5
Well, this is just user perception, but I thought the "quality" settings in modern codecs (wether it is audio or video) was an attempt to achieve a certain level of perceptual transparency where the actual bitrate is dependent on the variable complexity of the input without much constraint. Of course this results in a file where bitrate is variable, but from what I can grasp, a bitrate setting within a VBR "constraint" tries to sort of match the given bitrate as average instead of a given level of transparency, which is what I always thought vorbis did... So if you tell it to average to +/-96kbit it will depend on the complexity of the input how much perceptual quality the encoder can squeeze out of that given bitrate averaged, right?

What I always understood as a "q" setting is, in resume, a -more or less accurate- gauge of perceptual transparency, and the encoder is in charge of deciding just how much bitrate it needs to achieve it. but perhaps I was wrong...

Opus encoder with "q" setting?

Reply #6
Well, this is just user perception, but I thought the "quality" settings in modern codecs (wether it is audio or video) was an attempt to achieve a certain level of perceptual transparency where the actual bitrate is dependent on the variable complexity of the input without much constraint. Of course this results in a file where bitrate is variable, but from what I can grasp, a bitrate setting within a VBR "constraint" tries to sort of match the given bitrate as average instead of a given level of transparency, which is what I always thought vorbis did... So if you tell it to average to +/-96kbit it will depend on the complexity of the input how much perceptual quality the encoder can squeeze out of that given bitrate averaged, right?
No.  In unmanaged VBR mode setting bitrate and quality are the same— there is just an equivalence between the two.  The meaning of bitrate in a true VBR context is effectively "If I encode a large and diverse collection of audio with target quality X the average bitrate will be ~Y".  But this is all open-loop calibration, it's really targeting quality.  So if your large collection is all death metal or whatever, then you may come out with a rate which is quite different than the requested one.

Same deal in Opus (esp with the exp encoder).  It's just that we've skipped including a quality knob and just internalized the indirection with rate.  The problem I've found with quality is that it creates a lot of confusion— one of the most common questions I see for Vorbis is "what rate is quality X on average"— and then there would be issues like  "Opus quality 0 sounds much worse than Vorbis quality 0!" if the quality were scaled to avoid the negative values and reflect the lower common operating rates for opus, or if it wasn't scaled "I picked quality 1 and the opus file sounded no better!".  There is just a lot of potential for confusion for objectively no gain.


Opus encoder with "q" setting?

Reply #7
Well, this is just user perception, but I thought the "quality" settings in modern codecs (wether it is audio or video) was an attempt to achieve a certain level of perceptual transparency where the actual bitrate is dependent on the variable complexity of the input without much constraint.


Correct.

Quote
Of course this results in a file where bitrate is variable, but from what I can grasp, a bitrate setting within a VBR "constraint" tries to sort of match the given bitrate as average instead of a given level of transparency, which is what I always thought vorbis did...


Not correct. Vorbis remaps the bitrate your select to a quality level that *probably* works out approximately to what you selected.

Quote
So if you tell it to average to +/-96kbit it will depend on the complexity of the input how much perceptual quality the encoder can squeeze out of that given bitrate averaged, right?


Not correct (for Vorbis and Opus). The real bitrate that your clip gets will change, not the quality.

Vorbis and Opus *can* enforce the bitrate rigidly if you so desire, but this requires extra settings (--managed in Vorbis, --cvbr or --cbr in Opus). By default they do *not* do this, and there is no guarantee you end up with the bitrate requested. But we know that,  over a large collection of music, it will work out to that on *average*.

Vorbis and Opus default to quality-based encoding (instead of enforcing the bitrate) because this is generally what you want anyway.