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

[CoRoNe]

I've just released DC-Bass Source Mod 1.5.0.0, which I believe is the first DirectShow filter with Opus support. Have fun.

[LigH]

Nice. I hope BassSource for AviSynth will have it too, soon.

[CoRoNe]

There already is: bass_opus.dll (still experimental, but seems to be working great) in combination with BassAudio.

[kode54]

Is 'native' gapless support (like in Vorbis) planned for Opus?

Opusdec itself has the potential to glitch on these samples if you don't specify --rate 48000 when decoding them to WAV files, as it doesn't use LPC to flush the resampler at the end of the tracks. I'll work on this after lunch if this is the case.

In the mean time, decode to WAV files with --rate 48000 and test those.

m1.flac/m2.flac sound gapless to me with or without the --rate 48000 switch, so maybe my hearing isn't the best.

EDIT: Maybe you're using old opus-tools?

[Brand]

It's not really a gap, but a tiny quiet pop/glitch.

I'm using LameXP to encode and Foobar 1.1.14 for playback. The version of Opus in LameXP is libopus 2012-7-24.

I tried converting the Opus to WAV from Foobar and it was the same, still a glitch. (Foobar created a 48k WAV file and it also displays 48k when playing the Opus file.)


However:
If I decode the Opus file to WAV with LameXP there's no glitch. And the decoded WAV is 44.1k.

Just out of curiosity, I converted to WAV from Foobar while resampling (with PPHS) to 44.1k and I couldn't hear a glitch in the resulting WAV.

So 44.1k appears to work better in this case.


EDIT2: I tried quickly enconding to Opus with the last opus-tools CLI (opusenc) and it's always glitching, at 44.1k and at 48k. But I'm also using different settings than with LameXP.
If I decode the LameXP Opus with opusdec CLI, then again, the 44.1k doesn't glitch, while the 48k does.

This post has been edited by Brand: Jul 28 2012, 11:33

[zerowalker]

Where is the current "Transparent" settings right now, if there is any:)?

been playing with the one NullC gave, and it´s very neat;D

[kode54]

EDIT2: I tried quickly enconding to Opus with the last opus-tools CLI (opusenc) and it's always glitching, at 44.1k and at 48k. But I'm also using different settings than with LameXP.
If I decode the LameXP Opus with opusdec CLI, then again, the 44.1k doesn't glitch, while the 48k does.

Try this set of opus-tools with foobar2000, or stand-alone from a console, if you have an x64 system with Windows x64 installed:

https://dl.dropbox.com/u/14849789/opus-tools.zip

They're based on the latest exp_analysis branch, with some minor changes that should hopefully fix any track start gaps. Although at least with m1.flac and m2.flac, I don't notice any glitch on m1->m2 transition, and pasting the two together in a sound editor shows that the end of m1 lines up with the start of m2. Note that the end of m2 is not supposed to loop seamlessly back to the start of m1, in case that's something you were trying.

My change for start gap reduction applies an LPC pre-extrapolation at the start of the file, adding 2.5ms of latency to the stream, which is then absorbed into the preskip. This change is disabled if you request frame sizes smaller than 10ms, or maximum Ogg latency of less than 120ms.


Something worth noting for whoever is maintaining LameXP, the current master for git.xiph.org/opus-tools.git includes all the Unicode changes, and the MSVC 2010 projects now include a git version generator, so the tools will accurately mark files with whichever versions of libopus and opus-tools were used when encoding.

[Brand]

To keep things standardized, I'm now just using opusenc.exe with Foobar and --music --bitrate 128 - %d.


This build of opus-tools (from the previous page) produces, at least to my ears, an easily noticeable glitch when transitioning from m1 to m2. It's a quiet high pitched click, but with headphones and medium to loud volume I can easily hear it in the left channel.

The new build you just posted seems to make the glitch quieter, but it's still there.

EDIT:
I recorded the playback to compare the original FLAC, the older and the newer build:
http://dl.dropbox.com/u/81620025/opus gapless test.7z

This post has been edited by Brand: Jul 29 2012, 15:17

[IgorC]

Where is the current "Transparent" settings right now, if there is any:)?

Transparency is subjective. Furthermore Opus is on intensive development. So quality is improving constantly.
To have an idea, the last experimental build is reaching the quality of MP3 130 kbps (LAME -V 5) at 80 kbps.

This post has been edited by IgorC: Jul 29 2012, 17:50

[zerowalker]

Where is the current "Transparent" settings right now, if there is any:)?

Transparency is subjective. Furthermore Opus is on intensive development. So quality is improving constantly.
To have an idea, the last experimental build is reaching the quality of MP3 130 kbps (LAME -V 5) at 80 kbps.

Yes i understand that, but just that difference is very nice:)

I myself find 100 and below to sound extremely good, so i am hoping for it´s continuation:)

[zerowalker]

Is there any software that´s using Opus for speech transfer (skype like)?
I know it´s not finished and all that, but maybe there´s some open source software trying it out or something?
Would be very interesting to try it with it´s real purpose.

[Clifoo]

Mumble will undoubtedly support Opus soon. Mumble upcoming features

[Garf]

Is there any software that´s using Opus for speech transfer (skype like)?

Skype itself is using an older version of the algorithm (they contributed the speech encoding part to Opus).

[PHOYO]

Mind-blowing quality with only 64 kbps. Awesome work.

[zerowalker]

Mumble will undoubtedly support Opus soon. Mumble upcoming features

Nice that Skype uses some old version, hope they upgrade to the new:)

And that mumble will use is very neat. Haven´t used it, but would be nice.

Does mumble have better quality than skype?

Am i supposed to open a server myself and let my friend connect to it, or vice versa?

[LigH]

Yes, you may use Murmur as server, and can tell friends about your IP address (or maybe DynDNS name) and other connection details to talk freely with each other via Mumble clients. But there are also public servers with voice chat channels, similar to IRC with text chat channels.

The quality of the service depends on the (mainly upload) bandwidth from the server and each client, you can configure bitrate and latency / packet size.

This post has been edited by LigH: Aug 5 2012, 18:28

[zerowalker]

Yes, you may use Murmur as server, and can tell friends about your IP address (or maybe DynDNS name) and other connection details to talk freely with each other via Mumble clients. But there are also public servers with voice chat channels, similar to IRC with text chat channels.

The quality of the service depends on the (mainly upload) bandwidth from the server and each client, you can configure bitrate and latency / packet size.

Have tried it, using my PC as a server and my friend connecting to it, the difference from Skype in Sound Quality is SICK, it´s really amazing!
I think it´s lower latency aswell, as it´s not middle server.

But is there a Build that´s using OPUS, or can someone build one?
I know it´s experimental and all, but it would be very neat to try it on it´s home ground (speech).

[LigH]

It is a SourceForge project. So someone will probably be able to build an Opus DLL for it... But I would not recommend to rush it. It might be buggy. And it might be incompatible to other users not using exactly the same files.

Patience, young Padawan.

[zerowalker]

It is a SourceForge project. So someone will probably be able to build an Opus DLL for it... But I would not recommend to rush it. It might be buggy. And it might be incompatible to other users not using exactly the same files.

Patience, young Padawan.

Yeah i know, but i would like to test it with my Friend, so both will be using the Exact same file:)

Sadly i myself don´t know how to do it, as long as it´s not very easy, like changing a file or just some text etc.


Patience is something i lost long ago ;P

[Gainless]

One thing I've noticed is that Opus (the exp version of course) is pushing a lot of bits into pieces at higher bitrates for which other encoders like Vorbis or even Lame are using way less. Since Opus should be at least better than Vorbis at anything there could be probably a lot of average bitrate decrease done while still keeping the same quality overall.

This post has been edited by Gainless: Aug 6 2012, 22:09

[Garf]

One thing I've noticed is that Opus (the exp version of course) is pushing a lot of bits into pieces at higher bitrates for which other encoders like Vorbis or even Lame are using way less. Since Opus should be at least better than Vorbis at anything there could be probably a lot of average bitrate decrease done while still keeping the same quality overall.

Yes, that's why you can just lower the bitrate? I don't get your point.

[LigH]

I believe Gainless refers to something I would call "bitrate dynamics".

If one reduces the overall bitrate target, it does not only reduce the bitrate for the complex scenes which consume a lot of bitrate, but also for the simple scenes which are satisfied with less bitrate already. Gainless is probably interested in "compressing" only the high bitrate scenes, which he feels seem to get out of control.

[Garf]

I believe Gainless refers to something I would call "bitrate dynamics".

If one reduces the overall bitrate target, it does not only reduce the bitrate for the complex scenes which consume a lot of bitrate, but also for the simple scenes which are satisfied with less bitrate already. Gainless is probably interested in "compressing" only the high bitrate scenes, which he feels seem to get out of control.

If you don't want the encoder to adapt to the material, then use CBR mode.

If the reasoning is something like: "because Opus is better than Vorbis, it should be able to compress any piece/part of a piece of music to the same/better quality using less/same amount of bits" => this simply doesn't follow at all, which is exactly why VBR is boosting the bitrate.

[LigH]

Why black and white only?

Adapting the bitrate to the complexity of the material is useful. But tweaking the adaption factor might be useful in some cases where the bitrate dynamic is high. There might be situations where extreme bitrate fluctuations may lead to technical issues, e.g. regarding decoding buffers filled from slow sources like optical drives or network transfers. Of course, quality will be suboptimal where bitrate dynamics are dampened.

Do you know the Xvid video codec and the parameters for "Overflow treatment" and "Curve compression"?

This post has been edited by LigH: Aug 7 2012, 10:24

[Garf]

There might be situations where extreme bitrate fluctuations may lead to technical issues, e.g. regarding decoding buffers filled from slow sources like optical drives or network transfers.

In such case you should really use constrained VBR, that mode exist exactly for those situations. Unfortunately I believe in the current Opus encoder the decoder buffer size is not fully configurable: Constrained VBR CTL

In no circumstances should you use VBR if your transport has a limit that isn't far enough away from the expected maximal possible bitrate, that's just trying to make things work by coincidence. Let alone trying to make the bitrate stay within limits "by coincidence" by crippling the VBR behavior of the encoder, that's even worse as it will lower quality with zero guarantees it will work.

Do you know the Xvid video codec and the parameters for "Overflow treatment" and "Curve compression"?

In x264 you will configure the decoder buffer size and the channel bitrate, and this is really all the user needs to configure. And it's also exactly this that needs to be configured for proper support of hardware decoders, and it allows the encode to give the maximal possible quality knowing the constraints of the channel and the decoder. Other settings are, to put it mildly, suboptimal.