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

[IgorC]

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.

I've tried velvet sample http://www.rarewares.org/test_samples/velvet.wv and compared it to CELT 0.11.2 because the last one was very aggressive to preserve transients (though at cost of not great quality for tonal samples).

This build (exp6) produces ~64 kbps with --bitrate 61 and the same as CELT 0.11.2 --bitrate 67.5 kbps on large number of files.

While exp6 is a bit inferior to handle transients it has more balanced overall quality, better trade-off for transients/tonality (short/long blocks).

CODE

ABC/HR for Java, Version 0.53a, 07 July 2012
Testname:

Tester: IgorC

1L = velvet_CELT_0.11.2_67kbps.wav
2R = velvet_61k_exp6.wav

Ratings on a scale from 1.0 to 5.0

---------------------------------------
General Comments:
---------------------------------------
1L File: velvet_CELT_0.11.2_67kbps.wav
1L Rating: 3.5
1L Comment:
---------------------------------------
2R File: velvet_61k_exp6.wav
2R Rating: 3.1
2R Comment:
---------------------------------------

ABX Results:
velvet_CELT_0.11.2_67kbps.wav vs velvet_61k_exp6.wav
5 out of 5, pval = 0.031


---- Detailed ABX results ----
velvet_CELT_0.11.2_67kbps.wav vs velvet_61k_exp6.wav
Playback Range: 00.000 to 11.812
2:04:41 PM p 1/1 pval = 0.5
2:04:45 PM p 2/2 pval = 0.25
2:04:50 PM p 3/3 pval = 0.125
2:05:14 PM p 4/4 pval = 0.062
2:05:22 PM p 5/5 pval = 0.031

I wish I had a bit of time to get look into some parameters in code and try some variants but it's not the case.

[kennedyb4]

A listening test sounds like a great idea. Could I suggest 64kbps as the encoders are so good now that 96kbps is very painstaking, at least for me.

[NullC]

A listening test sounds like a great idea. Could I suggest 64kbps as the encoders are so good now that 96kbps is very painstaking, at least for me.

Conducting a large listening test of a moving target encoder— which won't exist except in the source code history in the current form anymore by the time the test is done— doesn't sound like a grand idea to me.

... Unless people really can't find any problem areas in the exp encoder and it's perfect, in which case we better stop changing it.

[IgorC]

A listening test sounds like a great idea. Could I suggest 64kbps as the encoders are so good now that 96kbps is very painstaking, at least for me.

I beleive we will see a lot of public tests ( at 64 kbps too) in future. There is still a long way for audio compression (USAC/Extended HE-AAC, Opus, new versions of LC/HE-AAC encoders, Ghost).

[rt87]

A listening test sounds like a great idea. Could I suggest 64kbps as the encoders are so good now that 96kbps is very painstaking, at least for me.

I beleive we will see a lot of public tests ( at 64 kbps too) in future. There is still a long way for audio compression (USAC/Extended HE-AAC, Opus, new versions of LC/HE-AAC encoders, Ghost).

I look forward to see a lower-than-64kbps (for example 48kbps) test against Vorbis and HE-AAC.

This post has been edited by rt87: Jul 9 2012, 09:03

[IgorC]

Post your suggestions here General discussion of future public test

[NullC]

I look forward to see a lower-than-64kbps (for example 48kbps) test against Vorbis and HE-AAC.

I'd be interested in seeing a test with just one or two people... to see if a bigger one s even worth doing. Opus is great... but for music (as opposed to speech) I would expect that at low enough rates Vorbis and especially HE-AAC will end up ahead again.

Perhaps I spent too much time on killer samples so my expectations are a bit low, and its possible that after collection rate correction the exp encoder will do better than I'm expecting. I'm not sure where that boundary lies exactly, but I don't see much purpose in having a big multiformat test with forgone conclusions if 48kbit is on the wrong side of it.

[NullC]

I've tagged opus-tools 0.1.3, and there are now binaries on the downloads page.

This version includes the gapless improvements that were in the last development-test build I cut as well as correct multichannel channel ordering for wav output (finally! sorry for the delay).

All feedback welcome.

[2304p]

I've tagged opus-tools 0.1.3, and there are now binaries on the downloads page.

This version includes the gapless improvements that were in the last development-test build I cut as well as correct multichannel channel ordering for wav output (finally! sorry for the delay).

All feedback welcome.

link doesn't work

CODE

Forbidden

You don't have permission to access /pub/mozilla.org/opus/win32/opus-tools-0.1.3-win32.zip on this server.

This post has been edited by 2304p: Jul 11 2012, 06:58

[NullC]

link doesn't work

I prodded the relevant people and its fixed now. Doh. Read access on a file server?? But someone might read something!

[yourlord]

Just for grins I downloaded and compiled libopus and opustools..

I then encoded the Dream Theater song Bridges In the Sky from FLAC to opus at 48Kbps.

flac -d --totally-silent -c Dream\ Theater/A\ Dramatic\ Turn\ Of\ Events/05\ -\ Bridges\ In\ The\ Sky.flac | opusenc --music --bitrate 48 - DT_Bridges.opus

(BTW, please try to add FLAC input file support to openenc when you get a chance!)

This was on Xubuntu Oneiric 11.10, 64-bit.

I then decoded the opus file back to wav, compressed it with FLAC and transferred it to my machine at work (did this on a machine at home while I was supposed to be working.. oops).

I'm listening on a Thinkpad T420 using VLC 2.0.2 and a craptastic pair of ear-buds.

I have a local 1st generation Ogg Vorbis -q5 version of the song to compare it to.


With all that said, and the obvious admission this is not ABX, I was definitely able to hear a marked difference between the 2. I was VERY impressed with how well opus did with such a small bitrate budget. While I was able to easily tell the difference between the 2, the quality of the opus encode was surprisingly good, and in some parts of the song it was actually difficult to hear the differences. I'm pretty sure if I bumped opus to 64Kbps I'd be hard pressed to ABX them on this gear. I'll try it with decent headphones when I get home tonight.

As a big fan of Vorbis, I've been watching the progress of this codec with great anticipation and hope it garners significant market share.
I really can't wait till my phone conversations sound crystal clear.

CODE

~/development$ opusinfo DT_Bridges.opus
Processing file "DT_Bridges.opus"...

New logical stream (#1, serial: 748363d4): type opus
Encoded with libopus 0.9.14
User comments section follows...
        ENCODER=opusenc from opus-tools 0.1.3

Opus stream 1:
        Pre-skip: 356
        Playback gain: 0dB
        Channels: 2
        Original sample rate: 44100Hz
        Packet duration:   20.0ms (max),   20.0ms (avg),   20.0ms (min)
        Page duration:   1000.0ms (max),  999.2ms (avg),  440.0ms (min)
        Total data length: 3797120 bytes (overhead: 1.35%)
        Playback length: 11m:01.426s
        Average bitrate: 45.93 kb/s, w/o overhead: 45.31 kb/s
Logical stream 1 ended

[Speckmade]

Now is really the time to get support into applications. 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.

Maybe not an application in the sense you had in mind, but...
Wikipedia and the other Wikimedia projects should support .opus files sooner or later, it seems to me. (With browser support emerging now it's even foreseeable to have them used for inline playback...)
- Wikimedia has a Bugzilla running that seems to be the right place for such requests. Maybe I'll try to file one myself soon if nobody else has felt more qualified or something by then...

[NullC]

Maybe not an application in the sense you had in mind, but...
Wikipedia and the other Wikimedia projects should support .opus files sooner or later, it seems to me. (With browser support emerging now it's even foreseeable to have them used for inline playback...)
- Wikimedia has a Bugzilla running that seems to be the right place for such requests. Maybe I'll try to file one myself soon if nobody else has felt more qualified or something by then...

It should be a one line configuration change to allow the extension. But it's probably worth waiting until Firefox ships a version with Opus on by default. In any case I'm pretty qualified to do so.

[punkrockdude]

Does anyone know and if someone is making an "in_opus.dll" for Foobar2000and if so how it is going? Regards.

[marc2003]

http://www.hydrogenaudio.org/forums/index....showtopic=88656

[IgorC]

http://www.hydrogenaudio.org/forums/index....showtopic=88656

obsolete, incompatible.

This post has been edited by IgorC: Jul 12 2012, 14:46

[marc2003]

ah sorry, i didn't realise that. but it could still be the place to ask for an update.

[Speckmade]

It should be a one line configuration change to allow the extension. But it's probably worth waiting until Firefox ships a version with Opus on by default.

So far they seem to be completely unaware of the new codec.
I guess in the end we definitely want inline playback support, which naturally depends on "player"/browser support, but it may not be essential for support to have inline playback support just yet. Wikimedia Commons is already useful as just a file repository; being able to embed the files directly into wiki pages is a feature on top.
Maybe it is reasonable to wait for player support nevertheless since it is bound to happen soon and we can then have it all at once.
But I was also more thinking in the direction of being ready at official prime time and at least giving them a first hint or so...
(For just that I should maybe rather drop a line on the discussion page of the help page about file format support first.)

[Garf]

ah sorry, i didn't realise that. but it could still be the place to ask for an update.

Peter is working on it, so foobar2000 will likely have support "soon".

[Clifoo]

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.

I really hope to see Opus decoder in the following version of Rockbox.

[saratoga]

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.

I really hope to see Opus decoder in the following version of Rockbox.

Getting a usable decoder in rockbox will probably be a fair amount of work, and right now no one is working on it, so I think it'll be a little longer then that. But hopefully we'll have it eventually.

[Peter]

Out-of-the-box Opus support now added to foobar2000 [ download beta version ].
Enjoy.

[LithosZA]

Out-of-the-box Opus support now added to foobar2000 [ download beta version ].
Enjoy.

AWESOME!

[IgorC]

Out-of-the-box Opus support now added to foobar2000 [ download beta version ].
Enjoy.

Thank You Very Much!

[eahm]

So, I didn't follow the development of this codec but I see everyone excited and I have to ask. Why? Is Opus supposed to be the "patent free AAC LC/HE/HEv2" quality as OGG Vorbis was supposed to be the "patent free MP3"?

This post has been edited by eahm: Jul 16 2012, 21:33