What features would you like to see in opus-tools? Options

[NullC]

If people get accustomed to Opus quality in stereo mode (but maybe mono for speech) maybe a stereo-equivalent bitrate switch would suffice for surround (amounting to constant quality regardless of channel count).

We've at least talked about making it 'full-band stereo quality equivalent'. The downside would be when you ask for 24kbit/sec mono for speech (which sounds pretty good) and end up getting 8kbit/sec which does not sound so great.

Well, it doesn't look to me that it's quality based. For me, "quality based" would mean that the minimum quality setting giving a transparent encode is more or less the same for all files. That doesn't seem to be the case with Opus.

That can only be true with a "perfect" lossy encoder— it's not true for any existing one. If you're aware of bit discrepancies in libopus 1.1a they'd be interesting to know about.

Where do I report these?

Make a post in this subforum, "Samples which aren't transparent at 160kbps with 1.1a" or something like that.


This post has been edited by NullC: Feb 4 2013, 20:02

[moosehunter]

There are a few things that I'd like to see. In opusenc, an option to force SILK or CELT. Goldwave already does this, and when I encode a 24kbps with SILK in Goldwave, it sounds much better than the opusenc file. This changes when you get down to 16kbps.

Going along with the voice/music detection in the 1.1-alpha, I don't know if it would be feasible, but it would be nice to dynamically scale the bitrate between detected music and voice portions of a clip with user specified bitrates for each, where the user might choose to set a bitrate of, say, 24kbps for voice, and a higher bitrate of 128 kbps for music.

And in opusinfo, a printout or graph of the bitrate vs time in the file, or maybe just a printout of the bitrate each frame, or the average bitrate at a user specified interval, so you could get a listing of the average bitrate every second, or whatever the user might specify. This might be useful for analyzing how your audio is being encoded.

[NullC]

There are a few things that I'd like to see. In opusenc, an option to force SILK or CELT. Goldwave already does this, and when I encode a 24kbps with SILK in Goldwave, it sounds much better than the opusenc file. This changes when you get down to 16kbps.

The codec doesn't really expose a way to "force SILK" ... that whole thinking of "force silk or celt" is usually the wrong way to think about the codec.... What about hybrid? Opus is not two distinct codecs with a big switch between them. Unfortunately, I don't have a clue of what goldwave is actually doing. — It would be nice to know.

Going along with the voice/music detection in the 1.1-alpha, I don't know if it would be feasible, but it would be nice to dynamically scale the bitrate between detected music and voice portions of a clip with user specified bitrates for each, where the user might choose to set a bitrate of, say, 24kbps for voice, and a higher bitrate of 128 kbps for music.

The detection is not that accurate, so that might produce pretty irritating results... sounds worth trying though.

And in opusinfo, a printout or graph of the bitrate vs time in the file, or maybe just a printout of the bitrate each frame, or the average bitrate at a user specified interval, so you could get a listing of the average bitrate every second, or whatever the user might specify. This might be useful for analyzing how your audio is being encoded.

Use the --save-range option to opusdec.

[jensend]

Wrote much of this almost a week ago; realized I still had the unfinished reply sitting around, and though it's late it still seemed worth saying.

There are a few things that I'd like to see. In opusenc, an option to force SILK or CELT. Goldwave already does this, and when I encode a 24kbps with SILK in Goldwave, it sounds much better than the opusenc file. This changes when you get down to 16kbps.

I find it somewhat odd that you're getting better results by forcing SILK-only at those rates; it'd normally be using hybrid. Once you get down to 16kbps it'll usually be doing SILK-only even if you don't force it. Have you looked at the output bandwidth and verified that it's only wideband? ABC/HR type blind test data confirming your preference for forced SILK would be interesting.

The mode decisions in the present encoder are fairly reasonable and will continue to be refined; thus I don't think forcing a mode is usually going to be beneficial. Also, the developers are understandably reluctant to give people options that either give them a false sense of control or allow them to shoot themselves in the foot. Nevertheless, I do want to echo the request for ways to constrain the encoder's mode and bandwidth decisions with opusenc, because I do think there are legitimate use cases. For instance, for playback on very constrained devices (e.g. many Rockbox targets), it'd be nice to be able to restrict the encoder for performance and/or battery life reasons.

With the 1.0.x encoder you could just choose a bitrate which would reliably give you the mode and bandwidth you wanted, but the adaptability of the master branch eliminates that predictability.

Another use case: I have speech recordings where the master branch encoder encodes them as fullband or keeps switching between FB and SWB but the content above 12kHz seems unhelpful. Some consonants, applause, and some noises (like dropping stuff on the podium) have appreciable HF content, but I think they're adequately represented by their energy below 12kHz. There are some noises in a few recordings- like background silverware- that are audibly affected by a 12kHz cutoff, but that's actually an improvement, since the noise is made slightly less distracting. Outside of that I don't know that I can even ABX 12kHz lowpassed versions of this material. I'd rather have those bits go to lower frequencies, and though the FB<->SWB transitions often aren't audible I think there's more danger of such transitions being audible than there is of the >12kHz content being missed. I think this situation is pretty common for speech, and while I could of course pass the encoder versions that I've lowpassed or resampled myself, it would be convenient to be able to just tell the encoder to not do FB.

Going along with the voice/music detection in the 1.1-alpha, I don't know if it would be feasible, but it would be nice to dynamically scale the bitrate between detected music and voice portions of a clip with user specified bitrates for each, where the user might choose to set a bitrate of, say, 24kbps for voice, and a higher bitrate of 128 kbps for music.

This seems to come up frequently- one discussion has been moved from the old huge "ready for testing thread" to its own thread.

And in opusinfo, a printout or graph of the bitrate vs time in the file, or maybe just a printout of the bitrate each frame, or the average bitrate at a user specified interval, so you could get a listing of the average bitrate every second, or whatever the user might specify. This might be useful for analyzing how your audio is being encoded.

opusenc's --save-range already dumps each frame's framelength and size, mode and bandwidth info, etc. Not the most handy format for visualization etc, and the only documentation that tells you what's what is reading the code, but the info is there for the parsing. Obviously that doesn't help if you're trying to analyze files you encoded with some other program or files you received from a third party.

[moosehunter]

Use the --save-range option to opusdec.

Cool, didn't realize you could do that, thanks. Is there a place that tells you what each part of the printout means? I had to dig into the source to figure it out.

Oh, and I don't know if anyone's mentioned it yet, it seems pretty obvious anyway, but it goes in with the FLAC support. Transferring the tag and image to the encoded files like the reference FLAC encoder does would be nice.

[moosehunter]

(Can you not edit your posts?)

I find it somewhat odd that you're getting better results by forcing SILK-only at those rates; it'd normally be using hybrid. Once you get down to 16kbps it'll usually be doing SILK-only even if you don't force it. Have you looked at the output bandwidth and verified that it's only wideband? ABC/HR type blind test data confirming your preference for forced SILK would be interesting.

Ahh, that was the difference. Goldwave was encoding it as super-wideband. The difference was usually night and day, depending on the voice of the person. One of the samples with the least difference between the two was the speech sample on the opus example page. I attached the two different encodes.

Given that discovery, I'd agree with the option to let the user choose the bandwidth of the output file.

opusenc's --save-range already dumps each frame's framelength and size, mode and bandwidth info, etc. Not the most handy format for visualization etc, and the only documentation that tells you what's what is reading the code, but the info is there for the parsing. Obviously that doesn't help if you're trying to analyze files you encoded with some other program or files you received from a third party.

Well, just feed the data into Excel, and it displays it just fine. And nevermind about my question about documentation, I didn't read this before I posted that.

Attached File(s)

 example.zip ( 59.5K ) Number of downloads: 26

 

[LithosZA]

A maximum bandwidth setting. In libopus the bandwidth seems to lower automatically when I lower the bitrate, but it seems to be different with opusenc?

Given that discovery, I'd agree with the option to let the user choose the bandwidth of the output file.

+1

[jensend]

You can edit your posts- but only for one hour after you post, since following a discussion gets pretty strange when you can't see what people were replying to. I can appreciate that this is sometimes inconvenient. For instance, my post above looks a little silly, as though I hadn't read the last part of NullC's reply, since I clearly didn't know --save-range was available in opusdec when I wrote most of the reply a week ago. (I'd frequently used it in opusenc but hadn't ever had reason to think about it on the decoding side.) I didn't notice the anachronism until just over an hour after I posted it, and it wasn't worth another reply by itself.

Ahh, that was the difference. Goldwave was encoding it as super-wideband. The difference was usually night and day, depending on the voice of the person. One of the samples with the least difference between the two was the speech sample on the opus example page. I attached the two different encodes.

Interesting. I don't think Goldwave was forcing a higher bandwidth; it was just using libopus 1.0.1, which by default will simply and predictably use hybrid SWB at those bitrates. The pre-1.1 encoder adapts more to its input, and my experience has usually been that it bumps the bandwidth up at considerably lower bitrates than 1.0.x did. With this file, the opposite happened- it quickly switched from SWB to just WB and stayed there.

This file is quite quiet- peaking at -14 dB, ReplayGain of ~+10 - and the encoder must be making its bandwidth detection decisions on an absolute rather than relative basis. If you amplify the file by 12dB, then 1.1-alpha quickly switches to FB and stays there for the length of the file. This seems like undesirable behavior.

[moosehunter]

This file is quite quiet- peaking at -14 dB, ReplayGain of ~+10 - and the encoder must be making its bandwidth detection decisions on an absolute rather than relative basis. If you amplify the file by 12dB, then 1.1-alpha quickly switches to FB and stays there for the length of the file. This seems like undesirable behavior.

That file was just an example. Pretty much all other files I tested did the same thing.

[jmvalin]

Interesting. I don't think Goldwave was forcing a higher bandwidth; it was just using libopus 1.0.1, which by default will simply and predictably use hybrid SWB at those bitrates. The pre-1.1 encoder adapts more to its input, and my experience has usually been that it bumps the bandwidth up at considerably lower bitrates than 1.0.x did. With this file, the opposite happened- it quickly switched from SWB to just WB and stayed there.

This file is quite quiet- peaking at -14 dB, ReplayGain of ~+10 - and the encoder must be making its bandwidth detection decisions on an absolute rather than relative basis. If you amplify the file by 12dB, then 1.1-alpha quickly switches to FB and stays there for the length of the file. This seems like undesirable behavior.

I just checked in a fix in master that should address this issue. It was mostly due to a bug where trying to vary the bandwidth too quickly could leave the encoder stuck in wideband mode. As for the bandwidth detection, it's actually using both relative *abd* absolute thresholds. The absolute thresholds are needed because quantization noise adds energy to all bands. At low volume it can sometimes be hard to tell the difference between quantization noise and actual signal energy.

[Omicron]

It would be good to make a feature in encoder so user do not need to choose bitrate. Encoder chooses the optimal bitrate at which human couldn't distinguish encoded file from the original.

This post has been edited by Omicron: Feb 21 2013, 12:30

[azaqiel]

@Omicron:

impossible. how would the said encoder know how good the music should be, or how good the listener wants it to be, or even how good of a listener the listener is at listening?

off topic: if you think the answer is "as good as it can be", try lossless.

[db1989]

It would be good to make a feature in encoder so user do not need to choose bitrate. Encoder chooses the optimal bitrate at which human couldn't distinguish encoded file from the original.

Oh, here we go again. You have two things to realise:

(1) Allowing a choice of quality and a bitrate that varies depending upon the complexity of the input stream are basic features of modern codecs in VBR modes.

(2) Encoders are not psychic, perceptual modelling is not perfect, listeners are not identical, and these statements are all negative by definition.

It is impossible for an encoder to conclude that x file at y quality will be transparent to “human”, assuming you mean everyone. And it’s impossible for them to guarantee the same thing for any single human.

But encoders already provide sliding scales, based upon various psychoacoustic metrics and without worrying much about bitrate, that allow the individual user to choose from various levels of quality and find one that is generally transparent to him/her.

It would be much easier just to accept this, do a few tests, pick an encoder and quality level, and not worry about it unless anything ever sounds audibly different to you personally.

[kennedyb4]

Tags that would work in Rockbox would be great.

[Omicron]

how would the said encoder know how good the music should be

I think it's possible. May be it's difficult to do, but it's possible. Needs one more algorithm for such a work and some sound experts with good/perfect hearing to find that optimal quality when nobody could distinguish the differences.

if you think the answer is "as good as it can be", try lossless.

You are Captain Obvious, aren't you?)

It is impossible for an encoder to conclude that x file at y quality will be transparent to “human”, assuming you mean everyone. And it’s impossible for them to guarantee the same thing for any single human.

OK, for any sound expert while developing algorithm. So no one in the world could carp for none perfect quality.

and find one that is generally transparent to him/her.

For this I need to find out the optimal bitrate just for one track. And I need to do this over and over again. So it's easier to use always 510kbps or use lossless, and it's not quite good for disk space.

For one of the sound it's impossible to distinguish differences at 128kbps, for other at 96kbs. So encoder chooses the optimal quality for each sound more variable not only over the chosen bitrate. 'cos, for example, when I encode mp3(v0) to opus(512) (I know that it's not good to do this, it's just for an example), opus is 7.48mb, while mp3 was 4.43. Do you know what I mean?

If it is a bad idea or very difficult to do, just... never mind.

[db1989]

Is there something contagious going around Hydrogenaudio recently that’s making people misunderstand how VBR encoders work and ignore what people actually write in explanatory replies? I really lack the energy to repeat myself in slightly different words in the hope that something will change, but hey, I’m going to try anyway.

• Encoders are not perfect and cannot always achieve the same level of theoretical quality for all tracks.
• A given level of quality being transparent on one input signal to one listener is not guaranteed to be transparent on across all, or even any, other material.
• An encoder cannot possibly know which level of theoretical quality will be transparent to you, as a single individual.

Thus, as much as you evidently want to find a reliably transparent level of quality – but equally, and emphatically, don’t want to do the leg-work that is a necessary corollary – you can either put in the effort and possibly get it, or not put in the effort and don’t. Miracles like a psychic encoder that can guarantee transparency on all signals at minimal size just for you are a nice thought, but so are lots of other things that aren’t and cannot ever be real. That’s a limitation that extends far beyond audio encoding.

This post has been edited by db1989: Feb 22 2013, 22:42

[NullC]

Is there something contagious going around Hydrogenaudio recently that’s making people misunderstand how VBR encoders work and ignore what people actually write in explanatory replies?

Yes. There is. Encoders that have "quality" knobs are apparently misunderstood as actually achieving the ideal they aspire to. This wasn't obvious to me before because it's not the sort of misconception that causes comments.

I will probably add a --quality knob that is just an alias for bitrate which will likely silence the complaints at some point... but I'm not in a rush to do it.

A maximum bandwidth setting. In libopus the bandwidth seems to lower automatically when I lower the bitrate, but it seems to be different with opusenc?
If these are possible otherwise please ignore:
- Intensity Stereo threshold setting; tweaking it for low bitrates.
- Force CELT/SILK/Hybrid setting.

Some amount of forcing is possible now via the undocumented set-ctl arguments. Though there is no analog of a settable intensity threshold in our encoder.

Bandwidth and bitrate behavior should be the same w/ libous/opusenc. The only major non-default thing opusenc does is that its VBR by default.

Generally, I am not eager provide detailed internal DSP influencing knobs— at least not as documented user-visible features. The reason for this is simple: If it were easy to set in an improved way the system would do it for you already. If I can't manage to improve the default behavior— knowing how the codec works, having experience and patience with blind testing, and having access to test subjects (you guys)— then it is really unlikely that users of the software— especially ones who haven't shown up in IRC and found out about the undocumented switches— will actually change the settings in a way that will make an improvement... maybe they'll get something that sounds a bit better on the first ten seconds of one sample, then they'll post it up on some less scientifically minded audio forums and people are then cargo-culting it. Meanwhile, exposing knobs takes time and creates more chances for bugs. It's just not generally a good tradeoff in my experience.

[jmvalin]

I think it's possible. May be it's difficult to do, but it's possible. Needs one more algorithm for such a work and some sound experts with good/perfect hearing to find that optimal quality when nobody could distinguish the differences.

Great to hear you know how to do this! I'm eagerly waiting for your patch that implements this and proves us all wrong. We can do a special release just for that for that feature. When are you planning on sending us the code? Thanks in advance.

[jensend]

I will probably add a --quality knob that is just an alias for bitrate which will likely silence the complaints at some point... but I'm not in a rush to do it.

As I tried to say in the other "bitrate vs quality" thread before it went off the rails, adding a --quality knob isn't just cosmetic because it allows you to do what you were talking about with "fullband stereo quality equivalent" without causing confusion or dismay. As you said, if somebody puts --bitrate x for their 22kHz mono speech recording and gets a bitrate of x/3 they will be surprised. However, if they put --quality x for their 22kHz mono speech and get a bitrate 1/3 what they get when they encode 44kHz stereo music with the same quality level, that is perfectly normal expected behavior. Likewise for getting 3x the bitrate for 5.1 surround.

It may sound trivial but it really does improve the user experience when you name things in a way that helps people have the right expectations.

Some amount of forcing is possible now via the undocumented set-ctl arguments. . . Generally, I am not eager provide detailed internal DSP influencing knobs— at least not as documented user-visible features. The reason for this is simple: If it were easy to set in an improved way the system would do it for you already. If I can't manage to improve the default behavior— knowing how the codec works, having experience and patience with blind testing, and having access to test subjects (you guys)— then it is really unlikely that users of the software— especially ones who haven't shown up in IRC and found out about the undocumented switches— will actually change the settings in a way that will make an improvement... maybe they'll get something that sounds a bit better on the first ten seconds of one sample, then they'll post it up on some less scientifically minded audio forums and people are then cargo-culting it. Meanwhile, exposing knobs takes time and creates more chances for bugs. It's just not generally a good tradeoff in my experience.

*sigh*

For those not in the know, the CTLs are in include/opus_defines.h in the opus source code. The main CTLs of interest are OPUS_SET_MAX_BANDWIDTH_REQUEST, OPUS_SET_APPLICATION_REQUEST, and OPUS_SET_SIGNAL_REQUEST.

Trying to make Opus use a higher bandwidth than normal, for which you would use OPUS_SET_BANDWIDTH_REQUEST, is dangerous to your audio quality. Only cases I can think of where it might help are encoder bugs like the one jmv just fixed above and some very artificial stuff like the noisy high-frequency test files softrunner talked about in the 1.1a thread. When Opus drops to a lower bandwidth it generally has very good reasons for doing so.

The CTLs may change in the future. In fact, maybe NullC will go change them now to try to prevent people who haven't been through the IRC initiation ceremony and secret handshake from having access to the sacred mysteries through my link, and maybe he'll try to chain me to a rock and have eagles pick at my liver. Caveat emptor atque venditor.

NullC, my reaction to what you've said above:

• Users have some information about their audio that isn't available to the encoder, e.g. a perfect knowledge of whether their audio is speech or music. Especially at present, when the encoder is trying to do all kinds of analysis with no additional lookahead for non-realtime uses, it's quite conceivable that utilizing that information through some of these settings may help in some situations.
• People may have use cases where maximum fidelity to the original, which is what the encoder is optimizing for, is not the only desideratum. For instance, as I said above, lower-bandwidth and/or SILK are easier to decode by enough to really make a difference on very constrained targets.
• IRC does not scale as a way of propagating information. Insisting that everybody hop on #opus and receive verbal instruction from you before trying to do anything unusual may have worked well during early development but is unreasonable in the long run.
• People are going to find a way to do stupid things no matter what you do. Rather than trying to make it impossible for people to make unwise decisions, it makes more sense to try to spread instruction and warnings and let people come to terms with that information themselves. A handful of fringe people somewhere in the world "cargo-culting it" with unwise settings for a while doesn't have to cause you to lose sleep. Most people won't mess with the options, and almost all of those who do will, with the right information and a little experience, come around to not abusing them. Plenty of other encoders have been through this without seeing persistent widespread abuse of advanced options.
• Exposing these knobs is quite trivial (even I could do it in a jiffy, and if I thought you'd accept a patch I would), and I have a hard time seeing why exposing what's already in the API would "create more chances" for bugs. Instead, I think exposing the knobs and thus allowing people to explore things more easily would be more likely to help discover bugs that are already latent.

This post has been edited by jensend: Feb 23 2013, 21:06

[darkbyte]

I think a per channel bitrate setting would be useful. For eg. i'm encoding my music collection recently into 80kbps Opus and i have some mono chiptune albums and they are getting as high bitrate as 100kbps. If i manually encode them using --bitrate 40 kbps i still get very good quality but just a bitrate around 50-60kbps. So a --bitrate-per-channel 40 would be very useful. This will be 40kbps for mono, 80kbps for Stereo. Or maybe an option to provide a bitrate list for different channel configurations. Someone might want to give a mono recording a bit higher bitrate to be on the safe side.

This post has been edited by darkbyte: Mar 13 2013, 13:07

[jmvalin]

I think a per channel bitrate setting would be useful. For eg. i'm encoding my music collection recently into 80kbps Opus and i have some mono chiptune albums and they are getting as high bitrate as 100kbps. If i manually encode them using --bitrate 40 kbps i still get very good quality but just a bitrate around 50-60kbps. So a --bitrate-per-channel 40 would be very useful. This will be 40kbps for mono, 80kbps for Stereo. Or maybe an option to provide a bitrate list for different channel configurations. Someone might want to give a mono recording a bit higher bitrate to be on the safe side.

Actually, the 1.1-alpha encoder will automatically reduce the bit-rate when the input is mono (well, when the file has two identical channels).

[darkbyte]

Actually, the 1.1-alpha encoder will automatically reduce the bit-rate when the input is mono (well, when the file has two identical channels).

Strange, i'm using the 1.1-alpha-39-g10a35a5-babyeater build but i'm getting the described 100kbps bitrate on some chiptune samples instead of a lower one. Maybe the source is just sounds Mono to me but it has some differences because of dithering or such.

Btw, i forgot that with --bitrate 40 i'm using the --downmix-mono switch on a stereo source where both channels sound equal to me. Otherwise i get the described 100kbps bitrate. So either the mono detection of Opus doesn't work or my source files are just sound mono.
I think i'll upload a sample.

Mod: here's one 30sec sample
This seems like pure mono sample to me. If you encode it with --bitrate 80 it ends up as 71kbps. If i encode it with --bitrate 40 --downmix-mono it will be a 43kbps Opus and it sounds the same to me.
Looks like the beginning of this track is boosting the bitrate a lot. This track ends up at 100kbps but only if i encode it in it's whole length. This 30sec sample encodes into a close to 80kbps size. I think i can't upload the whole track here, it's from the commercial CD "C64 Orchestra - Run 10".

It would be interesting to see if the SID directly converted and upmixed into stereo WAV and then encoded with Opus will end up with the same high bitrate.

Mod2: okay i think i've screwed up something. Now i can't reproduce the high bitrate even on the whole length of the song. Maybe i was encoding yesterday with the non babyeater build.

I think you should ignore this post for now.

This post has been edited by darkbyte: Mar 13 2013, 18:12

[jmvalin]

Strange, i'm using the 1.1-alpha-39-g10a35a5-babyeater build but i'm getting the described 100kbps bitrate on some chiptune samples instead of a lower one. Maybe the source is just sounds Mono to me but it has some differences because of dithering or such.

Please stop testing the babyeater build for now. We've discovered several major issues with it. These need to be fixed (non-trivial) before it's useful to test again.