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

[IgorC]

Gravitator,

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

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

[Gravitator]

Originally Posted by IgorC

Gravitator,

As I can see the issue was corrected. You can try this build https://hydrogenaud.io/index.php/top...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

[IgorC]

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]

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

[IgorC]

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.

Originally Posted by Gravitator

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.

Originally Posted by Gravitator

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.

Originally Posted by Gravitator

Download

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]

Originally Posted by Motenai Yoda

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/top...html#msg951485

[LoRd_MuldeR]

FWIW, here is opus-tools 0.1.10-12 [Feb 4 2018] (using libopus 1.3-beta-2):
https://sourceforge.net/projects/mul...4.zip/download

[Atak_Snajpera]

Originally Posted by LoRd_MuldeR

FWIW, here is opus-tools 0.1.10-12 [Feb 4 2018] (using libopus 1.3-beta-2):
https://sourceforge.net/projects/mul...4.zip/download

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

[LoRd_MuldeR]

Originally Posted by Atak_Snajpera

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]

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)?

[LoRd_MuldeR]

Originally Posted by nevcairiel

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]

Reminder.

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

[LoRd_MuldeR]

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 (mirror)

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 to show progress in 'opusdec' tool)

[foxyshadis]

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]

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 (mirror)

(Includes a custom patch to show progress in 'opusdec' tool)

[hajj_3]

Opus 1.3 RC1 released: https://www.opus-codec.org/release/d...us-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]

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 (mirror)

(Includes a custom patch to show progress in 'opusdec' tool)

[hajj_3]

Opus 1.3 RC2 is out: http://opus-codec.org/release/dev/20...s-1_3_rc2.html

[IgorC]

https://hydrogenaud.io/index.php/top...topicseen.html

Source code: opus-1.3-rc2.tar.gz
Win32 binaries: https://archive.mozilla.org/pub/opus...-0.2-win32.zip
Win64 binaries: https://archive.mozilla.org/pub/opus...-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]

opus v1.3-rc2+2
opus-tools v0.2+2 | libopusenc v0.2+2 | libopusfile v0.11+4
opus-tools.2018-10-03.zip (mirror)

(Includes a custom patch to show progress in 'opusdec' tool!)