User: Password:
|
|
Subscribe / Log in / New account

The Opus codec becomes an IETF standard

The Opus codec becomes an IETF standard

Posted Sep 11, 2012 20:41 UTC (Tue) by cyanit (guest, #86671)
Parent article: The Opus codec becomes an IETF standard

Is Opus always better than Vorbis in practice, making Vorbis usage no longer recommended, or is Vorbis still useful beyond compatibility?

More in general, is Opus indeed the best audio codec ever for any sort of audio at more than 12 kbps (as the graph seems to show, although > 128 kbps is missing), or are there tests that show that something else beats it in certain situations?

What about efficient compression of surround audio, both for command formats, and for generalized surround with an arbitrary number of channels in arbitrary 3D positions?


(Log in to post comments)

The Opus codec becomes an IETF standard

Posted Sep 11, 2012 21:03 UTC (Tue) by jmspeex (subscriber, #51639) [Link]

When you get to bitrates like 128 kb/s, it's so close to transparent that it's nearly impossible to test which codec is best with any kind of statistical significance. If you encoded all your music collection with Vorbis at 160 kb/s, I don't think you'd be gaining much from using Opus instead. Opus, Vorbis and AAC are so close to transparent at those rates that it's becomes mostly an encoder issue. In the end, there are bit-rates where Opus clearly outperforms Vorbis, but we're not aware of Vorbis really outperforming Opus at any point.

The Opus codec becomes an IETF standard

Posted Sep 11, 2012 21:25 UTC (Tue) by drag (subscriber, #31333) [Link]

Web based Voice over IP and super-high-compressed video/music is were Opus should shine.

Can it usefully be embedded in webm?

The Opus codec becomes an IETF standard

Posted Sep 11, 2012 21:59 UTC (Tue) by bjencks (subscriber, #80303) [Link]

Not webm, since webm is specifically the matroska/vp8/vorbis combination, with some extra restrictions on what matroska features are available.
There's work on putting it into matroska, though it looks like there are some incompatibilities with seek timestamps: http://wiki.xiph.org/MatroskaOpus

The Opus codec becomes an IETF standard

Posted Sep 12, 2012 9:32 UTC (Wed) by Jonno (subscriber, #49613) [Link]

> Is Opus always better than Vorbis in practice, making Vorbis usage no longer recommended, or is Vorbis still useful beyond compatibility?

Opus was not designed to obsolete Vorbis, only Speex. However, as a happy accident it outperforms Vorbis for bit rates of 96 kbps and below. For higher bit rates, it is statistically tied with Vorbis, primarily because the difficulty of hearing any difference at all between Opus/Vorbis and the original.

So, for any use of low-bitrate Vorbis (or mp3), switch to Opus. For high bit rates, use Opus or whatever you did before, whichever is easiest for you. As I expect Opus compatibility to overtake Vorbis compatibility fairly soon, I would make any new encodes as Opus, at 128kbps if mono and 192 kbps if stereo. Anything above that is not really useful except for perfect fidelity, in which case you should just use Flac instead.

> More in general, is Opus indeed the best audio codec ever for any sort of audio at more than 12 kbps, or are there tests that show that something else beats it in certain situations?

Last I checked, Opus is either better or statistically tied with all competitors at all supported bit rates above 12 kbps, and statistically tied with the original at the maximum bit rate of 256 kbps per channel, but there might be some study I have missed.

> What about efficient compression of surround audio, both for command formats, and for generalized surround with an arbitrary number of channels in arbitrary 3D positions?

Opus only support stereo coupling, but you can add several stereo-coupled channels in one stream (eg 7.1 surround would consist of three stereo couplings and two discrete channels). Not optimal efficiency, but better than Vorbis (which doesn't support coupling at all when there is more than two channels), and generally speaking good enough.

Comparison with codec2 & other very narrow encoders?

Posted Sep 12, 2012 14:40 UTC (Wed) by ejr (subscriber, #51652) [Link]

It'd be nice to see a low-end version of the quality graph comparing Opus with codec2 ( http://www.rowetel.com/blog/?page_id=452 ) and other low-rate voice encoders. I realize they're different design points, but the comparison would give an idea of the trade-offs in bit rate v. overall use (not just voice) in the lower end.

Comparison with codec2 & other very narrow encoders?

Posted Sep 13, 2012 8:50 UTC (Thu) by jmspeex (subscriber, #51639) [Link]

The comparison is actually not helpful because Opus just doesn't go that low. As I've said before, the only two codecs that Opus does not replace are codec2 and FLAC.

Comparison with codec2 & other very narrow encoders?

Posted Sep 13, 2012 15:21 UTC (Thu) by ejr (subscriber, #51652) [Link]

It is helpful at a higher level. If you're trying to design a system, is it worth pushing the bit rate as low as possible? Seeing the qualities achieved for typical signals can help people decide which trade-offs to tackle. Should you shoot for jamming enough into single network packets with moderate lag and a simple overlapping scheme for handling drops or go ahead and expect many packets with a different error handling mechanism, etc.

The Opus codec becomes an IETF standard

Posted Sep 13, 2012 9:19 UTC (Thu) by tterribe (✭ supporter ✭, #66972) [Link]

> Not optimal efficiency, but better than Vorbis (which doesn't support coupling at all when there is more than two channels), and generally speaking good enough.

Vorbis is actually the only format I know that supports arbitrary multi-level coupling. It simply wasn't implemented in a real encoder until 2010 (and the fact that it took that long speaks a lot more to the demand for this feature than the difficulty). And of course, when it was implemented, it broke decoders that hadn't bothered with that part of the spec.

See http://people.xiph.org/~xiphmont/surround/demo2.html for details.
The most interesting part of that work, to me, was that the bulk of the gains came from re-training the VQ backend, not from the coupling itself. Opus uses algebraic VQ which does not need to be re-trained.


Copyright © 2017, Eklektix, Inc.
Comments and public postings are copyrighted by their creators.
Linux is a registered trademark of Linus Torvalds