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

[Kohlrabi]

Now is really the time to get support into applications (well, this was also true for some time, but doubly so now). If there is an application you think should have Opus support that doesn't, especially open source ones, please post about it here and I'll do what I can to coordinate with their authors.

Probably the most important ones are the major browser vendors, Winamp, foobar2000, gstreamer and ffmpeg. Scouring the web I saw that at least the latter two have some implementations of CELT decoders in their trees.

This post has been edited by Kohlrabi: Jul 3 2012, 14:38

[NullC]

Probably the most important ones are the major browser vendors, Winamp, foobar2000, gstreamer and ffmpeg. Scouring the web I saw that at least the latter two have some implementations of CELT decoders in their trees.

Opus support in the audio tag is complete (well multichannel is following behind) in Firefox, and you can use it in Aurora (FF15) and Nightly, though you have to activate it through a preference: some quick instructions.

Support in Gstreamer is complete and reasonably well tested— at least for file based usage, not so much for RTP—, I'm not sure where in their release pipeline gstreamer is right now.

There are patches for Ffmpeg, though last I checked were incomplete and so they handled files incorrectly (e.g. got the duration wrong, did not apply the header gain, couldn't accurately seek) but this should be fairly straight forward to complete.

I understand that foobar2000 is being worked on, but I'm not sure where it stands. I understand that the relevant people have been prodded. People still use Winamp? Okay. I'll see what I need to do there.

This post has been edited by NullC: Jul 3 2012, 14:53

[lvqcl]

Probably the most important ones are the major browser vendors, Winamp, foobar2000, gstreamer and ffmpeg. Scouring the web I saw that at least the latter two have some implementations of CELT decoders in their trees.

foo_input_celt

[LithosZA]

foo_input_celt

Will that work with Opus encoded files or only CELT?

[Garf]

foo_input_celt

Will that work with Opus encoded files or only CELT?

Given the age, likely only CELT. Here's hoping Peter adds full Opus by default in foobar2000.

[lvqcl]

This plugin is old and incompatible even with CELT 0.11.4: http://www.hydrogenaudio.org/forums/index....st&p=758102

[yourlord]

Opus has received the IETF's approval to become a standard.

Congrats! Another great day in the open audio world!

[greensdrive]

this is wonderful. I silently predicted this, though.

as far as applications, DeaDBeeF. open source, and I'm fairly certain it doesn't use gstreamer. I use it a lot, so Opus support would be awesome. I also use foobar2000, but Peter may have something going on behind the scenes for Opus... I hope.

question: do the "exp_wip" branches have some kind of extra tuning? I mean, what's their purpose?

[CoRoNe]

If there is an application you think should have Opus support that doesn't, especially open source ones, please post about it here and I'll do what I can to coordinate with their authors.

BASS Audio Library

[IgorC]

question: do the "exp_wip" branches have some kind of extra tuning? I mean, what's their purpose?

Reading the changelog can be informative.

And since it's an open source You can look as close as You wish ... if You wish.

This post has been edited by IgorC: Jul 3 2012, 21:04

[skamp]

If there is an application you think should have Opus support that doesn't, especially open source ones, please post about it here and I'll do what I can to coordinate with their authors.

caudec 1.4.2 supports encoding with Opus

I asked DeaDBeeF's author about it, but that was the first he heard of it. He has thus no current plans to support it, and he said ALAC support will likely come first.

[greensdrive]

Reading the changelog can be informative.

I'm familiar with git, but never was interested enough to investigate those branches until earlier today. dunno why I asked, really...

side note: I was unable to compile a working opusenc on Linux Mint. it got through ./configure, make, sudo make install with no errors, but complains about the missing libopus.so.0, which is actually installed in /usr/local/lib, and also got through ./configure, make, sudo make install with no errors. very odd.

[NullC]

Reading the changelog can be informative.

I'm familiar with git, but never was interested enough to investigate those branches until earlier today. dunno why I asked, really...

side note: I was unable to compile a working opusenc on Linux Mint. it got through ./configure, make, sudo make install with no errors, but complains about the missing libopus.so.0, which is actually installed in /usr/local/lib, and also got through ./configure, make, sudo make install with no errors. very odd.

It's the expected behavior when /usr/local/ isn't in your PKG_CONFIG path. Run:

PKG_CONFIG_PATH=/usr/local/lib/pkgconfig/ ./configure

And you'll be all set.

You can see the revision history without running git yourself. (it's now called exp_wip6 as it was rebased on the current master work today)

The EXP work adds a psymodel to Opus. It's used to dynamically control some of the tuning and the bitrate. The improvement for VBR is fairly substantial. I'll put up an opus-tools win32 build with it soon for people here to try out.

[NullC]

This is a win32 build of opus-tools using the "exp_analysis" encoder.

Please give it a whirl. Most interesting is VBR at moderately low bitrates (e.g. 64kbit/sec for stereo).

This is an improved Opus encoder which uses an explicit psymodel to inform various encoding decisions. It should improve the perceived quality overall and greatly improve it on some samples (and this belief has been supported in small blind informal listening tests).

A couple quick notes:
* This encoder is much slower, this is expected. It should get somewhat faster before release.
* This encoder is much more VBR in VBR mode than prior opus encoders, on single tracks you may get significantly more or less than you asked for (as is true for libvorbis and other true VBR encoders)
* This encoder's VBR is not yet calibrated. If you ask for 64k you may find that the average on a large representative collection comes out to be 75k (random numbers). If so, you ought to be comparing this to the old encoder running at a similar rate overall rate. Obviously it will be calibrated before the release so that when you ask for 64 you get 64 on average for large diverse collections.

We'd very much like to hear if you find any samples where (after fairly calibrating rates on some bigger collection) this encoder does obviously (or at least ABXably) worse than the normal encoder.

Thanks and happy listening!

[Dynamic]

I think Android should add OPUS support. They've incorporated Vorbis from the start and any app can use that infrastructure to play Vorbis natively.
Very plausible that OPUS support could get into other Google products such as GoogleTalk and GooglePlus Hangouts, some of which might get native Android support.
I presume that fixed-point support implies compatibility with embedded or ARM-type architectures (I didn't spot implicit mention of integer decoding support, but fixed-point can usually be implemented using integer architecture with appropriate bit-shifting).

It may be worth bringing up OPUS as a new standard with such a lot of strong selling points, all converging in one codec, giving the potential for new use-cases and improvements to existing use-cases:

What really excites me about OPUS is (I think my understanding is correct on all these points):

ONE CODEC SIMULTANEOUSLY CAPABLE OF CLASS-LEADING PERFORMANCE IN A WIDE VARIETY OF USES:
• live or delayed listening;
• speech & music;
• mono, stereo or multichannel;
• streaming or stored files;
• bit-perfect or degraded transmission

Specific features:
- at ultra-low bitrates from 6kbps: good speech codec with low latency
- at low bitrates: test-topping stereo music performance at low constrained bitrates, with low latency and packet loss concealment all at the same time
- at higher-bitrates: transparent quality, low latency and packet loss concealment at same time
- scalable anywhere between these extremes
- seamlessly switchable between modes during live stream
- floating/fixed-point compatible


- topping low bitrate stereo music blind listening test (as CELT, despite competing in 25ms latency against the best high-latency codecs)
- also capable of ultra-low bitrates as a speech codec
- all the same advantages as Vorbis (open patent-free design philosophy - suitable for Wikipedia, for example), scalable from low bitrates up to perceptual transparency yet more data-efficient than Vorbis despite lower latency
- very low or low latency
- web embedding support
- two-way/multi-way comms suitable including music-compatible at mobile-suitable bitrates with packet loss concealment
- suitable for live-casting (e.g. potentially useful for personal playback for the hearing-impaired (or anyone) at live events with low latency - still lip synced with a live speaker - with modest bandwidth requirements)
- potential for wireless headphone implementations given low latency
- suitable for live jam sessions over hundreds of kilometres
- many more uses can be developed given the convergence of these features in one codec for the first time

And also, it's already got support coming or implemented in beta from some important players in the field.

[greensdrive]

I agree that Android should support playback (among other things). however, I kinda think Google supporting Opus upon or near 1.0 release is pretty unrealistic.

NullC:

what I meant earlier was that I compiled and installed opus (exp_wip5 from git). then I compiled and installed opus-tools (from git). but after that, running `opusenc --help` from the command line gave me a "cannot find shared object libopus.so.0" type of error. just wanted to clarify. it's probably just a problem on my end.

[jmvalin]

what I meant earlier was that I compiled and installed opus (exp_wip5 from git). then I compiled and installed opus-tools (from git). but after that, running `opusenc --help` from the command line gave me a "cannot find shared object libopus.so.0" type of error. just wanted to clarify. it's probably just a problem on my end.

Try:
export LD_LIBRARY_PATH=$LD_LIBRARY_PATH:/usr/local/lib/

[Garf]

This is a win32 build of opus-tools using the "exp_analysis" encoder.

Please give it a whirl.

Might be worthy of a new top-level topic? This kind of thing should very interesting to our audience.

[NullC]

what I meant earlier was that I compiled and installed opus (exp_wip5 from git). then I compiled and installed opus-tools (from git). but after that, running `opusenc --help` from the command line gave me a "cannot find shared object libopus.so.0" type of error. just wanted to clarify. it's probably just a problem on my end.

Try:
export LD_LIBRARY_PATH=$LD_LIBRARY_PATH:/usr/local/lib/

^ That. Or add a line with "/usr/local/lib/" to your /etc/ld.so.conf ... Most GNU/Linux systems don't look in /usr/local/lib/ by default

[IgorC]

This is a win32 build of opus-tools using the "exp_analysis" encoder.

Please give it a whirl.

Might be worthy of a new top-level topic? This kind of thing should very interesting to our audience.

Have tried the experimental branch here http://www.hydrogenaudio.org/forums/index....st&p=796102
My guess is that people will want to get their hands to it when some support will be here.

[NullC]

I've posted an updated win32 build of the experimental encoder branch:

opus-tools_exp_1a50ad0b.zip

This update includes encoder fixes for 2.5ms frame VBR (a bug in the prior version made it always produce very low rates) and an updated version of opusenc with improved gapless handling contributed by kode54.

[Gainless]

I've posted an updated win32 build of the experimental encoder branch:

opus-tools_exp_1a50ad0b.zip

This update includes encoder fixes for 2.5ms frame VBR (a bug in the prior version made it always produce very low rates) and an updated version of opusenc with improved gapless handling contributed by kode54.

Thanks
I've just tested it with a few tunes at 64 kbps and found one that may could benefit of some improvements.

Audio Link

Just listen to the distorted kinda vocal that's coming in after a few seconds.

This post has been edited by Gainless: Jul 6 2012, 15:17

[greensdrive]

Gainless, I listened to the entire sample, no vocals. maybe you uploaded the wrong clip? also, was that the original lossless or the encoded version? I would think the original lossless would be more important to test with...

[punkrockdude]

C'mon coders. Please make a Foobar2000 decoder so we can use this format. Regards.

[Gainless]

Gainless, I listened to the entire sample, no vocals. maybe you uploaded the wrong clip? also, was that the original lossless or the encoded version? I would think the original lossless would be more important to test with...

Ok, "vocal" isn't a great description, it's more like a distorted voice saying "e-ah!". And the sample is of course from the original lossless file.

This post has been edited by Gainless: Jul 7 2012, 10:58