[Updated 2019] Opus 1.3. New WebM audio codec (Opus+VP9/AV1)

[IgorC]

Opus 1.3
http://opus-codec.org/

http://upload.wikimedia.org/wikipedia/commons/thumb/0/02/Opus_logo2.svg/320px-Opus_logo2.svg.png


Demos
(version 1.1)http://people.xiph.org/~xiphmont/demo/opus/demo3.shtml
(version 1.2) https://people.xiph.org/~jm/opus/opus-1.2/
(version 1.3) https://people.xiph.org/~jm/opus/opus-1.3/

Previously Opus has shown excellent results beating LC-AAC, HE-AAC v1, HE-AAC v2 and Vorbis.

Public Multiformat Listening Test @ ~64 kbps [March 2011] (http://forum.doom9.org/showthread.php?t=160185)
Public Multiformat Listening Test @ ~96 kbps [2014] (http://listening-test.coresv.net/results.htm)

Official builds of Opus 1.3 stable

Win64 https://archive.mozilla.org/pub/opus/win64/opus-tools-0.2-opus-1.3-win64.zip

Win32 https://archive.mozilla.org/pub/opus/win32/opus-tools-0.2-opus-1.3.zip

Playback

You can play Opus files on your Android/Apple iOS/Windows Phone smartphones/tablets via foobar2000 http://mobile.foobar2000.com/

Many players as MPC, VLC, foobar2000 (Windows, Android, iOS, Windows Phone) support Opus format as well as Rockbox (a firmware for portable players). https://www.rockbox.org/

For more information
http://wiki.hydrogenaud.io/index.php?title=Opus

[LoRd_MuldeR]

Opus v1.1 has finally been released :)

For info see here:
http://xiph.org/~xiphmont/demo/opus/demo3.shtml

Fresh builds can be found here:
http://sourceforge.net/projects/muldersoft/files/Opus%20Tools/

[IgorC]

Have updated the OP and links to official binaries.

[SeeMoreDigital]

What do people think about Opus's surround sound encoding capabilities?

[Brazil2]

Fresh builds can be found here:
http://code.google.com/p/mulder/downloads/detail?name=opus-tools.2013-12-06.zip&can=2&q=
I've tried your SSE2 x86 build and compared it with the official build from Opus-tools v0.1.8.
As expected, your build is a bit faster than the Xiph one, however it writes 60 bytes less when encoding the same source file on the same machine:

Xiph:
Encoding using libopus 1.1 (audio)
-----------------------------------------------------
Encoded: 44 minutes and 53.6 seconds
Runtime: 1 minute and 24 seconds
(32.07x realtime)
Wrote: 43510600 bytes, 134680 packets, 2696 pages


Mulder:
Encoding using libopus 1.1-SSE2 [2013-12-06] (audio)
-----------------------------------------------------
Encoded: 44 minutes and 53.6 seconds
Runtime: 1 minute and 21 seconds
(33.25x realtime)
Wrote: 43510540 bytes, 134680 packets, 2696 pages

Perhaps you can find some usefull info about that here:
http://www.hydrogenaudio.org/forums/index.php?showtopic=101764&view=findpost&p=851264
http://www.hydrogenaudio.org/forums/index.php?showtopic=101764&view=findpost&p=851337
http://www.hydrogenaudio.org/forums/index.php?showtopic=101764&view=findpost&p=851357

[the_weirdo]

@Brazil2

According to Jean-Marc Valin (http://www.hydrogenaudio.org/forums/index.php?showtopic=101764&view=findpost&p=851812), that may be due to rounding behaviour (with different optimization levels).

[Anakunda]

I would be interested how low can man go to keep transparent sound. Seems that effective ~210k still give superior quality on 6 channel audio.

surround with good quality at 128 kbps for 5.1 and usable down to 48 kbps

[LoRd_MuldeR]

According to Jean-Marc Valin (http://www.hydrogenaudio.org/forums/index.php?showtopic=101764&view=findpost&p=851812), that may be due to rounding behaviour (with different optimization levels).

Either that, or the phase of the moon. 60 bytes more/less on a 43510600 bytes file is a difference of 0.00014 percent - which is pretty much nothing ;)

Not that a difference in file size would mean anything. In theory, the bits could be distributed completely different and still the exactly same file size could be hit!

Instead, you should decompress both files to uncompressed Wave/PCM and then add the inverse of the one file to the other file (e.g. use "mix paste" in Audition).

As long as the result is silent - or at least very close to silent - there is no reason to be concerned. Furthermore, you could also try to ABX the files...

[EDIT]

I just converted a complete album (Chinese Democracy) to Opus format, once using the "i386" build and once using the "sse2" build. Both files came out at identical size.

Files were not identical by content. Of course, not. The encoder signature string already differs.

Next I decoded the "i386"-encoded file with the "sse2" decoder and the "sse2"-encoded file with the "i386" decoder, which should be the most extreme test case, I think.

The difference between the two decoded files is silent. There are a few minor peaks in a few places, but noting critical. Average RMS of the diff is -85.79 dB.

[the_weirdo]

Actually, I've discovered that if you compile Opus and Opus-tools with GCC, you can add "-fno-strict-aliasing" to CFLAGS to get the same (bit identical) results with -O level from 0 to 3. (Of course, it only applies when you're comparing the results encoded by the same machine.)

[LoRd_MuldeR]

FWIW, here's a set of fresh Opus binaries made from current Git Master:
http://sourceforge.net/projects/muldersoft/files/Opus%20Tools/opus-tools.2014-04-13.zip/download

[Kurtnoise]

fyi, Opus Audio format has been validated by mp4ra.org (http://www.mp4ra.org/codecs.html)...and a draft is in progress (http://vfrmaniac.fushizen.eu/contents/opus_in_isobmff.html) to encapsulate Opus files into MP4.

[SeeMoreDigital]

fyi, Opus Audio format has been validated by mp4ra.org (http://www.mp4ra.org/codecs.html)...and a draft is in progress (http://vfrmaniac.fushizen.eu/contents/opus_in_isobmff.html) to encapsulate Opus files into MP4.
I've must admit I was not expecting this move. But I'll take it ;)

[filler56789]

Let's see how much time the GPAC team will take to implement the idea...

since they don't care at all about VC-1 and DTS in MP4 :rolleyes:

[Kurtnoise]

Let's see how much time the GPAC team will take to implement the idea...


http://sourceforge.net/p/gpac/feature-requests/59/

[Kurtnoise]

fyi, Opus Audio format has been validated by mp4ra.org (http://www.mp4ra.org/codecs.html)...and a draft is in progress (http://vfrmaniac.fushizen.eu/contents/opus_in_isobmff.html) to encapsulate Opus files into MP4.
Also, this has been added in vlc (http://git.videolan.org/?p=vlc.git;a=shortlog) few hours ago...

[nevcairiel]

Opus in MP4 is still a draft, and VLC adding a potentially unfinished draft just seems like a not-well-thoughtout move. At least they only demux and don't mux files which may be wrong eventually...

[Selur]

Not sure if this a a playback or a 'I'm just stupid' king of bug.
I'm using:
ffmpeg -y -threads 8 -loglevel fatal -i "H:\Output\test.ac3" -ac 6 -ar 48000 -f sox - | sox --multi-threaded --ignore-length --temp "H:\Temp" --buffer 524288 -S -t sox - -b 16 -t wav - | opusenc --bitrate 192 --comp 10 --framesize 20 --expect-loss 0 --max-delay 1000 --ignorelength --raw-bits 16 --raw-rate 48000 --raw-chan 6 - "H:\Output\test.opus"
to convert an .ac3 into an .opus file. (uploaded both to: https://drive.google.com/folderview?id=0B_WxUS1XGCPAM2wxdThlUnd3Yms&usp=sharing)
Reencoding seems to work fine, but upon playback the channel order is wrong lfe comes through the front right box.
-> My guess is that I either need to rearrange the channels before encoding or there is a problem with the decoding through MPC-HC.

[Anakunda]

Reencoding seems to work fine, but upon playback the channel order is wrong lfe comes through the front right box.
-> My guess is that I either need to rearrange the channels before encoding or there is a problem with the decoding through MPC-HC.

That's right the order in Ur conversion is messed.
Try play this: http://www6.zippyshare.com/v/50RpBiHm/file.html

eac3to test.ac3 stdout.wav -normalize | opusenc --ignorelength --vbr --comp 10 --bitrate 192 - test.opus

[SeeMoreDigital]

That's right the order in Ur conversion is messed.
Try play this: http://www6.zippyshare.com/v/50RpBiHm/file.html

eac3to test.ac3 stdout.wav -normalize | opusenc --ignorelength --vbr --comp 10 --bitrate 192 - test.opus
I can confirm that the 'LAV Audio Decoder' (v0.63.0) plays/presents the channels in the correct order ;)

EDIT: The last time I checked, LameXP was able to correctly assign the channel order...

[Selur]

Okay, then ffmpeg probably doesn't adjust the channel order is '-f sox' is used.
Thanks for the feedback. :)

[Selur]

When I call:
ffmpeg -y -threads 8 -loglevel fatal -i "H:\Output\test.ac3" -ac 6 -ar 48000 -acodec pcm_s16le -f wav h:\Output\test.wav"
the channel order inside the test.wav file is okay, when I call:
ffmpeg -y -threads 8 -loglevel fatal -i "H:\Output\test.ac3" -ac 6 -ar 48000 -acodec pcm_s16le -f wav - > h:\Output\pipe.wav"
the channel order inside the pipe.wav file is okay, when I call:
ffmpeg -y -threads 8 -loglevel fatal -i "H:\Output\test.ac3" -ac 6 -ar 48000 -acodec pcm_s32le -f wav - | sox --multi-threaded --ignore-length --temp "H:\Temp" --buffer 524288 -S -t wav - -b 16 -t wav h:\Output\sox.wav
the channel order inside the sox.wav file is okay, when I call:
opusenc --bitrate 192 --comp 10 --framesize 20 --expect-loss 0 --max-delay 1000 h:\Output\sox.wav "H:\Output\test.opus"
the channel order of the test.opus file is okay, when I call:
ffmpeg -y -threads 8 -loglevel fatal -i "H:\Output\test.ac3" -ac 6 -ar 48000 -f sox - | sox --multi-threaded --ignore-length --temp "H:\Temp" --buffer 524288 -S -t sox - -t wav h:\Output\sox2.wav
the channel order of the sox2.wav file is okay, when I call:
ffmpeg -y -threads 8 -loglevel fatal -i "H:\Output\test.ac3" -ac 6 -ar 48000 -f sox - | sox --multi-threaded --ignore-length --temp "H:\Temp" --buffer 524288 -S -t sox - -t wav -b 16 - | opusenc --bitrate 192 --comp 10 --framesize 20 --expect-loss 0 --max-delay 1000 --ignorelength --raw-bits 16 --raw-rate 48000 --raw-chan 6 - "H:\Output\test.opus
the channel order is messed up.
Using:
ffmpeg -y -threads 8 -loglevel fatal -i "H:\Output\test.ac3" -ac 6 -ar 48000 -f sox - | sox --multi-threaded --ignore-length --temp "H:\Temp" --buffer
524288 -S -t sox - -t raw -b 16 - | opusenc --bitrate 192 --comp 10 --framesize 20 --expect-loss 0 --max-delay 1000 --ignorelength --raw --raw-bits 16 --raw-rate 48000 --raw-chan 6 - "H:\Output\test.opus"
channels are still messed up, but in another way.

Checked LameXP, and from the look of it, LameXP avoids the problem by creating a temporal wav file. :(

Found a workaround by using flac as intermediate: :D
ffmpeg -y -threads 8 -loglevel fatal -i "H:\Output\test.ac3" -ac 6 -ar 48000 -f sox - | sox --multi-threaded --ignore-length --temp "H:\Temp" --buffer 524288 -S -t sox - -t flac - | opusenc --bitrate 192 --comp 10 --framesize 20 --expect-loss 0 --max-delay 1000 --ignorelength - "H:\Output\test.opus"
alternatively if sox isn't used
ffmpeg -y -threads 8 -loglevel fatal -i "H:\Output\test.ac3" -ac 6 -ar 48000 -f flac - | opusenc --bitrate 192 --comp 10 --framesize 20 --expect-loss 0 --max-delay 1000 --ignorelength - "H:\Output\test.opus"
in both cases the channel order is correct. :)

Cu Selur

[Kurtnoise]

This looks silly to me...why you do not use the libopusenc directly in FFmpeg ?

[Selur]

Since I normally use sox for filtering. :)
Yes, I could probably decode with ffmpeg pipe to sox and then pipe to ffmpeg and use that for encoding.

[Reino]

@ Selur:
ffmpeg.exe -hide_banner -i test.ac3 -af "aresample=resampler=soxr:osr=48000:precision=28" -c:a libopus -vbr 0 -b:a 192k test.opus

or

ffmpeg.exe -hide_banner -i test.ac3 -c:a pcm_f32le -f wav - | sox.exe -t wav - -t wav - rate -v 48k | opusenc.exe --bitrate 192 - test.opus

[LoRd_MuldeR]

Does anybody know what's going on with Opus development? Is it considered "mature" now? Have the core developers even moved on to another project?

I ask, because since v1.1, which contained huge improvements and was released more than a year ago, development has mostly ceased. At least judging from what's visible in official Git repository.

(In the last couple of months, there were mostly documentation updates and some smaller fixes. I also see no activity in any of the development branches)

[Selur]

through https://www.youtube.com/watch?v=Dmho4gcRvQ4 which is mainly about Daala it sounded like opus is kind of finished

[foxyshadis]

It's all arm/neon optimizations now. There's no effort being put into quality improvement, maybe it's seen as good enough; we'll probably have to wait for someone else, the way 蒼弓 improved Vorbis so much. It's definitely mature and stable, though.

[Bloax]

I'm somewhat disappointed that the encoder has been practically dropped what with them having teased us multiple times with a two-pass "the encoder actually knows what's coming" mode.
:v

[LoRd_MuldeR]

FWIW, fresh Opus builds from Git Master:
http://sourceforge.net/projects/muldersoft/files/Opus%20Tools/opus-tools.2015-03-26.zip/download

[LoRd_MuldeR]

Fresh Opus v1.1.2 builds, for your pleasure:
https://sourceforge.net/projects/muldersoft/files/Opus%20Tools/opus-tools.2016-02-20.zip/download

[Brazil2]

Fresh Opus v1.1.2 builds, for your pleasure:
https://sourceforge.net/projects/muldersoft/files/Opus%20Tools/opus-tools.2016-02-20.zip/download
I was looking for recent OPUS builds which would run on XP without the need to hack them with an hex editor because they have been compiled without changing the MajorSubsystemVersion from 6 to 5 (http://www.msfn.org/board/topic/172970-why-not-a-valid-win32-application-xp-programs/).

These ones natively run on XP, thanks for doing it :)

[Reino]

Fresh Opus v1.1.2 builds, for your pleasure:
https://sourceforge.net/projects/muldersoft/files/Opus%20Tools/opus-tools.2016-02-20.zip/download
Thanks, LoRd_MuldeR.
Unfortunately Xiph didn't include the 32-bit float piping bug fix (see here (https://hydrogenaud.io/index.php/topic,103713.msg868589.html#msg868589) and here (http://forum.doom9.org/showthread.php?p=1685235#post1685235)) :(

[LoRd_MuldeR]

Thanks, LoRd_MuldeR.
Unfortunately Xiph didn't include the 32-bit float piping bug fix (see here (https://hydrogenaud.io/index.php/topic,103713.msg868589.html#msg868589) and here (http://forum.doom9.org/showthread.php?p=1685235#post1685235)) :(

Can you point me to the latest patch? Rarewares.org seems to have patched binaries, but no patch (or link to patch).

[LoRd_MuldeR]

Thanks, LoRd_MuldeR.
Unfortunately Xiph didn't include the 32-bit float piping bug fix (see here (https://hydrogenaud.io/index.php/topic,103713.msg868589.html#msg868589) and here (http://forum.doom9.org/showthread.php?p=1685235#post1685235)) :(

Please try this:
https://mega.nz/#!2ctTHSqS!SEs9Ln6987AdOFEDDACaUBVz0jyRORdDOmkW6wmYRWo

This should fix the Win32 seeking issue with pipe'd input.

[Reino]

It does. Thanks a lot!
In the meantime I've asked John Edwards to post the exact patch here, but it seems that's not necessary anymore.
I initially thought you were asking for the patch to approach Xiph with it. In my opinion this bug is important enough for them to include in the original git. Now you'd always have to patch it afterwards.

[LoRd_MuldeR]

In the meantime I've asked John Edwards to post the exact patch here, but it seems that's not necessary anymore.

Now I'm confused. The problem in the seek_forward() function (only with pipes and only on Win32), which was discussed in the thread you linked, clearly seems not fixed in latest Opus Tools (Git).

So is the patch still needed or not? :confused:

[Reino]

Sorry for the confusion. You're right. I actually meant it wasn't necessary anymore for John to post the patch in order for you to create patched builds, but for the official Opus Tools git it would still be appreciated if he would.
On the other hand, since your build now also work, you could do it as well. ;)

[Reino]

For those who can't download from MEGA.nz:
http://www.mediafire.com/download/00jvw3goex6fv6k/opus-tools.2016-02-20.pipe-fix.zip (http://www.mediafire.com/download/00jvw3goex6fv6k/opus-tools.2016-02-20.pipe-fix.zip)

[tebasuna51]

For those who can't download from MEGA.nz:
http://www.mediafire.com/download/00jvw3goex6fv6k/opus-tools.2016-02-20.pipe-fix.zip (http://www.mediafire.com/download/00jvw3goex6fv6k/opus-tools.2016-02-20.pipe-fix.zip)

LoRd_MuldeR update their upload at post http://forum.doom9.org/showthread.php?p=1757872#post1757872 , I think is already patched now.

Is correct?

[Brazil2]

For those who can't download from MEGA.nz:
http://www.mediafire.com/download/00jvw3goex6fv6k/opus-tools.2016-02-20.pipe-fix.zip (http://www.mediafire.com/download/00jvw3goex6fv6k/opus-tools.2016-02-20.pipe-fix.zip)
Thanks a lot ;)



LoRd_MuldeR update their upload at post http://forum.doom9.org/showthread.php?p=1757872#post1757872 , I think is already patched now.
Is correct?
This version doesn't have the piping bug fix.

[LoRd_MuldeR]

LoRd_MuldeR update their upload at post http://forum.doom9.org/showthread.php?p=1757872#post1757872 , I think is already patched now.

Is correct?

Nope. But I can do a full re-build with the patch included, if anybody can confirm that the problem does actually exist in the build without the patch and that is was fixed in the patched build.

[Overdrive80]

Hi, has opus mode lossless? If not, will it be implement any day? Thanks

[mariush]

If you want lossless, use FLAC. It's standardized, fast and supported on lots of devices.

[Overdrive80]

If you want lossless, use FLAC. It's standardized, fast and supported on lots of devices.

I know flac, but my question is for other reason... I want compare that encoder lossless is more efficient (in terms of compression factor) if opus would have mode lossless.

[Brazil2]

I want compare
http://wiki.hydrogenaud.io/index.php?title=Lossless_comparison

https://en.wikipedia.org/wiki/Comparison_of_audio_coding_formats

[foxyshadis]

Opus would not be suitable in any way as a lossless codec. It works as well as it does because it generates a lot of fake (but close enough) data, like HE-AACv2 but even deeper and extended all the way to perceptually lossless. Codecs designed from the ground up for lossless are much better at it, and neither of Opus's are.

[LoRd_MuldeR]

FWIW, here's another set of fresh Opus v1.1.x binaries:
opus-tools.2016-05-22.zip (https://sourceforge.net/projects/muldersoft/files/Opus%20Tools/opus-tools.2016-05-22.zip/download)

[LoRd_MuldeR]

Hi, has opus mode lossless? If not, will it be implement any day? ThanksOpus would not be suitable in any way as a lossless codec. It works as well as it does because it generates a lot of fake (but close enough) data, like HE-AACv2 but even deeper and extended all the way to perceptually lossless. Codecs designed from the ground up for lossless are much better at it, and neither of Opus's are.

Yeah, lossy and lossless audio formats work quite differently.

All the "lossless" audio codecs I know work in time domain. These codecs pretty much come down to: The encoder predicts the next sample value using some fancy prediction function and then transmits the delta (difference) to the actual sample value. The decoder performs the same prediction and then adds the transmitted delta value, in order to restore the original sample value. This is how FLAC, Monkey's Audio and friends work. Easy to see why this is lossless.

"Lossy" codes, on the other hand, typical work in frequency domain. First step is to transform the input samples from time domain into frequency domain. Then Psy-modelling is used to decide which frequency bands get more bits (e.g. more fine-grained quantization) and which get less bits (e.g. more coarse quantization). This is how MP3, AAC and friends work. The transform to the frequency domain and the inverse transform), which are typically done in floating-point math, probably already causes rounding errors that make the whole process non-lossless. And the quantization certainly makes it lossy. You could leave out the quantization, yes. But then compression probably sucks, because entropy coding won't save any bits.

[Motenai Yoda]

Well DTS-MA and TrueHD should work, even if in part, in the frequency domain.

[Brazil2]

FWIW, here's another set of fresh Opus v1.1.x binaries:
opus-tools.2016-05-22.zip (https://sourceforge.net/projects/muldersoft/files/Opus%20Tools/opus-tools.2016-05-22.zip/download)
Thanks for this :)

Just a little question though:

Previous version reported:
opusenc opus-tools v0.1.9-git SSE2 [2016-02-20] (using libopus 1.1.2-git SSE2 [2016-02-20])


While the new version reports:
opusenc opus-tools v0.1.9-git SSE2 [2015-05-22] (using libopus 1.1.x-git SSE2 [2015-05-22])

I assume libopus 1.1.2 is still used ?