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

IgorC

18th July 2013, 18:12

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

6th December 2013, 16:36

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

7th December 2013, 04:23

Have updated the OP and links to official binaries.

SeeMoreDigital

7th December 2013, 14:51

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

Brazil2

9th December 2013, 10:15

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

9th December 2013, 11:07

@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

10th December 2013, 19:57

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

10th December 2013, 21:53

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

11th December 2013, 08:08

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

13th April 2014, 14:22

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

14th January 2015, 15:38

SeeMoreDigital

14th January 2015, 16:17

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

14th January 2015, 17:13

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

14th January 2015, 17:48

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

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

Kurtnoise

15th January 2015, 08:38

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

15th January 2015, 10:24

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

27th January 2015, 15:39

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

27th January 2015, 15:51

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

27th January 2015, 18:30

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

27th January 2015, 19:10

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

Selur

27th January 2015, 21:06

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

28th January 2015, 09:14

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

Selur

28th January 2015, 22:25

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

29th January 2015, 17:14

@ 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

30th January 2015, 20:01

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

30th January 2015, 20:34

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

foxyshadis

31st January 2015, 01:51

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

12th February 2015, 00:48

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

26th March 2015, 22:21

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

LoRd_MuldeR

20th February 2016, 14:25

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

20th February 2016, 16:21

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

20th February 2016, 17:22

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

20th February 2016, 18:08

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

20th February 2016, 18:46

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

20th February 2016, 19:37

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

21st February 2016, 12:23

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

21st February 2016, 12:35

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

24th February 2016, 21:48

tebasuna51

25th February 2016, 10:16

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

25th February 2016, 11:04

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

25th February 2016, 19:56

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

7th May 2016, 22:06

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

mariush

7th May 2016, 22:46

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

Overdrive80

8th May 2016, 14:17

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

8th May 2016, 17:00

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

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

foxyshadis

19th May 2016, 10:25

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

22nd May 2016, 13:42

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

22nd May 2016, 13:54

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

22nd May 2016, 19:21

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

Brazil2

22nd May 2016, 19:24

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 ?

LoRd_MuldeR

22nd May 2016, 19:43

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 ?

I built latest Git "master" branch. So this is actually post v1.1.2 release ;)

(I have no idea whether the next release will be v1.1.3 or v1.2.0 or v2.0.0, but currently PACKAGE_VERSION says "1.1.x-git")

Brazil2

22nd May 2016, 21:28

I built latest Git "master" branch. So this is actually post v1.1.2 release ;)
Thanks for the precision :)

IgorC

18th July 2016, 16:37

Some news :)

Version 1.1.3 released
https://www.opus-codec.org/

Neon optimizations improving performance on ARMv7 and ARMv8 by up to 15%
Fixes some issues with 16-bit platforms (e.g. TI C55x)
Fixes to comfort noise generation (CNG)
Documenting that PLC packets can also be 2 bytes
Includes experimental ambisonics work (--enable-ambisonics)

Work in progress 1.2 (quality improvements)

Reino

5th August 2016, 22:44

Motenai Yoda

6th August 2016, 04:17

Opus 1.1.3 compiled with mediaautobuild suite (gcc 6.x), x64 only
http://filenurse.com/download/b70a588cfbb0ac029c8c432788595f62.html
link will expire in a week

filler56789

29th August 2016, 05:29

Another up-to-date build of OpusTools
[compiled with GCC 4.8.5]

[C:\]
=> opusenc --version
opusenc opus-tools 0.1.9-24-g746e2af (using libopus 1.1.3)
Copyright (C) 2008-2013 Xiph.Org Foundation

http://forum.videohelp.com/threads/380225-OpusTools-1-1-3-for-Windows

hajj_3

3rd September 2016, 12:31

I hope that the opus developers concentrate on low bitrate audio as xhe-aac is far superior at 12-64kbps. Some digital radio platforms like DRM have support for this.

Gravitator

3rd September 2016, 13:14

Привет.
What improvement noticed through ambisonics?

IgorC

7th September 2016, 03:39

I hope that the opus developers concentrate on low bitrate audio as xhe-aac is far superior at 12-64kbps. Some digital radio platforms like DRM have support for this.

Last time I have tried Opus 1.1 at 64 kbps it was superior to best HE-AAC encoders 64 kbps and on par with xHE-AAC. Opus 1.1 was inferior to HE-AAC at 48 kbps.

But the situation is changing now. Several months ago Opus 1.2 (early alpha) was already at least on par or somewhat better than HE-AAC at 48 kbps.

Also xHE-AAC is a great format its main scope is 12-32 kbps.
Its performance is very close to normal HE-AAC at 48-64 kbps.
You can easily confuse xHE-AAC and highestly optimized HE-AAC (such as Fraunhofer Winamp's encoder) at 64 kbps.

It's very likely that upcoming Opus 1.2 will be at least on par with xHE-AAC at bitrates 48 kbps and higher. It also to expect a reasonable quality from it at 32-40 kbps.

Motenai Yoda

8th September 2016, 01:53

IIRC opus did some stuff on the lbr branch
did you compare opus vs hev2 or vs hev1 coz seems hev2 is still a bit better on 32-48kbps

IgorC

8th September 2016, 21:57

hajj_3

9th September 2016, 15:30

HE-AAC v2 is better than v1 up to ~36 kbps (valid for any encoder like Nero, Fraunhofer, Coding Techonologies).

v2 makes more harm than benefit at 48 kbps. http://www.mp3-tech.org/tests/aac_48/results.html While this test is pretty old the v2 and v1 encoders were already mature at that point. Nowadays the situation hasn't changed a little bit.

those tests are from 2006. This test from 2013 is better: http://www.iis.fraunhofer.de/content/dam/iis/de/doc/ame/wp/FraunhoferIIS_Technical-Paper_xHE-AAC.pdf

http://i.imgur.com/AKAu07I.png

another report: http://nprlabs.org/sites/nprlabs/files/documents/codec/20130920%20Streaming%20Codec%20Study%20Report.pdf

http://www.radioworld.com/Portals/0/rw-streaming%20codec%20figure%203.jpg

I can't find some diagrams with opus as a comparison, i saw some last year but cannot find the links.

IgorC

9th September 2016, 21:28

those tests are from 2006. This test from 2013 is better:http://www.iis.fraunhofer.de/content/dam/iis/de/doc/ame/wp/FraunhoferIIS_Technical-Paper_xHE-AAC.pdf

Let's put it straight. This information from the same organizations who push xHE-AAC and HE-AAC v2/v1. v2 is more expensive than v1 so it's convenient :)

Anyway Fraunhofer HE-AAC encoder (Winamp) uses
v2 - 32 kbps
v1 - 48 kbps.

It's possible to force v2 at 48 kbps but it's not recommended by the same AAC developers.

It's always possible to encode a few samples and listen for yourself.

LoRd_MuldeR

11th September 2016, 14:02

LoRd_MuldeR, could you compile a set of fresh post v1.1.3 binaries?

Here is set of fresh Opus v1.1.3 binaries:
opus-tools.2016-09-11.zip (https://sourceforge.net/projects/muldersoft/files/Opus%20Tools/opus-tools.2016-09-11.zip/download)

bilditup1

14th September 2016, 07:51

Here is set of fresh Opus v1.1.3 binaries:
opus-tools.2016-09-11.zip (https://sourceforge.net/projects/muldersoft/files/Opus%20Tools/opus-tools.2016-09-11.zip/download)

Thanks for taking the time to make these binaries LoRd_Mulder. However with this latest one, every time I try to encode from FLAC - any FLAC - I get the message "Error parsing input file", and the thing quits. This happens on each of the i686, sse2, and avx builds. Converting a WAV made from FLAC fixes this. The FLACs in question play without issue and were encoded using libflac 1.2.1 through 1.3.1. The FLACs have no issue being parsed by the two-year-old 0.1.9 release at the opus site and otherwise playback/decode just fine.

ED1: I have tried all of your builds going back to 20140413, and they all have the same issue. This lead me to believe I am doing something wrong, or that there is something about the way I generally encode that is causing problems. But I just made a few new FLACs from WAVs using libflac 1.3.1, no metadata or anything, and still your builds quit with the parsing error. It does not seem plausible to me that your builds have had this issue for 2+ years, so what am I missing? Some dependency or other?

ED2: I just tried the 1.1.3 build from videohelp and it failed with the same error. More googling revealed that FLAC support is only in the official build? That's the only thing that makes sense (it should not have taken me this long to figure out, anyway). You don't think you can bake in FLAC input support in your next build, do you LoRd_Mulder?

Brazil2

14th September 2016, 12:31

Last time I have tried Opus 1.1 at 64 kbps it was superior to best HE-AAC encoders 64 kbps and on par with xHE-AAC.

Also xHE-AAC is a great format its main scope is 12-32 kbps.
You can easily confuse xHE-AAC and highestly optimized HE-AAC (such as Fraunhofer Winamp's encoder) at 64 kbps.
Where do find xHE-AAC binaries (encoder and decoder) for Windows desktop (no app) ?

Here is set of fresh Opus v1.1.3 binaries:
opus-tools.2016-09-11.zip (https://sourceforge.net/projects/muldersoft/files/Opus%20Tools/opus-tools.2016-09-11.zip/download)
Thanks! :)

filler56789

14th September 2016, 12:59

........

ED2: I just tried the 1.1.3 build from videohelp and it failed with the same error. More googling revealed that FLAC support is only in the official build? That's the only thing that makes sense (it should not have taken me this long to figure out, anyway).

The binaries that I compiled do not support FLAC input, sorry.
I am not a big fan of the "dependency hell" around several FOSS libraries, such as FLAC, Ogg, Vorbis, and etc., so my "releases" are as simple as possible.

Brazil2

14th September 2016, 13:09

More googling revealed that FLAC support is only in the official build?
The Opusenc from the foobar2000 Free Encoder Pack (http://www.foobar2000.org/encoderpack) has FLAC support ;)
You can open it with 7-Zip.

LoRd_MuldeR

14th September 2016, 19:35

ED2: I just tried the 1.1.3 build from videohelp and it failed with the same error. More googling revealed that FLAC support is only in the official build? That's the only thing that makes sense (it should not have taken me this long to figure out, anyway). You don't think you can bake in FLAC input support in your next build, do you LoRd_Mulder?

I did not build opus-tools with libFLAC, because build these binaries primarily for use in LameXP, where built-in FLAC support is not needed. LameXP uses separate FLAC decoder ;)

(I may consider building with libFLAC next time)

bilditup1

16th September 2016, 23:23

The Opusenc from the foobar2000 Free Encoder Pack (http://www.foobar2000.org/encoderpack) has FLAC support ;)
You can open it with 7-Zip.

Thanks for the heads-up - I'll stick with that for now.

I did not build opus-tools with libFLAC, because build these binaries primarily for use in LameXP, where built-in FLAC support is not needed. LameXP uses separate FLAC decoder ;)

(I may consider building with libFLAC next time)

Cool beans :)

Brazil2

22nd September 2016, 12:19

Last time I have tried Opus 1.1 at 64 kbps it was superior to best HE-AAC encoders 64 kbps and on par with xHE-AAC.

Also xHE-AAC is a great format its main scope is 12-32 kbps.
You can easily confuse xHE-AAC and highestly optimized HE-AAC (such as Fraunhofer Winamp's encoder) at 64 kbps.

Where to find xHE-AAC binaries (encoder and decoder) for Windows desktop (no app) ?
Binaries anyone ?

IgorC

11th October 2016, 01:21

No codec available no binaries but there is some information https://hydrogenaud.io/index.php/topic,109486.msg929358.html#msg929358

LoRd_MuldeR

16th October 2016, 14:30

hajj_3

4th November 2016, 09:16

opus 1.2 alpha changelog: https://www.opus-codec.org/release/dev/2016/11/03/libopus-1_2_alpha.html

Brazil2

4th November 2016, 11:26

No codec available no binaries but there is some information https://hydrogenaud.io/index.php/topic,109486.msg929358.html#msg929358
How do you encode your xHE-AAC/USAC samples for your listening tests then ?

Brazil2

4th November 2016, 12:40

Here is a set of fresh Opus v1.1.3 binaries:
opus-tools.2016-10-16.zip (https://sourceforge.net/projects/muldersoft/files/Opus%20Tools/opus-tools.2016-10-16.zip/download)
There have been some fixes in the Opus Git "master" since the last build. Also, this time, all 'opusenc' binaries have libFLAC enabled.

Here is a set of fresh Opus v1.2-alpha binaries:
opus-tools.2016-11-02.zip (https://sourceforge.net/projects/muldersoft/files/Opus%20Tools/opus-tools.2016-11-02.zip/download)
There have been some fixes in the Opus Git "master" since the last build. Also, this time, all 'opusenc' binaries have libFLAC enabled.
Thanks! :)

LoRd_MuldeR

4th November 2016, 18:59

Here is a set of fresh Opus v1.2-alpha binaries:
opus-tools.2016-11-04.zip (https://sourceforge.net/projects/muldersoft/files/Opus%20Tools/opus-tools.2016-11-04.zip/download)

There have been some fixes in the Opus Git "master" since the last build. Also, this time, all 'opusenc' binaries have libFLAC enabled.

IgorC

6th November 2016, 22:11

Opus 1.2 alpha outperforms HE-AACv2 at ~32 kbps VBR for the first time.

Scores of blind listening test at 32 kbps VBR:
1. Opus 1.2 alpha (exp-df24252) - 3.22
2. CELT (music) Mode - 3.28
3. HEAACv2 (FhG Winamp, VBR 1) - 2.92

https://hydrogenaud.io/index.php/topic,111798.msg930611.html#msg930611

hajj_3

7th November 2016, 11:48

IgorC

7th November 2016, 14:12

It also would be good if there will be any available xhe-aac encoder at all, now wouldn't it?

Sparktank

8th November 2016, 16:06

Here is a set of fresh Opus v1.2-alpha binaries:
opus-tools.2016-11-04.zip (https://sourceforge.net/projects/muldersoft/files/Opus%20Tools/opus-tools.2016-11-04.zip/download)

There have been some fixes in the Opus Git "master" since the last build. Also, this time, all 'opusenc' binaries have libFLAC enabled.

Thanks for this.
I might consider trying this out for mobile.

Reino

21st December 2016, 18:16

Here is a set of fresh Opus v1.2-alpha binaries:
opus-tools.2016-11-04.zip (https://sourceforge.net/projects/muldersoft/files/Opus%20Tools/opus-tools.2016-11-04.zip/download)
Hi, LoRd_MuldeR,

I'd appreciate it if you could include OpusTools-v0.1.9-PipeSeekFix.V1.diff for future builds, like you did here:
src/audio-in.c | 13 ++++++++++++-
1 file changed, 12 insertions(+), 1 deletion(-)

diff --git a/src/audio-in.c b/src/audio-in.c
index 8ed037b..6b08017 100644
--- a/src/audio-in.c
+++ b/src/audio-in.c
@@ -46,6 +46,7 @@
#include <stdio.h>
#include <string.h>
#include <sys/types.h>
+#include <sys/stat.h>
#include <math.h>

#include "stack_alloc.h"
@@ -142,9 +143,19 @@ input_format *open_audio_file(FILE *in, oe_enc_opt *opt)
return NULL;
}

+static int is_regular_file(FILE *in)
+{
+ struct _stat file_info;
+ if(_fstat(_fileno(in), &file_info) == 0)
+ {
+ return ((file_info.st_mode & S_IFMT) == S_IFREG) ? 1 : 0;
+ }
+ return 0;
+}
+
static int seek_forward(FILE *in, unsigned int length)
{
- if(fseek(in, length, SEEK_CUR))
+ if((!is_regular_file(in)) || fseek(in, length, SEEK_CUR))
{
/* Failed. Do it the hard way. */
unsigned char buf[1024];

Btw, did you base this patch upon lvqcl's proposal (https://hydrogenaud.io/index.php/topic,103713.msg868660.html#msg868660), or nu774's proposal (https://hydrogenaud.io/index.php/topic,103713.msg868817.html#msg868817)?

LoRd_MuldeR

21st December 2016, 18:25

Hi, LoRd_MuldeR,

I'd appreciate it if you could include OpusTools-v0.1.9-PipeSeekFix.V1.diff for future builds, like you did

I think I never got a clear confirmation that the patch is still required and/or that my patch actually solved the problem, so I didn't bother ;)

Btw, did you base this patch upon lvqcl's proposal (https://hydrogenaud.io/index.php/topic,103713.msg868660.html#msg868660), or nu774's proposal (https://hydrogenaud.io/index.php/topic,103713.msg868817.html#msg868817)?

I used the opus-tools sources from "official" Xiph Git server:
https://git.xiph.org/?p=opus-tools.git;a=summary

Reino

21st December 2016, 20:10

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

This should fix the Win32 seeking issue with pipe'd input.It does. Thanks a lot!That's my confirmation that your fix worked. Guess you've overlooked that.
Now, I don't follow opus development by the minute and I only update every now and then. And admittedly, the use-case for this fix - piping 24/32bit float audio from FFMpeg to opusenc.exe - is a rare one, since most FFMpeg users would use FFMpeg's own libopus anyway, but deserves to be fixed nonetheless, if you ask me.
A shame Xiph hasn't officially merged this patch into their source-code.

LoRd_MuldeR

21st December 2016, 20:24

That's my confirmation that your fix worked. Guess you've overlooked that.
Now, I don't follow opus development by the minute and I only update every now and then. And admittedly, the use-case for this fix - piping 24/32bit float audio from FFMpeg to opusenc.exe - is a rare one, since most FFMpeg users would use FFMpeg's own libopus anyway, but deserves to be fixed nonetheless, if you ask me.
A shame Xiph hasn't officially merged this patch into their source-code.

Okay, I will include the patch again next time.

Note that the "opus" core library and the "opus-tools" (CLI front-ends) are two separate projects. While "opus" project is under active development, there's not much activity in "opus-tools" project.

(The patch in question concerns the "opus-tools" project)

hajj_3

10th January 2017, 14:59

Just found this pdf comparing AMR-WB, opus-tools 0.1.9 and the new EVS (Enhanced Voice Services) audio codec for voice and mixed content at low bitrates: http://resources.alcatel-lucent.com/asset/200002

EVS looks very impressive. It can support around 10% missed packets and still work without much interference, anyone know how good Opus is at coping with errors?

I wish they did a new test comparing Opus 1.2 Alpha.

Anakunda

10th January 2017, 17:07

EVS looks very impressive. It can support around 10% missed packets and still work without much interference
.

Nice, any trail to find a encoder/decoder source code or precompiled backends to try on own?

Sent from my phone by Tapatalk

hajj_3

23rd January 2017, 13:07

opus 1.2 alpha 2 is out now: http://downloads.xiph.org/releases/opus/opus-1.2-alpha2.tar.gz
Opus tools 0.1.10 is out too: http://downloads.xiph.org/releases/opus/opus-tools-0.1.10.tar.gz

SeeMoreDigital

23rd January 2017, 16:10

Out of interest...

How well is Opus doing in the 'big wide world'. Is there any hardware playback support for it yet?

VincAlastor

23rd January 2017, 16:49

Out of interest...

How well is Opus doing in the 'big wide world'. Is there any hardware playback support for it yet?

:search: & google

https://en.wikipedia.org/wiki/Opus_%28audio_format%29#Hardware

a little bit more respect to opus developers, thanks!

Maybe for you in your "big world" it would be better to stay with mp3 until 2050 - for over one year all other people enjoy high quality opus audio for example on the biggest video portal in the "big wide world" named youtube.

SeeMoreDigital

23rd January 2017, 18:50

Oh wow... that's told me (and told me) :p

VincAlastor

5th February 2017, 14:19

Okay, I will include the patch again next time.

Note that the "opus" core library and the "opus-tools" (CLI front-ends) are two separate projects. While "opus" project is under active development, there's not much activity in "opus-tools" project.

(The patch in question concerns the "opus-tools" project)

opus 1.2 alpha 2 is out now: http://downloads.xiph.org/releases/opus/opus-1.2-alpha2.tar.gz
Opus tools 0.1.10 is out too: http://downloads.xiph.org/releases/opus/opus-tools-0.1.10.tar.gz

would be very thankful for change log and windows avx builds :)

nakTT

6th February 2017, 04:04

opus 1.2 alpha 2 is out now: http://downloads.xiph.org/releases/opus/opus-1.2-alpha2.tar.gz
Opus tools 0.1.10 is out too: http://downloads.xiph.org/releases/opus/opus-tools-0.1.10.tar.gz
I believe some good samaritans already released windows executables.

Barough

6th February 2017, 17:40

Opus-tools v0.1.10 (using libopus 1.2-alpha2-4-gcfdaf365) (http://ge.tt/15q03hi2) (MSYS/MinGW, GCC 6.3.0, 32 & 64bit EXEs)

nakTT

7th February 2017, 13:23

Opus-tools v0.1.10 (using libopus 1.2-alpha2-4-gcfdaf365) (http://ge.tt/15q03hi2) (MSYS/MinGW, GCC 6.3.0, 32 & 64bit EXEs)
Thanks for the sharing.:thanks:

Barough

10th February 2017, 16:22

Opus-tools v0.1.10 (using libopus 1.2-alpha2-6-gc5a84df8) (http://ge.tt/270lnki2) (MSYS/MinGW, GCC 6.3.0, 32 & 64bit EXEs)

nakTT

10th February 2017, 16:46

Opus-tools v0.1.10 (using libopus 1.2-alpha2-6-gc5a84df8) (http://ge.tt/270lnki2) (MSYS/MinGW, GCC 6.3.0, 32 & 64bit EXEs)
I have downloaded it and gave it a try. It works well, thanks.:thanks:

Barough

25th February 2017, 18:00

Opus-tools v0.1.10-1-gd0dc36b (using libopus 1.2-alpha2-25-g8056706f) (http://www45.zippyshare.com/v/mFUlp2ZD/file.html) (MSYS/MinGW, GCC 6.3.0, 32 & 64bit EXEs)

LoRd_MuldeR

28th February 2017, 17:52

That's my confirmation that your fix worked. Guess you've overlooked that.
Now, I don't follow opus development by the minute and I only update every now and then. And admittedly, the use-case for this fix - piping 24/32bit float audio from FFMpeg to opusenc.exe - is a rare one, since most FFMpeg users would use FFMpeg's own libopus anyway, but deserves to be fixed nonetheless, if you ask me.
A shame Xiph hasn't officially merged this patch into their source-code.

Looks like they have implemented a fix recently:
https://git.xiph.org/?p=opus-tools.git;a=commit;h=d0dc36b7318d13614d4854681d83e3d5123e9536

They use a somewhat different way to check whether the FILE is a "regular" file or a pipe - a way that requires using Win32 API directly - but the result should be the same.

VincAlastor

16th March 2017, 19:04

Opus-tools v0.1.10-1-gd0dc36b (using libopus 1.2-alpha2-25-g8056706f) (http://www45.zippyshare.com/v/mFUlp2ZD/file.html) (MSYS/MinGW, GCC 6.3.0, 32 & 64bit EXEs)

:thanks:

Barough

17th March 2017, 17:46

Opus-tools v0.1.10-1-gd0dc36b (using libopus 1.2-alpha2-29-gc293dede)
Built on Mar 17, 2017, GCC 6.3.0

Opus-tools v0.1.10-1-gd0dc36b (using libopus 1.2-alpha2-29-gc293dede) (http://www51.zippyshare.com/v/cuVUi1qn/file.html) (MSYS/MinGW, GCC 6.3.0, 32 & 64bit EXEs)

https://git.xiph.org/?p=opus.git;a=summary
https://git.xiph.org/?p=opus-tools.git;a=summary

VincAlastor

17th March 2017, 21:03

LoRd_MuldeR

18th March 2017, 21:58

FWIW, here is a set of fresh Opus v1.2-alpha2 binaries:
opus-tools.2017-03-18.zip (https://sourceforge.net/projects/muldersoft/files/Opus%20Tools/opus-tools.2017-03-18.zip/download)
https://www.mediafire.com/folder/w9d33485q6zxa/Opus_Tools

SSE2 and AVX optimized builds included. All 'opusenc' binaries have libFLAC support enabled.

Gravitator

19th March 2017, 12:36

Привет!
На улице весенний гололед :(
Poorly copes with the increased parameters of framesize > Download (https://files.videohelp.com/u/227452/Opus%201.2-RC1.7z)

VincAlastor

19th March 2017, 23:24

nakTT

20th March 2017, 05:57

Reino

24th March 2017, 10:59

Looks like they have implemented a fix recently:
https://git.xiph.org/?p=opus-tools.git;a=commit;h=d0dc36b7318d13614d4854681d83e3d5123e9536

They use a somewhat different way to check whether the FILE is a "regular" file or a pipe - a way that requires using Win32 API directly - but the result should be the same.FWIW, here is a set of fresh Opus v1.2-alpha2 binaries:
opus-tools.2017-03-18.zip (https://sourceforge.net/projects/muldersoft/files/Opus%20Tools/opus-tools.2017-03-18.zip/download)

Thanks, LoRd_MuldeR. It looks like 'OpusTools-v0.1.9-PipeSeekFix.V1.diff' isn't needed anymore, as piping 24/32bit float audio from FFMpeg to opusenc.exe now works without it indeed. ;)

VincAlastor

6th May 2017, 12:55

@LoRd_MuldeR thanks again for your builds and keeping us up to date :)

Built on 2017-05-05, by LoRd_MuldeR

https://www.videohelp.com/download/opus-tools.2017-05-05.zip

edit:

Built on 2017-05-06, by LoRd_MuldeR

https://www.videohelp.com/download/opus-tools.2017-05-06.zip

hajj_3

25th May 2017, 01:17

Opus 1.2 beta out now: https://www.opus-codec.org/release/dev/2017/05/24/libopus-1_2_beta.html

VincAlastor

27th May 2017, 10:27

Opus 1.2 beta out now: https://www.opus-codec.org/release/dev/2017/05/24/libopus-1_2_beta.html

windows build? :thanks:

Gravitator

27th May 2017, 10:46

Opus-tools-0.1.10-9-gbd65450 (using libopus 1.2-beta-6-g92422f6e)_x86_x64_gcc630.7z (https://hydrogenaud.io/index.php?action=dlattach;topic=113009.0;attach=11180)

VincAlastor

27th May 2017, 10:51

Opus-tools-0.1.10-9-gbd65450 (using libopus 1.2-beta-6-g92422f6e)_x86_x64_gcc630.7z (https://hydrogenaud.io/index.php?action=dlattach;topic=113009.0;attach=11180)

:thanks::thanks::thanks:

hajj_3

9th June 2017, 12:28

VincAlastor

10th June 2017, 10:21

Opus 1.2 RC1 out now. Changes compared to 1.2-beta include:

Improves quality on files with powerful tones that cause MDCT leakage
Improves bit allocation on mode transitions (CELT to/from SILK/hybrid)
More ARM Neon optimizations
Fixes to the speech/music detection at the very beginning of files
Fixes to the unit tests (fixes illegal instructions and –disable-static)

https://opus-codec.org/

x64 test builds:

https://hydrogenaud.io/index.php?action=dlattach;topic=114185.0;attach=11227

https://hydrogenaud.io/index.php?action=dlattach;topic=114185.0;attach=11224

Gravitator

10th June 2017, 11:35

My file is still very dirty coded with an improved Opus (not recommended to move away from the standard parameter framesize - 10) > Download (https://files.videohelp.com/u/227452/Opus%201.2-RC1.7z)

IgorC

10th June 2017, 22:10

It's recommended to use default frame size (20 ms).
Opus isn't x264 where "higher numbers" means better

LoRd_MuldeR

11th June 2017, 16:05

It's recommended to use default frame size (20 ms).
Opus isn't x264 where "higher numbers" means better

Actually there are a lot of options in x264 as well where you don't want to go too high (even if encoding speed doesn't matter), e.g. Deblock-Parameter, Psy-RDO, Psy-Trellis, AQ-Strength.

The conclusion has to be that one should never mess with an encoder option, unless the consequences are well understood/tested. Some info on tweaking the Opus frame size can be found here:
https://wiki.xiph.org/Opus_Recommended_Settings#Framesize_Tweaking

tl;dr:
„Unless operating at very low bitrates over RTP, there is no reason to use frame sizes above 20 ms [...] the default 20 ms frames are a good choice for most applications.“

IgorC

11th June 2017, 20:01

Correct, Lord_Murder.

More reason not to mess with some settings.

jmvalin

13th June 2017, 07:21

Correct, Lord_Murder.
More reason not to mess with some settings.

When it comes to Opus encoder settings, the fundamental design principle is that the default settings give you the optimal quality and then any options you specify means "I'm willing to get slightly worse quality in exchange for feature X". The feature X can be something like lower delay for real-time use, better robustness to packet loss, this rate management, ... If if you don't need anything special, you don't need any option -- well except for the target bitrate I guess.

Gravitator

13th June 2017, 10:04

It's recommended to use default frame size (20 ms).

Thank you for correcting me.
---------

You are the owner of audiophilesoft.ru (http://audiophilesoft.ru/) ?

IgorC

17th June 2017, 19:41

You are the owner of audiophilesoft.ru (http://audiophilesoft.ru/) ?
The admin is a mate Steve Forte Rio (hydrogenaudio member)

jmvalin

21st June 2017, 04:39

FYI, Opus 1.2 has just been released, along with a demo (https://people.xiph.org/~jm/opus/opus-1.2/) showing the recent improvements and how the quality and speed improved compared to 1.0 and 1.1.

hajj_3

23rd June 2017, 22:13

could a moderator update the title to v1.2 please.

nakTT

24th June 2017, 05:54

Finally, the 1.2 stable release is here.

Glad the hear the news.

This Opus 1.2 major release brings many quality improvements, new features, and bug fixes. You can read all the details in this release demo page. Changes since 1.1.x include:

- Speech quality improvements especially in the 12-20 kbit/s range
- Improved VBR encoding for hybrid mode
- More aggressive use of wider speech bandwidth, including fullband speech starting at 14 kbit/s
- Music quality improvements in the 32-48 kb/s range
- Generic and SSE CELT optimizations
- Support for directly encoding packets up to 120 ms
- DTX support for CELT mode
- SILK CBR improvements
- Support for all of the fixes in draft-ietf-codec-opus-update-06 (the mono downmix and the folding fixes need --enable-update-draft)
- Many bug fixes, including integer wrap-arounds discovered through fuzzing (no security implications)

There are no known regressions compared to the latest stable release (1.1.5). Please report any problems.

tebasuna51

24th June 2017, 10:30

could a moderator update the title to v1.2 please.

Update the title of first post correspond to owner, IgorC, than seems still a active Doom9 user.

Comments and links must be also modified to point to the new version to avoid confusions.

Like title was changed (not for me) I make some edit waiting to IgorC action.

IgorC

25th June 2017, 17:52

Thank You, tebasuna

I have modified the OP somewhat more.

Including this:
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/

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

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

IgorC

8th July 2017, 17:13

This Opus 1.2.1 minor release fixes a relatively rare issue where the 1.2 encoder would wrongly assume a signal to be bandlimited to 12 kHz and not encode frequencies between 12 and 20 kHz. This only happens on a few clips, but it is good to update to avoid a potential loss of quality.

There are no other changes compared to 1.2. Please report any problems.

Official builds

Win64 https://ci.appveyor.com/api/buildjobs/pd5jp1d0dv3ml1w7/artifacts/opus-tools.zip

Win32 https://ci.appveyor.com/api/buildjobs/0532d1twvfk2gwqm/artifacts/opus-tools.zip

You can also find some custom builds here
https://hydrogenaud.io/index.php/topic,114234.msg941283.html#msg941283

Midzuki

8th July 2017, 17:22

Official builds

Win64 https://ci.appveyor.com/api/buildjobs/pd5jp1d0dv3ml1w7/artifacts/opus-tools.zip

Win32 https://ci.appveyor.com/api/buildjobs/0532d1twvfk2gwqm/artifacts/opus-tools.zip

Thanks for the updated builds :thanks:

However both archives have the same filename...
not very wise, I must say.

IgorC

8th July 2017, 17:29

Midzuki
Yes, I've just posted links from a developer.

BTW I have also changed OP. Suggestions are welcome.
Hello,

It's a release of Opus 1.1 (UPDATED: and new 1.2.1)

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/

Previously Opus has shown excellent results beating LC-AAC, HE-AAC 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.2.1

Win64 https://ci.appveyor.com/api/buildjobs/pd5jp1d0dv3ml1w7/artifacts/opus-tools.zip

Win32 https://ci.appveyor.com/api/buildjobs/0532d1twvfk2gwqm/artifacts/opus-tools.zip

You can also find some custom builds here
https://hydrogenaud.io/index.php/topic,114234.msg941283.html#msg941283

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

tebasuna51

8th July 2017, 18:43

Thanks IgorC, it's OK.

nakTT

9th July 2017, 04:35

Midzuki
Yes, I've just posted links from a developer.

BTW I have also changed OP. Suggestions are welcome.
Thanks for the sharing.

Btw, what is the difference between version 1.2 and 1.2.1?

Thank you in advance.

sneaker_ger

9th July 2017, 08:18

See post #127.

nakTT

9th July 2017, 16:37

See post #127.
Thanks. I missed that post. My bad.

stax76

9th July 2017, 19:32

There is a issue with flac input files created with ffmpeg.

Sample file:

https://www.mediafire.com/?rde2k68hb5unlho

-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
Convert from DTSMA to FLAC using ffmpeg 3.3.1 x64
-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-

D:\Projekte\VS\VB\StaxRip\bin\Apps\ffmpeg\ffmpeg.exe -i "D:\Temp\StaxRip\JB_temp\JB ID2 1ms English.dtsma" -y -hide_banner -ac 6 "D:\Temp\StaxRip\JB_temp\JB ID2 1ms English.flac"

Input #0, dts, from 'D:\Temp\StaxRip\JB_temp\JB ID2 1ms English.dtsma':
Duration: N/A, start: 0.000000, bitrate: N/A
Stream #0:0: Audio: dts (DTS-HD MA), 48000 Hz, 5.1(side), s32p (24 bit)
Stream mapping:
Stream #0:0 -> #0:0 (dts (dca) -> flac (native))
Press [q] to stop, [?] for help
Output #0, flac, to 'D:\Temp\StaxRip\JB_temp\JB ID2 1ms English.flac':
Metadata:
encoder : Lavf57.71.100
WAVEFORMATEXTENSIBLE_CHANNEL_MASK: 0x3f
Stream #0:0: Audio: flac, 48000 Hz, 5.1, s32 (24 bit), 128 kb/s
Metadata:
encoder : Lavc57.89.100 flac
video:0kB audio:2211kB subtitle:0kB other streams:0kB global headers:0kB muxing overhead: 0.367996%

Start: 20:29:22
End: 20:29:23
Duration: 00:00:00

General
Complete name : D:\Temp\StaxRip\JB_temp\JB ID2 1ms English.flac
Format : FLAC
Format/Info : Free Lossless Audio Codec
File size : 2.17 MiB
Duration : 20 s 64 ms
Overall bit rate mode : Variable
Overall bit rate : 906 kb/s
Writing application : Lavf57.71.100

Audio
Format : FLAC
Format/Info : Free Lossless Audio Codec
Duration : 20 s 64 ms
Bit rate mode : Variable
Bit rate : 903 kb/s
Channel(s) : 6 channels
Channel positions : Front: L C R, Back: L R, LFE
Sampling rate : 48.0 kHz
Bit depth : 24 bits
Stream size : 2.16 MiB (100%)
Writing library : Lavf57.71.100

-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
Audio encoding using opusenc 1.2.1 x64
-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-

D:\Projekte\VS\VB\StaxRip\bin\Apps\opusenc\opusenc.exe --bitrate 160 --vbr "D:\Temp\StaxRip\JB_temp\JB ID2 1ms English.flac" "D:\Temp\StaxRip\JB_temp\JB ID2 1ms English_a1.opus"

Error parsing input file: D:\Temp\StaxRip\JB_temp\JB ID2 1ms English.flac

-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
Error Audio encoding using opusenc 1.2.1 x64
-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-

Audio encoding using opusenc 1.2.1 x64 failed with exit code: 1 (0x1)

stax76

9th July 2017, 19:34

Same problem with eac3to created FLAC files.

sneaker_ger

9th July 2017, 19:42

What build? Is it a build that's supposed to have FLAC support? Not all of them have it. If yes: any FLAC it does work with?

stax76

9th July 2017, 19:50

Even then there are still two issues, the help file says FLAC is supported:

1) opusenc reads audio data in Wave, AIFF, FLAC, Ogg/FLAC, or raw PCM format and encodes it into an Ogg Opus stream.

2) saying 'Error parsing input file' for an unsupported format isn't precise enough, it should say that the format isn't supported.

I've downloaded in the link posted in #129

When I run opusenc.exe I get:

The input format can be Wave, AIFF, or raw PCM.

Where can I get a 1.2.1 build with FLAC support?

sneaker_ger

9th July 2017, 20:07

1). Just call "opusenc.exe". It will tell you what input formats it supports. For the builds hotlinked in #129 it seems they don't support FLAC. Try the ones posted in the forum that's linked in the same post or build yourself.
2.) It may not be able to parse the input file for other reasons i.e. a file in a generally supported format but malformed. Saying something along the lines of "the format isn't supported" could be misleading.

stax76

9th July 2017, 20:13

Thanks, I found a build now.

stax76

9th July 2017, 21:01

Is any developer of opusenc reading here? I would like to request a normalize and a delay feature.

Can anybody tell me if there is a way to find out which version of the opus library is used by ffmpeg?

sneaker_ger

9th July 2017, 21:16

Are you using zeranoe's ffmpeg builds? He's already using 1.2.1. He lists the library versions at the bottom of his download site (https://ffmpeg.zeranoe.com/builds/).

stax76

9th July 2017, 21:22

I'll just scrap what I've worked the last 2 hours... :-(

LoRd_MuldeR

4th December 2017, 23:23

Opus-Tools v0.1.10-9, using libOpus v1.2.1-35 (2017-11-16):
https://sourceforge.net/projects/muldersoft/files/Opus%20Tools/opus-tools.2017-12-04.zip/download

VincAlastor

5th December 2017, 11:39

Opus-Tools v0.1.10-9, using libOpus v1.2.1-35 (2017-11-16):
https://sourceforge.net/projects/muldersoft/files/Opus%20Tools/opus-tools.2017-12-04.zip/download

:thanks:

Did you found a mentioned opus 1.3 release already?

https://public.etherpad-mozilla.org/p/daala-weekly-meeting

LoRd_MuldeR

5th December 2017, 14:48

Did you found a mentioned opus 1.3 release already?

Built straight from latest Git "master" branch. Probably that will be tagged as "v1.2.2" or maybe "v1.3" at some point...

VincAlastor

10th December 2017, 11:25

What's better for quality preserving encodes, in eac3to if requiered downmix to stereo and down sampling to 16 bit 48 KHz or let opusenc do this while encoding?

examples
eac3to stdout.wav -downstereo -down16 -resampleTo48000 | opusenc --ignorelength --bitrate 200 - %_.opus
or
eac3to stdout.wav | opusenc --downmix-stereo --ignorelength --bitrate 200 - %_.opus

tebasuna51

10th December 2017, 13:32

What's better for quality preserving encodes, in eac3to if requiered downmix to stereo and down sampling to 16 bit 48 KHz or let opusenc do this while encoding?

- Down sampling to 16 bit is not recommended at all.
- Resample to 48 KHz is only recommended if source have a greater samplerate. If not let the original samplerate.
- About the downmix method:

a) Seems than opusenc --downmix-stereo make this downmix:

FL' = 0.26xFL + 0.19xFC + 0.19xLFE + 0.23xSL + 0.13xSR
FR' = 0.26xFR + 0.19xFC + 0.19xLFE + 0.13xSL + 0.23xSR

- The mix uses normalized coeficients to avoid clip, but the output can be at low volume.
- Mix the LFE channel, not recommended always.
- Mix the surround channels like -downdpl (Dolby ProLogic)

b) With eac3to you can select your downmix method (-downdpl or -downstereo), add LFE (-mixlfe) or not, and -normalize to avoid clip and obtain the best volume.

My recommendation:

eac3to INPUT stdout.wav -downstereo -normalize | opusenc --ignorelength --bitrate 200 - OUTPUT.opus

(or COMMAND LINE in UsEac3to:
stdout.wav -downstereo -normalize | opusenc --ignorelength --bitrate 200 - %_.opus)

LoRd_MuldeR

10th December 2017, 15:31

- Down sampling to 16 bit is not recommended at all.

Generally agree. But he is going to compress it with Opus anyway.

While compressed audio doesn't really have a "bits per sample", as compressed audio doesn't store individual samples (it stores "frames", in frequency-domain), the average "bits per sample" in an Opus stream will probably be around ~2.

So, down-sampling to 16-Bit (from 24-Bit or 32-Bit FP) probably doesn't make a noticeable difference in this scenario, as the real "loss" happens in the Opus compression stage anyway.

- Resample to 48 KHz is only recommended if source have a greater samplerate. If not let the original samplerate.

Opus is a "48 KHz only" format, so anything not already 48 KHz will be up- or down-sampled to 48 KHz, by OpusEnc, before sending it to the actual Opus encoder library. OpusEnc uses its built-in Speex re-sampler for that job.

So, only reason to re-sample manually to 48 KHz before sending your audio to OpusEnc, IMO, would be if you want to use a different re-sampler than Speex...

tebasuna51

10th December 2017, 17:08

Opus is a "48 KHz only" format...

I didn't know.

By default eac3to uses SSRC (Shibatch) resampler, or r8brain resampler if you include the parameter -r8brain

VincAlastor

11th December 2017, 11:35

Thanks guys!
Without initiating a religious war, I would like to ask what is the better resampler. Speex or SSRC?
Can opus really receive and decode pro logic II information correctly?
And if I understand that correctly, it is better to let opus do a bit-down-sampling automatically if necessary, right?

edit:
ok, i've got the answer for what's the better resampler: it doesn't matter, you can't hear the better SOX/SSRC. Speex has no GPL conflict and that's ok.
https://hydrogenaud.io/index.php/topic,113655.0.html

LoRd_MuldeR

11th December 2017, 12:54

Thanks guys!
Without initiating a religious war, I would like to ask what is the better resampler. Speex or SSRC?

See here:
https://hydrogenaud.io/index.php/topic,113655.0.html

tl;dr: The "artifacts" introduced by Speex re-sampler probably are way too low (silent) to bother, considering the lossy compression that follows and that does far worse things ;)

https://i.imgur.com/8qK71gHl.jpg?1 (https://i.imgur.com/8qK71gH.jpg?1)

Can opus really receive and decode pro logic II information correctly?

I don't think OpusEnc handles Pro Logic II in any kind of way.

For OpusEnc your Pro Logic II input would simply be a Stereo source. So, you'd get a Stereo Opus file and it would still be up to the Pro Logic decoder to "split" the channels.

And if I understand that correctly, it is better to let opus do a bit-down-sampling automatically if necessary, right?

As said before, there is no real "bits per sample" in (lossy) compressed audio. Also, most loss, by far, is going to happen in the lossy compression stage.

So, down-sampling the source to 16-Bit before passing it to OpusEnc probably doesn't make an audible difference.

But I also see no reason why you should need to down-sample, as OpusEnc should be able to handle 16-Bit, 24-Bit and 32-Bit IEEE sources just fine...

(The data passed into the actual Opus encoder library (https://opus-codec.org/docs/opus_api-1.2/group__opus__encoder.html#gad2d6bf6a9ffb6674879d7605ed073e25) is a sequence of opus_int16 values, i.e. 16-Bit per sample, in any case!)

VincAlastor

11th December 2017, 13:23

ok, i understand, thanks.
Then tebasuna51's cmd recommendation is the right one for me. But for which input i should set -mixlfe?

tebasuna51

11th December 2017, 15:52

But for which input i should set -mixlfe?
From Mixing_Information_for_Dolby_Pro_Logic_II.pdf

"There are other concerns when adding an LFE signal to the mix. If the LFE is simply redistributed within the other channels of the mix, they will usually be subject to some low-frequency bandpass filtering. This filtering causes phase shifts of the LFE signal.
When they are acoustically added within a room, these phase shifts are fairly subtle and often go unnoticed.
However, when they are electronically added together with the five main channels in the encoder, they may produce less than desirable results at certain frequencies."

Dolby never recommend use the LFE channel in downmix, but of course is your choice.

VincAlastor

11th December 2017, 19:10

From Mixing_Information_for_Dolby_Pro_Logic_II.pdf

"There are other concerns when adding an LFE signal to the mix. If the LFE is simply redistributed within the other channels of the mix, they will usually be subject to some low-frequency bandpass filtering. This filtering causes phase shifts of the LFE signal.
When they are acoustically added within a room, these phase shifts are fairly subtle and often go unnoticed.
However, when they are electronically added together with the five main channels in the encoder, they may produce less than desirable results at certain frequencies."

Dolby never recommend use the LFE channel in downmix, but of course is your choice.

so less is more sometimes ^^ and i will use simply your recommendation cmd for stereo encoding with eac3to and opus.

For 5.1 encodes you wouldn't add eac3to --normalize to keep dynamic sound, right? Or keeps --normalize dynamic anyway?

tebasuna51

11th December 2017, 20:59

The normalize in eac3to is a Peak normalization (https://en.wikipedia.org/wiki/Audio_normalization#Peak_normalization), the dynamics are preserved.

But I recommend preserve the original volume when encode to 5.1.

hajj_3

22nd December 2017, 13:50

Opus 1.3 beta is out now: https://www.opus-codec.org/release/dev/2017/12/21/libopus-1_3_beta.html

Gravitator

28th December 2017, 19:54

С наступающим :)
Defect/rustling at a frequency of 16 kHz > OPUS v1.3b-0.1.1.7z (https://files.videohelp.com/u/227452/OPUS%20v1.3b-0.1.1.7z)

IgorC

31st December 2017, 20:18

Generally agree. But he is going to compress it with Opus anyway.

While compressed audio doesn't really have a "bits per sample", as compressed audio doesn't store individual samples (it stores "frames", in frequency-domain), the average "bits per sample" in an Opus stream will probably be around ~2.

Lossy encoders don't affect dynamic range. Some CD files (44.1/16) can even have 18-21 effective bits during 24-bits playbasck thanks to noise-shaping and Opus doesn't lower dynamic range (still 18-21 effective bits. Crazy thing, right?

С наступающим :)
Defect/rustling at a frequency of 16 kHz > OPUS v1.3b-0.1.1.7z (https://files.videohelp.com/u/227452/OPUS%20v1.3b-0.1.1.7z)
while it's my mother tongue. Please, English m English.

And this sample is useless as is. Nobody tests lossy audio codecs on tonal sweeps or video codec on a fancy square areas of different primary colors.

Provide a real content like music, speech, mix of both, ambiental, even some awkward art/noise stuff is acceptable.

Motenai Yoda

31st December 2017, 22:48

Lossy encoders don't affect dynamic range. Some CD files (44.1/16) can even have 18-21 effective bits during 24-bits playbasck thanks to noise-shaping and Opus doesn't lower dynamic range (still 18-21 effective bits. Crazy thing, right?
bit per sample and bitdepth are different things, as LoRd_MuldeR said bitpersample is ambigue as it should be derived from bitperframe aka framesize.
anyway bitdepth is a physical thing, 16 bit still is 16bit, sure it's able to handle < -96dB signals using noise shaping as Christopher Montgomery showed us, but it goes over 16bit only if you're taking quantization noise as a dynamic range limit for a given bitdepth.

Gravitator

1st January 2018, 12:19

See how in the problem area the bitrate drops sharply and then rises in tonal test.
Problems can be in the chain of work algorithm combination:
1. Quality of lowering or increasing the sampling rate of frequency resampling;
2. Thin or thick slices of framesize;
3. Thin or thick proportions of trimming high frequencies to the quality of the selected bitrate;
4. Algorithm of signal restoration;
5. Algorithm smoothing (tail signal);
6. Bitrate distribution.
-------------------------
Download with augmented audio file > OPUS v1.3b-0.1.1 (01.01.2018) (https://files.videohelp.com/u/227452/OPUS%20v1.3b-0.1.1%20%2801.01.2018%29.7z)

IgorC

1st January 2018, 16:19

Gravitator

1st January 2018, 19:48

Gravitator,

As I can see the issue was corrected. You can try this build https://hydrogenaud.io/index.php/topic,115156.msg950387.html#msg950387

It's already better for the music :)
I decided to get dusty Opus 1.1 vs 1.3b-0.1.1-2-gcc5a249 on the tones. The old one has two defects at 12 and 16 seconds (12kHz and 16kHz), while the new one has 16 seconds (16kHz).
> Download (https://files.videohelp.com/u/227452/OPUS%20v1.1%20vs%201.3b-0.1.1-gcc5a249.7z)

IgorC

2nd January 2018, 02:30

You should stop to consider sweep tones as test sample. Nobody cares ( even less developers) about pure tone samples.

Tones aren't a real scenario. Nobody listens pure tones as it was music.

You can have awful codec on pure tones but at the same time it will be the best for music/speech overall (and Opus is just this sort of codecs).

Gravitator

2nd January 2018, 14:50

In the file OPUS:
OPUS 1.1 - Big conflict 16kHz&17kHz&20kHz (perceived as quantization noise with 20sec), generated 20kHz (in the original it does not) - why spend the bitrate on the non-existent and not audible range!
OPUS 1.2 - 16kHz is shifted to 17kHz (from the beginning), a parasitic 20kHz is generated.
OPUS 1.3b - 16kHz is shifted to 17kHz (from the beginning), a parasitic 20kHz is generated.
> Download (https://files.videohelp.com/u/227452/16kHz%20and%2020kHz.7z)

IgorC

14th January 2018, 18:54

Gravitator,
You shouldn’t watch spectrograms but rather actually listen files by your own ears.

Tha same way You don’t watch spectrograms of videocodecs like H.264/H.265/VP9 codecs.
You will be horrified of what You can see there.

Rather try ABX in foobar2000 player to compare audio files.

In the file OPUS:
OPUS 1.1 - Big conflict 16kHz&17kHz&20kHz...
It’s perfectly normal and its how psychoacoustics works. Human ear is far from being perfect and would hardly (if at all) perceive such differences in 16-20 kHz range in real music.

why spend the bitrate on the non-existent and not audible range!

Opus allocates less than 1 kbps for frequencies >15.6 kHz (at overall bitrate 64 -80kbps). It’s very efficient.
And it gradually increases bitrate for higher frequencies when there is enough bits to spend with rate increasing.

Young people don’t like lowpassed audio (and tests confirm it) but even they can’t distinguish a lot of “details” there in HF (16kHz+) so a raw/approximate presentation (just energy) is already enough to make a good job. And that is what Opus does.

There are people behind Opus development who know how to do audio codecs.

Download (https://files.videohelp.com/u/227452/16kHz%20and%2020kHz.7z)
Any particular reason for hard-CBR? VBR is recommended as it always provides both at the same time: better quality and/or smaller size.
Also Opus ABR = AAC CBR

IgorC

27th January 2018, 14:35

bit per sample and bitdepth are different things, as LoRd_MuldeR said bitpersample is ambigue as it should be derived from bitperframe aka framesize.

Thank you to clarify it. I have interpreted the discussion about bitspersample wrong way.

Also if somebody want to try and report some quality changes between these two builds https://hydrogenaud.io/index.php/topic,115156.msg951485.html#msg951485

LoRd_MuldeR

4th February 2018, 15:48

FWIW, here is opus-tools 0.1.10-12 [Feb 4 2018] (using libopus 1.3-beta-2):
https://sourceforge.net/projects/muldersoft/files/Opus%20Tools/opus-tools.2018-02-04.zip/download

Atak_Snajpera

7th February 2018, 19:43

FWIW, here is opus-tools 0.1.10-12 [Feb 4 2018] (using libopus 1.3-beta-2):
https://sourceforge.net/projects/muldersoft/files/Opus%20Tools/opus-tools.2018-02-04.zip/download

Why so many variants? I doubt that AVX2 will be faster than plain SSE2. Have you done any speed tests?

LoRd_MuldeR

7th February 2018, 21:06

Why so many variants? I doubt that AVX2 will be faster than plain SSE2. Have you done any speed tests?

Yes, in my experience “higher” instruction set extensions are consistently faster:

Encoding using libopus 1.3-beta-2-g8299edfc IA32 [Feb 4 2018] (audio)

===============================================================================
TEST COMPLETED SUCCESSFULLY AFTER 5 METERING PASSES
-------------------------------------------------------------------------------
Mean Execution Time : 5.272 seconds
90% Confidence Interval : +/- 0.023 (0.431%) = [5.250, 5.295] seconds
95% Confidence Interval : +/- 0.027 (0.514%) = [5.245, 5.299] seconds
99% Confidence Interval : +/- 0.036 (0.675%) = [5.237, 5.308] seconds
Standard Deviation : 0.028 seconds
Standard Error : 0.014 seconds
Fastest / Slowest Pass : 5.245 / 5.310 seconds
===============================================================================
Encoding using libopus 1.3-beta-2-g8299edfc SSE2 [Feb 4 2018] (audio)

===============================================================================
TEST COMPLETED SUCCESSFULLY AFTER 5 METERING PASSES
-------------------------------------------------------------------------------
Mean Execution Time : 3.188 seconds
90% Confidence Interval : +/- 0.016 (0.514%) = [3.172, 3.204] seconds
95% Confidence Interval : +/- 0.020 (0.613%) = [3.168, 3.207] seconds
99% Confidence Interval : +/- 0.026 (0.805%) = [3.162, 3.214] seconds
Standard Deviation : 0.020 seconds
Standard Error : 0.010 seconds
Fastest / Slowest Pass : 3.162 / 3.218 seconds
===============================================================================
Encoding using libopus 1.3-beta-2-g8299edfc AVX1 [Feb 4 2018] (audio)

===============================================================================
TEST COMPLETED SUCCESSFULLY AFTER 5 METERING PASSES
-------------------------------------------------------------------------------
Mean Execution Time : 2.903 seconds
90% Confidence Interval : +/- 0.019 (0.668%) = [2.884, 2.923] seconds
95% Confidence Interval : +/- 0.023 (0.796%) = [2.880, 2.927] seconds
99% Confidence Interval : +/- 0.030 (1.046%) = [2.873, 2.934] seconds
Standard Deviation : 0.024 seconds
Standard Error : 0.012 seconds
Fastest / Slowest Pass : 2.874 / 2.936 seconds
===============================================================================
Encoding using libopus 1.3-beta-2-g8299edfc AVX2 [Feb 4 2018] (audio)

===============================================================================
TEST COMPLETED SUCCESSFULLY AFTER 5 METERING PASSES
-------------------------------------------------------------------------------
Mean Execution Time : 2.854 seconds
90% Confidence Interval : +/- 0.015 (0.519%) = [2.839, 2.869] seconds
95% Confidence Interval : +/- 0.018 (0.619%) = [2.836, 2.872] seconds
99% Confidence Interval : +/- 0.023 (0.813%) = [2.831, 2.877] seconds
Standard Deviation : 0.018 seconds
Standard Error : 0.009 seconds
Fastest / Slowest Pass : 2.839 / 2.884 seconds
===============================================================================

Note: The "SSE2" builds additionally have AVX runtime-detection enabled, the "AVX" builds additionally have AVX2 runtime-detection enabled, and the "AVX2" builds additionally have AVX512 runtime-detection enabled. The "IA32" builds are pure i686 builds without runtime-detection, because runtime-detection reproducibly crashes the binary on any CPU that lacks SSE2 support (i.e. SSE2 seems to be the minimum requirement for runtime-detection to work). Since my system supports SSE2, obviously, I can not give you "pure" SSE2 results - the "SSE2" build effectively uses AVX. However, since even going from AVX to AVX2 gives a nice little speed-up, I supposed that going from IA32 to SSE2 as well as going from SSE2 to AVX gives a noteworthy speed-up too. Also, since my system does not support AVX512, it is not much of a surprise that "AVX" and "AVX2" builds are on par, as both effectively use AVX2...

nevcairiel

7th February 2018, 21:48

LoRd_MuldeR

7th February 2018, 21:59

If there is the ability for runtime detection, why is there a need for AVX/AVX2 builds anyway, instead of just one build that uses as much as is available in the CPU (plus one that doesnt use anything, if its somehow broken otherwise)?

Well, I can select the target CPU arch for the “base” execution path, and I can select the target CPU arch for the “optimized” execution path. The latter will be selected or not, at runtime, depending on the CPU's actual capabilities. Also, allowing the “higher” instruction set extension to be used in the base path (instead of allowing it only to be used in the optimized path) should give some extra speed-up. That's because runtime CPU dispatching has some overhead, and the compiler decides for each function whether the potential speed-up of an optimized path outweighs that overhead or not. So, not every function gets an optimized path, but all functions benefit from “higher” instruction set extension in the base path...

IgorC

8th February 2018, 02:50

Reminder.

1.3 beta is only for tests and to report bugs.
1.2.1 well tested and recommended version.

LoRd_MuldeR

24th February 2018, 20:37

opusenc opus-tools 0.1.10-49
libopus 1.3-beta-15 | libopusenc 0.1.1-39 | libopusfile v0.10-7
opus-tools.2018-02-25.zip (https://sourceforge.net/projects/muldersoft/files/Opus%20Tools/opus-tools.2018-02-25.zip/download) (mirror (http://www.mediafire.com/file/ceeq49do2fk1h6k/opus-tools.2018-02-25.zip))

This is the revamped version of opus-tools, based on libopusenc and libopusfile – “which means opusenc is finally able to make use of the Opus delayed-decision feature to make better speech/music transitions.”

(Includes a custom patch (https://gist.github.com/anonymous/103196c96a7f795c37f2cabffe7dbf03) to show progress in 'opusdec' tool)

foxyshadis

27th February 2018, 10:10

Since my system crashed and I haven't had time to set up Visual Studio again, I guess I'll be using your builds again, Mulder. Thanks for still making them available! Have to stay on the bleeding edge somehow....

LoRd_MuldeR

7th April 2018, 19:50

opus-tools 0.1.10-51
libopus 1.3-beta-31 | libopusenc 0.1.1-43 | libopusfile v0.10-7
opus-tools.2018-04-07.zip (https://sourceforge.net/projects/muldersoft/files/Opus%20Tools/opus-tools.2018-04-07.zip/download) (mirror (http://www.mediafire.com/file/oaq5ra8h4sop982/opus-tools.2018-04-07.zip))

(Includes a custom patch (https://gist.github.com/lordmulder/694343f9c79bf746058b7c5ae64e1150) to show progress in 'opusdec' tool)

hajj_3

2nd June 2018, 11:44

Opus 1.3 RC1 released: https://www.opus-codec.org/release/dev/2018/06/01/libopus-1_3_rc.html

Changelog:

Making it possible to use SILK down to bitrates around 5 kb/s

Using wideband encoding down to 9 kb/s

Improving security (including a new –enable-hardening option)

Minor quality improvement on tones

Improving Ambisonics support (still experimental)

Minor bug fixes

LoRd_MuldeR

3rd June 2018, 13:28

opus-tools 0.1.10-71
libopus 1.3-rc-1 | libopusenc 0.1.1-47 | libopusfile v0.10-7
opus-tools.2018-06-03.zip (https://sourceforge.net/projects/muldersoft/files/Opus%20Tools/opus-tools.2018-06-03.zip/download) (mirror (http://www.mediafire.com/file/bzha4d4g93u2mj5/opus-tools.2018-06-03.zip))

(Includes a custom patch (https://gist.github.com/lordmulder/694343f9c79bf746058b7c5ae64e1150) to show progress in 'opusdec' tool)

hajj_3

19th September 2018, 15:44

Opus 1.3 RC2 is out: http://opus-codec.org/release/dev/2018/09/18/libopus-1_3_rc2.html

IgorC

19th September 2018, 18:36

https://hydrogenaud.io/index.php/topic,116618.msg962444/topicseen.html

Source code: opus-1.3-rc2.tar.gz
Win32 binaries: https://archive.mozilla.org/pub/opus/win32/opus-tools-0.2-win32.zip
Win64 binaries: https://archive.mozilla.org/pub/opus/win64/opus-tools-0.2-win64.zip

This is a second release candidate for the upcoming Opus 1.3. Changes include:
Fixing an issue with bandwidth detection
Enabling Ambisonics support by default
Using mapping families 2 and 3 for Ambisonics (instead of experimental families 253 and 254)
Enabling hardening by default

This release also comes with three other releases:
libopusenc 0.2
opusfile 0.11
opus-tools 0.2

With these releases, opus-tools now depends on both libopusenc for encoding and on opusfile for decoding. The main difference is that opusenc is now able to use look-ahead, which helps when encoding speech and music at low-ish bitrates. Please give all of these a try and report any problems.

Source code: opus-1.3-rc2.tar.gz
Win32 binaries: opus-tools-0.2-win32.zip
Win64 binaries: opus-tools-0.2-win64.zip

Edit: Add win64 binaries

LoRd_MuldeR

3rd October 2018, 14:57

opus v1.3-rc2+2
opus-tools v0.2+2 | libopusenc v0.2+2 | libopusfile v0.11+4
opus-tools.2018-10-03.zip (https://sourceforge.net/projects/muldersoft/files/Opus%20Tools/opus-tools.2018-10-03.zip/download) (mirror (http://www.mediafire.com/file/w3rmb17comc36ha/opus-tools.2018-10-03.zip/file))

(Includes a custom patch (https://gist.github.com/lordmulder/196760a3721a002cdd3f1c2a4a200eb0) to show progress in 'opusdec' tool!)

LoRd_MuldeR

14th October 2018, 19:50

opus v1.3-rc2+2
opus-tools v0.2+2 | libopusenc v0.2.1 | libopusfile v0.11+4
opus-tools.2018-10-14.zip (https://sourceforge.net/projects/muldersoft/files/Opus%20Tools/opus-tools.2018-10-14.zip/download) (mirror (https://www.mediafire.com/file/o56orl3zlw5784b/opus-tools.2018-10-14.zip/file))

(Includes a custom patch (https://gist.github.com/lordmulder/196760a3721a002cdd3f1c2a4a200eb0) to show progress in 'opusdec' tool!)

hajj_3

18th October 2018, 22:55

Opus 1.3 final is out now, please update title.

Changes since 1.2.x include:

Improvements to the VAD and speech/music classification using an RNN
Support for ambisonics coding using channel mapping families 2 and 3
Improvements to stereo speech coding at low bitrate
Using wideband encoding down to 9 kb/s
Making it possible to use SILK down to bitrates around 5 kb/s
Minor quality improvement on tones
Enabling the spec fixes in RFC 8251 by default
Security/hardening improvements
Notable bug fixes include:

Fixes to the CELT PLC
Bandwidth detection fixes

IgorC

22nd October 2018, 23:32

OP updated.

Gravitator

23rd October 2018, 08:42

Gravitator,

As I can see the issue was corrected. You can try this build https://hydrogenaud.io/index.php/topic,115156.msg950387.html#msg950387

The issue was present when native built-in resampler was used.

The old version is still better...
Is it possible to control the built-in resampler?
OPUS v1.3-beta1 encoder > opus-tools 0.1.10-2-gcc5a249-dirty (https://jmvalin.ca/misc_stuff/opus-tools-95c4871.zip)
OPUS v1.3-final encoder > opus-tools 0.2-3-gf5f571b (https://archive.mozilla.org/pub/opus/win32/opus-tools-0.2-opus-1.3.zip)
Test sample > OPUS 1.3-final vs 1.3-beta1
(https://files.videohelp.com/u/227452/OPUS%201.3-final%20vs%201.3-beta.7z)

LoRd_MuldeR

24th October 2018, 21:23

opus v1.3
opus-tools v0.2+3 | libopusenc v0.2.1 | libopusfile v0.11+4
2018-10-24.zip (https://sourceforge.net/projects/muldersoft/files/Opus%20Tools/opus-tools.2018-10-24.zip/download) (mirror (https://www.mediafire.com/file/wccyfbw83t91x7h/opus-tools.2018-10-24.zip/file))

(Includes a custom patch (https://gist.github.com/lordmulder/196760a3721a002cdd3f1c2a4a200eb0) to show progress in 'opusdec' tool!)

jmvalin

24th October 2018, 23:09

The old version is still better...
Is it possible to control the built-in resampler?
OPUS v1.3-beta1 encoder > opus-tools 0.1.10-2-gcc5a249-dirty (https://jmvalin.ca/misc_stuff/opus-tools-95c4871.zip)
OPUS v1.3-final encoder > opus-tools 0.2-3-gf5f571b (https://archive.mozilla.org/pub/opus/win32/opus-tools-0.2-opus-1.3.zip)
Test sample > OPUS 1.3-final vs 1.3-beta1
(https://files.videohelp.com/u/227452/OPUS%201.3-final%20vs%201.3-beta.7z)

So it appears that the issue has nothing to do with the resampler, but with the signal itself and (especially) the fact that it's 8-bit. When you give an 8-bit file to the encoder, it assumes that it's very noisy and that it can discard a lot of that noise. What probably happened in the "good" file is that the information about the bit depth just never made it to the encoder. As for the reason an external resampler "fixes" the problem, it's probably just because the resampler's output was a 16-bit file.

So there may still be something to do to improve the situation, but to be honest I'm not actually sure what would be the correct behaviour for 8-bit input.

hajj_3

13th April 2019, 14:01

Opus v1.3.1 is out:

libopus 1.3.1
Apr 12, 2019
This Opus 1.3.1 minor release fixes an issue with the analysis on files with digital silence (all zeros), especially on x87 builds (mostly affects 32-bit builds). It also includes two new features:

A new OPUS_GET_IN_DTX query to know if the encoder is in DTX mode (last frame was either a comfort noise frame or not encoded at all)
A new (and still experimental) CMake-based build system that is eventually meant to replace the VS2015 build system (the autotools one will stay).

LoRd_MuldeR

21st April 2019, 16:10

opus v1.3.1+1
libopusenc v0.2.1+2 | libopusfile v0.11+5 | opus-tools v0.2+3
opus-tools.2019-04-21.zip (https://sourceforge.net/projects/muldersoft/files/Opus%20Tools/opus-tools.2019-04-21.zip/download) (mirror (https://www.mediafire.com/file/nc8ei0x42346bdf/opus-tools.2019-04-21.zip/file))

(Includes a custom patch (https://pastebin.com/X5irLr4q) to show progress in 'opusdec' tool!)

redbtn

6th November 2019, 12:55

I will be grateful for the explanation how to correctly convert 5.1 or 7.1 to opus?
For example i have 7.1 flac file. I tried to convert through foobar2000 and ffmpeg, and i get Channel layout : L in both cases. What i'm doing wrong?

My bat file

ffmpeg.exe -i input.flac -c:a libopus -vbr on -b:a 512k -ac 8 -y -hide_banner output.opus

Audio
ID : 3035015489 (0xB4E6A941)
Format : Opus
Duration : 1 h 52 min
Channel(s) : 8 channels
Channel layout : L
Sampling rate : 48.0 kHz
Detected bit depth : 24 bits
Compression mode : Lossy
Writing library : Lavf58.29.100

Audio
Format : FLAC
Format/Info : Free Lossless Audio Codec
Duration : 1 h 52 min
Bit rate mode : Variable
Bit rate : 3 066 kb/s
Channel(s) : 8 channels
Channel layout : L R C LFE Lb Rb Ls Rs
Sampling rate : 48.0 kHz
Bit depth : 24 bits
Compression mode : Lossless
Stream size : 2.41 GiB (100%)
Writing library : libFLAC 1.3.2 (UTC 2017-01-01)

Anakunda

6th November 2019, 12:58

I will be grateful for the explanation how to correctly convert 5.1 or 7.1 to opus?

For example i have 7.1 flac file. I tried to convert through foobar2000 and ffmpeg, and i get Channel layout : L in both cases. What i'm doing wrong?

My bat fileCan you upload the source somewhere, or excerpt from it.

________________________
Sent from my phone using Tapatalk

redbtn

6th November 2019, 13:45

Can you upload the source somewhere, or excerpt from it.

I cut it by mkvtoolnix, but when i extract *.flac, for some reason it has the duration of the whole movie. But it doesn't matter, you can still reproduce it
https://drive.google.com/open?id=1Ys4dw04ai-6qvu6tTb3VCGOTLGz0TaEu

I can upload source, but it 2.4Gb.

Anakunda

6th November 2019, 14:48

I was able to convert all channels

General
Duration : 58 s 801 ms
Overall bit rate : 146 kb/s
Writing application : opusenc from opus-tools 0.2-3-gf5f571b
ENCODER_OPTIONS : --bitrate 128 --vbr --comp 10

Channel(s)_Original : 8 channels
Channel layout : L R C LFE Lb Rb Ls Rs
ChannelLayout_Original : FL
Sampling rate : 48.0 kHz
Detected bit depth : 24 bits
Compression mode : Lossy
Writing library : libopus 1.3, libopusenc 0.2.1

Probably Opus requires at least 16kbit per channel while defaulting to VBR@96k leaves only 12k for each channel, hence downmixing comes into effect. What are your encoder settings? Try to increase overall bitrate to 128k or more.

redbtn

6th November 2019, 14:56

I was able to convert all channels

General

Duration : 58 s 801 ms

Overall bit rate : 146 kb/s

Writing application : opusenc from opus-tools 0.2-3-gf5f571b

ENCODER_OPTIONS : --bitrate 128 --vbr --comp 10

Channel(s)_Original : 8 channels

Channel layout : L R C LFE Lb Rb Ls Rs

ChannelLayout_Original : FL

Sampling rate : 48.0 kHz

Detected bit depth : 24 bits

Compression mode : Lossy

Writing library : libopus 1.3, libopusenc 0.2.1

Probably Opus requires at least 16kbit per channel while defaulting to VBR@96k leaves only 12k for each channel, hence downmixing comes into effect. What are your encoder settings? Try to increase overall bitrate to 128k or more.Like I said my settings are
ffmpeg.exe -i input.flac -c:a libopus -vbr on -b:a 512k -ac 8 -y -hide_banner output.opus
So, 512kb should be enough. Can you share your script?

Anakunda

6th November 2019, 15:04

redbtn

6th November 2019, 16:38

Then problem lies in you frontend. Use opusenc instead

opusenc --bitrate 512 --vbr sample.flac sample.opus

Can you play this (https://1drv.ms/u/s!AhPPAclo1OfinHR3WaZx81W_O23r?e=supZYi) on all channels?Thank you very much! I used opus tools with your script and now it works good! Can I ask where you got latest opus tools? It looks like mine is older than yours.
First I downloaded from the official website, now I use LoRd_Mulder's build.

Anakunda

6th November 2019, 18:29

It's at HydrigenAudio, Opus subforum.

________________________
Sent from my phone using Tapatalk

qyot27

6th November 2019, 21:01

I will be grateful for the explanation how to correctly convert 5.1 or 7.1 to opus?
For example i have 7.1 flac file. I tried to convert through foobar2000 and ffmpeg, and i get Channel layout : L in both cases. What i'm doing wrong?

My bat file
The problem is mediainfo. The output from FFmpeg is correct and matches the output of opusenc, as shown by opusinfo. The only difference is the metadata written to the container.

The issue at hand is that opusenc seems to always write the WAVEFORMATEXTENSIBLE_CHANNEL_MASK= value to the file's metadata, whereas FFmpeg only does it if the channel layout does not match the default (apparently; that's what some of the kinda-related issues on FFmpeg's trac go with).

The Opus file sourced from sample.flac after encoding by opusenc has a value of WAVEFORMATEXTENSIBLE_CHANNEL_MASK=0X63F. If you demux the metadata from the FFmpeg-encoded opus file, paste that value into the metadata, then take the FFmpeg-encoded file and adjusted metadata file and remux them together with FFmpeg, mediainfo will 'see' the channel layout in the new file.

ffmpeg -i sample.flac -acodec libopus -vbr on -ab 512k ffmpeg.opus
Check ffmpeg.opus in mediainfo to show it's not seeing the layout.

Then check ffmpeg.opus in opusinfo and using ffmpeg -i to show that both of them still see the file as having all its channels.

Play it back in mpv to verify whether the layout is correct despite mediainfo not reporting it.
ffmpeg -i ffmpeg.opus -f ffmetadata metadata.txt
Add WAVEFORMATEXTENSIBLE_CHANNEL_MASK=0X63F to metadata.txt because that's what opusenc would output.
ffmpeg -i ffmpeg.opus -i metadata.txt -map_metadata 1 -c copy ffmpeg-new.opus
Check ffmpeg-new.opus with mediainfo to see that it is reporting the layout.

Now, if you do this and then the channel layout when being played back is wrong, then there's a bug that needs to be traced.

redbtn

7th November 2019, 12:18

The problem is mediainfo. The output from FFmpeg is correct and matches the output of opusenc, as shown by opusinfo. The only difference is the metadata written to the container.

The issue at hand is that opusenc seems to always write the WAVEFORMATEXTENSIBLE_CHANNEL_MASK= value to the file's metadata, whereas FFmpeg only does it if the channel layout does not match the default (apparently; that's what some of the kinda-related issues on FFmpeg's trac go with).

The Opus file sourced from sample.flac after encoding by opusenc has a value of WAVEFORMATEXTENSIBLE_CHANNEL_MASK=0X63F. If you demux the metadata from the FFmpeg-encoded opus file, paste that value into the metadata, then take the FFmpeg-encoded file and adjusted metadata file and remux them together with FFmpeg, mediainfo will 'see' the channel layout in the new file.

ffmpeg -i sample.flac -acodec libopus -vbr on -ab 512k ffmpeg.opus

Check ffmpeg.opus in mediainfo to show it's not seeing the layout.

Then check ffmpeg.opus in opusinfo and using ffmpeg -i to show that both of them still see the file as having all its channels.

Play it back in mpv to verify whether the layout is correct despite mediainfo not reporting it.

ffmpeg -i ffmpeg.opus -f ffmetadata metadata.txt

Add WAVEFORMATEXTENSIBLE_CHANNEL_MASK=0X63F to metadata.txt because that's what opusenc would output.

ffmpeg -i ffmpeg.opus -i metadata.txt -map_metadata 1 -c copy ffmpeg-new.opus

Check ffmpeg-new.opus with mediainfo to see that it is reporting the layout.

Now, if you do this and then the channel layout when being played back is wrong, then there's a bug that needs to be traced.I'll check it later. But, when I use foobar2000 (it uses opusenc for converting), I get the same result with only L channel. How to explain that?
And I have another question. If I convert the same file multiple times, I get files with identical size but different MD5. I thought maybe only metadata changes, and looked on files into hex editor. They are different. Opus makes different decisions every time and encodes differently?
(for example x265 or flac gives identical files)

PS: I found another weird thing, if I convert to flac via ffmpeg (instead of eac3to), and then convert to opus via opus-tools, the same thing happens (mediainfo shows only L channel)
I checked in hex editor and flac file produced by ffmpeg also doesn't have WAVEFORMATEXTENSIBLE_CHANNEL_MASK=0X63F

The same situation with
eac3to INPUT stdout.wav | opusenc --ignorelength --bitrate 512 - OUTPUT.opus

I'm sure I'm not the first who noticed it, but it seems I'm only one who's worried about it.

qyot27

8th November 2019, 00:15

foobar2000 is probably not giving the FLAC file directly to opusenc, but decoding it to PCM and either piping it into opusenc or using a temp Wave file.

This really does sound like something that needs to be reported to MediaInfo, though.

I don't know anything about libopus' determinism (or lack thereof) with its output from the same file.

redbtn

8th November 2019, 00:48

foobar2000 is probably not giving the FLAC file directly to opusenc, but decoding it to PCM and either piping it into opusenc or using a temp Wave file
Yes, I think so. Like eac3to does this with command line I've posted above.
It doesn't matter, I found that mkvtoolnix erases metadata from opus file. When I mux it into MKV, mediainfo shows "Channel L". And if I demux opus from MKV, files are not the same. It doesn't have Channel layout and information about encoder (and maybe something else). I tried to compare them into hex editor, but files are much different. I don't have enough knowledge in this area, and I don't know is it impact to playback or not. But I definitely don't like that I can't mux file into MKV and then demux and get the same file as it was.
It seems to me that I have to choose another encoder for converting my files (Unless someone can clarify this situation)
Anyway, thank you qyot27 for help.

qyot27

8th November 2019, 00:51

Ah, here it is in opusenc's manpage:
--serial n

Force use of a specific stream serial number, rather than one that is randomly generated. This is used to make the encoder deterministic for testing and is not generally recommended.
You could try forcing the serial number and see if that results in what you're wanting.

redbtn

8th November 2019, 01:04

Ah, here it is in opusenc's manpage:

--serial n

Force use of a specific stream serial number, rather than one that is randomly generated. This is used to make the encoder deterministic for testing and is not generally recommended.

You could try forcing the serial number and see if that results in what you're wanting.I don't know what number I should use. It seems to me like it just stream "ID", isn't it?

qyot27

8th November 2019, 01:08

If you look at opusinfo's output, serial numbers appear to be CRC32-style hashes:
E:\Documents>opusinfo test.opus | grep serial
New logical stream (#1, serial: dc7ac5e3): type opus

Boulder

23rd February 2021, 19:37

What is the proper way to re-encode a 3/1-channel track with Opus? At least Mediainfo thinks Opus maps two channels to the rear while the proper order is L R C Cb.

tebasuna51

23rd February 2021, 20:47

Seems opus only support these channels mapping:

5.1.1.2. Channel Mapping Family 1

Allowed numbers of channels: 1...8. Vorbis channel order.

Each channel is assigned to a speaker location in a conventional
surround arrangement. Specific locations depend on the number of
channels, and are given below in order of the corresponding channel
indices.

o 1 channel: monophonic (mono).

o 2 channels: stereo (left, right).

o 3 channels: linear surround (left, center, right).

o 4 channels: quadraphonic (front left, front right, rear left,
rear right).

o 5 channels: 5.0 surround (front left, front center, front right,
rear left, rear right).

o 6 channels: 5.1 surround (front left, front center, front right,
rear left, rear right, LFE).

o 7 channels: 6.1 surround (front left, front center, front right,
side left, side right, rear center, LFE).

o 8 channels: 7.1 surround (front left, front center, front right,
side left, side right, rear left, rear right, LFE).

filler56789

24th February 2021, 01:22

What is the proper way to re-encode a 3/1-channel track with Opus? At least Mediainfo thinks Opus maps two channels to the rear while the proper order is L R C Cb.

Vorbis, Opus, AAC, FLAC, are good only as replacements for the old Layer 3,
if you want PROPER multichannel encoding just go with AC3, DTS, MLP /TrueHD and DTS-HD.

Richard1485

24th February 2021, 02:55

Another option is to double the back channel and encode as 5.0.

Boulder

24th February 2021, 06:06

Another option is to double the back channel and encode as 5.0.

Yes, that's what I thought I'd have to do if Opus couldn't work with the original order. I recall that the eac3to thread had at least one case like this, just have to dig the magic Avisynth script from there :)

tebasuna51

24th February 2021, 11:57

You can use:

ffmpeg -i input310 -af "pan=5.0|FL=FL|FR=FR|FC=FC|BL=0.707BC|BR=0.707BC" -ab 192k output50.opus

But warning, MediaInfo v20.09 have a bug and inform output50.opus like:
Channel layout : L R Lb Rb LFE
a inexistent opus channel layout

But after decoded output50.opus by ffmpeg or opusdec have the correct channel mapping:
Channel layout : L R C Lb Rb

Boulder

24th February 2021, 13:19

Richard1485

24th February 2021, 16:15

Tebasuna has already provided an easy solution with ffmpeg, but if anyone wants to go from 4.0 to 5.0 with AviSynth:

#double back channel
fl=WavSource("l.wav")
fr=WavSource("r.wav")
c=WavSource("c.wav")
bc=WavSource("bc.wav").Amplify(0.707)# preserve global volume

MergeChannels(fl,fr,c,bc,bc)

Boulder

25th February 2021, 10:34

I think you also need to use Amplify(0.707) on those new rear channels.

tebasuna51

25th February 2021, 11:19

In order to obtain a correct channel mapping from AviSynth I recommend use BeHappy with this .avs:

a=LWLibavAudioSource("INPUT310")
fronts = GetChannel(a, 1, 2, 3)
back = GetChannel(a, 4).Amplify(0.707)
Mergechannels(fronts, back, back)

And check the ChMask option with a value of 55.
Now the AviSynth output is a WAVE_FORMAT_EXTENSIBLE with the correct channelmask and must be encoded correctly by any encoder compatible (ffmpeg,qaac,opus,flac,...)

[EDIT] If you don't want install BeHappy you can try this command line:

wavi INPUT310.avs - /M 55 | opusenc --ignorelength --bitrate 192 - output50.opus

I attach the last Chikuzen wavi encode (https://forum.doom9.org/showthread.php?p=1527102#post1527102)
There are also rewavi (https://forum.doom9.org/showthread.php?p=1829561#post1829561) with similar sintax:

rewavi INPUT310.avs - -x 55 | opusenc --ignorelength --bitrate 192 - output50.opus

Out of BeHappy the default AviSynth output is 16 bits, if you want more precission you can add to .avs the line:
global OPT_AllowFloatAudio=True

And also Avs2pipemod (http://avisynth.nl/index.php/Avs2pipemod)

Avs2pipemod INPUT310.avs -extwav=float | opusenc --ignorelength --bitrate 192 - output50.opus

It can work here because the default channel mask for 5 channels is 55 but Avs2pipemod can't supply the desired channel mask like wavi/rewavi

For big files maybe the wavi-AviSynth 32 bits can crash.