IETF Opus codec now ready for testing, That's CELT 0.11 Options

[LoRd_MuldeR]

Probably --rate 48000 will do the trick.

Does Opus really always use exactly 48.000 Hz internally, even for "speech" footage with input rates as low as 8.000 Hz?

And, if so, does "--rate 48000" really ensure, under all circumstances, that the resampler won't get invoked? If so, maybe just make "--no-resample" and alias for "--rate 48000", for clarity.

Regards.

[Caroliano]

As opus AWAYS resample to 48kHz, a "--no-resample" switch will certainly cause confusion for those who don't know that. I think there may be a better name. Maybe "--native-rate", "--rate internal", "--encoded-rate", or something like that.

[LoRd_MuldeR]

As opus AWAYS resample to 48kHz

Thanks for confirming.

a "--no-resample" switch will certainly cause confusion for those who don't know that. I think there may be a better name. Maybe "--native-rate", "--rate internal", "--encoded-rate", or something like that.

Anything like that would be welcome.

This post has been edited by LoRd_MuldeR: Nov 24 2012, 17:36

[lvqcl]

Current git version -- v1.0.1-154-g07418d9

This post has been edited by lvqcl: Dec 22 2012, 15:28

[.alexander.]

Hi, I just faced the fact that being mandatory to implement WebRTC codec Opus cannot encode 32KHz signals and WebRTC (some of its components) is designed to support just 8,16 and 32 - but not 48KHz sample rate. Could you clarify, is this a problem of reference implementation or you guys had any particular reason not allocate 2 more bits for 32 and 44.1KHz in bit syntax? Could this be related to transition between SILK and CELT modes? AAC syntax has very minor difference between 32 and 48KHz, basically it's all about mapping bark scale to scale factor bands. Header and side info overhead would be 1.5 times larger for up-sampled signal so it'd probably be better to encode 32KHz signal as 24KHz. What would you expect from OPUS in case it'd be configured for 24KHz to encode 32KHz?

[Speckmade]

Opus cannot encode 32KHz signals

Maybe this is the most frequent confusion with Opus. Try Google for more on this.
Short answer: Opus always works with 48 kHz internally, though it happily takes input and gives output of any rate you like through internal sampling rate conversion. Opus is a little different than other transform codecs and you should probably think of it as being rateless.

[IgorC]

Hi, I just faced the fact that being mandatory to implement WebRTC codec Opus cannot ...

http://lmgtfy.com/?q=opus+32+kHz+%20webrtc

[NullC]

Hi, I just faced the fact that being mandatory to implement WebRTC codec Opus cannot encode 32KHz signals and WebRTC (some of its components) is designed to support just 8,16 and 32 - but not 48KHz

Don't confuse the WebRTC standard and Google's legacy codebase. In the codebase IIRC existing usage of opus there just hooks up a resampler to front end it, but ultimately I presume their code will be fixed. I've prodded some people who are more involved with WebRTC to get an update on whats going on with the google codebase, as I haven't been following it.

sample rate. Could you clarify, is this a problem of reference implementation or you guys had any particular reason not allocate 2 more bits for 32 and 44.1KHz in bit syntax? Could this be related to transition between SILK and CELT modes?

It's related to a couple things, primarily the ability to seamlessly switch between all supported modes and having no possibility of negotiation failure (e.g. remote end only supports 48kHz and your end only supports 32kHz) and also rom and ram size (no separate tables needed for other modes) and what works for computationally cheap internal resampling. It has the benefit that if you're playing a stream from one opus source and the source changes you can just switch to it without upsetting your audio pipeline... or if the network bandwidth changes the codec can make optimal use of whatever is available without a glitchful pipeline interruption.

If an application needs a specific rate for the codec it can always resample, and a reasonably well constructed resampler is perceptually lossless and also quite fast. If opus "supported" more rates thats all it would be doing in any case (and thats effectively what it does for the current supported rates— though they are chosen so that some especially inexpensive handling can be done internally)— as the codec itself doesn't really have a rate in the encoded form (except for the _frame rate_ of 25/50/100/200/400Hz). As far as bitstream bits go... There aren't any bits in the payload for any sampling rates _at all_, though are bits that signal the signals bandpass, which line up with the supported rates, though these can change on a frame by frame basis depending on the content. Bits aren't free, you know— especially when you can emit 400 frames per second in lower latency modes.

This post has been edited by NullC: Dec 5 2012, 16:41

[derf_]

Hi, I just faced the fact that being mandatory to implement WebRTC codec Opus cannot encode 32KHz signals and WebRTC (some of its components) is designed to support just 8,16 and 32 - but not 48KHz sample rate.

Right, this is a limitation of the webrtc.org code. It's slowly being addressed, and eventually the whole stack should support 48 kHz.

Could you clarify, is this a problem of reference implementation or you guys had any particular reason not allocate 2 more bits for 32 and 44.1KHz in bit syntax?

As speckmade alluded to, Opus works somewhat differently than most codecs. Because of its focus on communications, it's designed to have no "negotiation failure", i.e., any encoded Opus packet can be decoded without having to know the settings the encoder was configured with. This includes sampling rate. In order to have this work in a relatively simple way, all of the rates it does support evenly divide 48 kHz (consider what would have to be done to make things work if one packet wanted 48 kHz and the next wanted 44.1 kHz, in a codec with MDCT's windowed overlap-adding).

We evaluated supporting 32 kHz very carefully, but in addition to the complexity a) it doesn't match the band layout of the MDCT layer very well (the cutoff lies in the middle of the highest band), and changing that band structure would have hurt the other audio bandwidths, and b) it doesn't save very many bits over just using fullband. Opus spends so few bits on the high bands at typical super-wideband bitrates that the savings is actually comparable to the overhead needed to signal it. Each packet must be independently decodable, so those "2 more bits" you ask for would have to be included in every one. Even if you omitted the highest band completely, at these rates we are usually only encoding its energy, and that is predicted from past frames and lower bands, so it typically only needs 1 to 1.5 bits/channel per packet to begin with.

AAC syntax has very minor difference between 32 and 48KHz, basically it's all about mapping bark scale to scale factor bands.

Yes, and this is how Opus Custom (the old, more configurable CELT layer) works, but it gives up many of the other properties we wanted, and makes the implementation more complex (for example, the Rockbox people have started contributing decoder optimizations which simply wouldn't work with Opus Custom). For these and many other reasons, we don't recommend people actually use Opus Custom unless they have very specialized hardware that requires particular frame sizes or sampling rates, and don't have to interoperate with anyone else.

Header and side info overhead would be 1.5 times larger for up-sampled signal so it'd probably be better to encode 32KHz signal as 24KHz. What would you expect from OPUS in case it'd be configured for 24KHz to encode 32KHz?

Given what I said above, I would recommend encoding a 32 kHz signal as fullband. I don't know what you mean by "header overhead"... the header sizes are independent of the audio bandwidth. Opus also does not include any per-sample side information and, as I said above, the actual extra rate required to go from 32 kHz to 48 kHz is pretty small. This is the approach taken to supporting Opus in the webrtc.org code until it gets full support for 48 kHz sampling rates. You can see that in the patch that is currently the first result of IgorC's link.

[.alexander.]

Thanks! Opus design really benefits from lack of 32 KHz support. Though solutions that have jitter buffer as primary source of latency may not need 400 packets per second. Upsampling by 3 and 1.5 is almost the same, I looked into your code and gave up with impression that there is no explicit upsampling and inventing pruned MDCT to avoid some resampling latency is overkill. Do you have any expectations of change in average call duration with switch from ISAC to Opus? Design goals and subjective tests are good, but what if call duration would drop on a very big sample?

[bawjaws]

Design goals and subjective tests are good, but what if call duration would drop on a very big sample?

I can't find the link right now but I think Skype (who were involved in creating Opus) did this exact test and found it was a positive change (at least compared with previous codec, which might have been Silk alone, or their previous codec, not sure)

[jossilint]

I tested and at least to me ffmpeg FDK-AAC(he-v2) 40Kbps vbr sounds better than opus(0.1.6) 40Kbps vbr ? any thoughts? can opus defeat aac-he-v2 at low bitrates, i even found one internet radio with opus test, if admins allow i post link here.

This post has been edited by jossilint: Dec 17 2012, 22:02

[saratoga]

I tested and at least to me ffmpeg FDK-AAC(he-v2) 40Kbps vbr sounds better than opus(0.1.6) 40Kbps vbr ? any thoughts?

How did you compare?

[Seren]

I find you need to be over 48kb/s for opus for stereo music. HE seems to sound better just below that, though you can always drop the opus encode to mono and it'd sound better than the HE-AAC below 48kb/s. Well these are my findings based on a few listens, no real ABX'ing so it may be different for others.

[Gainless]

New alpha version has been released:
Link

Can someone compile it?

[Nekit1234007]

Here is a build I made for myself with some crazy gcc parameters, might not work for many people, should work with i7s, x64 only.

http://www.mediafire.com/?onut3ba3ygz9493

[Seren]

Here is a build I made for myself with some crazy gcc parameters, might not work for many people, should work with i7s, x64 only.

http://www.mediafire.com/?onut3ba3ygz9493

Doesn't work on AMD Athlon x2. "opusenc has stopped working"

[lvqcl]

MSVC compile; requires WinXP and SSE processor.

[obsolete; removed]

This post has been edited by lvqcl: Feb 13 2013, 23:01

[jmvalin]

For those interested, here's a blog post that describes what's in this alpha in more details.

[Nick.C]

From the blog regarding the revised VBR constraints - does this mean that the output is tending towards constant quality rather than constant bitrate?

btw: I've been listening to 96kbit/s OPUS output on my RockBoxed Sansa Fuze and am very pleased with what I hear....

[jmvalin]

From the blog regarding the revised VBR constraints - does this mean that the output is tending towards constant quality rather than constant bitrate?

Correct.

[ErectX]

Here is a build I made for myself with some crazy gcc parameters, might not work for many people, should work with i7s, x64 only.

http://www.mediafire.com/?onut3ba3ygz9493

Doesn't work on AMD Athlon x2. "opusenc has stopped working"

Works for me on a Core2. Do you have a 64-bit OS?

1st Athlon x2 - Manchester:
MMX, Extended 3DNow!, SSE, SSE2, SSE3, AMD64, Cool'n'Quiet, NX Bit

Core2 Quad Kentsfield:
MMX, SSE, SSE2, SSE3, SSSE3, Enhanced Intel SpeedStep Technology (EIST), Intel 64, XD bit (an NX bit implementation), iAMT2 (Intel Active Management), Intel VT-x

I have noticed a glitchiness in otherwise stellar 32kbps stereo 24KHz on this build. With radio (voice plus occasional music behind talking), sometimes there will be pronounced audio glitches or popping in one channel, they stand out using headphones because of easy localization vs center voice (they appear to be in the audio stream as repeating the audio gives the same glitches, but I haven't extensively researched yet to verify it's not player-specific to Rockbox Clip+). Also transitions from mono to stereo with a bit of background stereo music in this mode are less then transparent.

I also noted in 1.0.1 (but haven't re-evaluated for improvement with 1.1A yet), that the stream predictor means that you don't get the same audio twice, not at all. Encoding a file with the same two minutes repeated gets you different encoding results two minutes later in the stream. Using 21kbps with -6dB voice there was about one minute of lowpass at 8KHz at the start of the file, when the audio repeated it had 12KHz bandwidth, very visible and audible. Increasing to 22kbps or increasing the source audio level altered the bandwidth allocations but still was quite different on repeated encoding depending on where in the file it was. Perhaps a two-pass encoding or a very large pre-skip, preloading the first minute to train the encoder, would help this.

[Seren]

Here is a build I made for myself with some crazy gcc parameters, might not work for many people, should work with i7s, x64 only.

http://www.mediafire.com/?onut3ba3ygz9493

Doesn't work on AMD Athlon x2. "opusenc has stopped working"

Works for me on a Core2. Do you have a 64-bit OS?

1st Athlon x2 - Manchester:
MMX, Extended 3DNow!, SSE, SSE2, SSE3, AMD64, Cool'n'Quiet, NX Bit

Core2 Quad Kentsfield:
MMX, SSE, SSE2, SSE3, SSSE3, Enhanced Intel SpeedStep Technology (EIST), Intel 64, XD bit (an NX bit implementation), iAMT2 (Intel Active Management), Intel VT-x

Sorry, I kinda screwed that up, I meant "Athlon II" (x2 245 using MMX(+), 3DNow!(+), SSE(1,2,3,4A), x86-64, AMD-V)
Win7 x64.

This post has been edited by Seren: Dec 23 2012, 03:10

[Gainless]

MSVC compile; requires WinXP and SSE processor.

Thanks!

It seems like the new alpha version performs worse on certain stuff than Opus tools 0.1.6, e.g on the Muse Breaks and Sycho Active samples (can be found here and here), obvious glitches at 192 kbps, while OT is pretty much transparent there.

This post has been edited by Gainless: Dec 23 2012, 11:28

[ErectX]

Here is a build I made for myself with some crazy gcc parameters, might not work for many people, should work with i7s, x64 only.

http://www.mediafire.com/?onut3ba3ygz9493

Doesn't work on AMD Athlon x2. "opusenc has stopped working"

It looks like the one instruction set missing is SSSE3 (http://en.wikipedia.org/wiki/SSSE3#CPUs_with_SSSE3) which is only on AMD Bulldozer+/Core2+. I don't have 64bit OS on my non-SSSE3 Intel (P4 Prescott MMX, SSE, SSE2, SSE3, Hyper-Threading, Intel 64, XD bit) to check this binary. Perhaps Nekit1234007 can detail what the "crazy parameters" were.

This build runs about 5% faster than Mozilla opus-tools, so no complaints.