IPB

Welcome Guest ( Log In | Register )

Opus encoder with "q" setting?
radorn
post Dec 15 2012, 01:13
Post #1





Group: Members
Posts: 52
Joined: 12-May 04
Member No.: 14052



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.
Go to the top of the page
+Quote Post
 
Start new topic
Replies (1 - 7)
Nekit1234007
post Dec 15 2012, 01:57
Post #2





Group: Members
Posts: 12
Joined: 26-February 12
Member No.: 97404



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)
Go to the top of the page
+Quote Post
radorn
post Dec 15 2012, 03:45
Post #3





Group: Members
Posts: 52
Joined: 12-May 04
Member No.: 14052



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?

This post has been edited by radorn: Dec 15 2012, 03:45
Go to the top of the page
+Quote Post
Seren
post Dec 15 2012, 14:25
Post #4





Group: Members
Posts: 54
Joined: 1-November 12
Member No.: 104244



QUOTE (radorn @ Dec 15 2012, 10:45) *
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...

This post has been edited by Seren: Dec 15 2012, 14:50
Go to the top of the page
+Quote Post
Rumbah
post Dec 15 2012, 15:23
Post #5





Group: Members
Posts: 2
Joined: 17-May 09
Member No.: 69894



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.
Go to the top of the page
+Quote Post
radorn
post Dec 16 2012, 01:03
Post #6





Group: Members
Posts: 52
Joined: 12-May 04
Member No.: 14052



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

This post has been edited by radorn: Dec 16 2012, 01:06
Go to the top of the page
+Quote Post
NullC
post Dec 18 2012, 16:16
Post #7





Group: Developer
Posts: 200
Joined: 8-July 03
Member No.: 7653



QUOTE (radorn @ Dec 15 2012, 16:03) *
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.

Go to the top of the page
+Quote Post
Garf
post Dec 18 2012, 16:59
Post #8


Server Admin


Group: Admin
Posts: 4885
Joined: 24-September 01
Member No.: 13



QUOTE (radorn @ Dec 16 2012, 01:03) *
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.
Go to the top of the page
+Quote Post

Reply to this topicStart new topic
1 User(s) are reading this topic (1 Guests and 0 Anonymous Users)
0 Members:

 



RSS Lo-Fi Version Time is now: 22nd September 2014 - 09:15