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

[LoRd_MuldeR]

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]

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

[tebasuna51]

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]

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]

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]

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

[Gravitator]

С наступающим :)
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]

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]

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]

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]

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.

[Gravitator]

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]

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 (https://files.videohelp.com/u/227452/16kHz%20and%2020kHz.7z)

[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.

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]

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]

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]

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]

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]

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 (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]

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 (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]

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]

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]

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

[IgorC]

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]

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]

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]

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]

OP updated.

[Gravitator]

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]

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]

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]

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]

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]

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]

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]

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]

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]

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]

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?

[redbtn]

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]

It's at HydrigenAudio, Opus subforum.

________________________
Sent from my phone using Tapatalk

[qyot27]

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]

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]

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]

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.