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

[sneaker_ger]

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.

[stax76]

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

[LoRd_MuldeR]

Opus-Tools v0.1.10-9, using libOpus v1.2.1-35 (2017-11-16):
https://sourceforge.net/projects/mul...4.zip/download

[VincAlastor]

Originally Posted by LoRd_MuldeR

Opus-Tools v0.1.10-9, using libOpus v1.2.1-35 (2017-11-16):
https://sourceforge.net/projects/mul...4.zip/download

Did you found a mentioned opus 1.3 release already?

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

[LoRd_MuldeR]

Originally Posted by VincAlastor

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]

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]

Originally Posted by VincAlastor

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]

Originally Posted by tebasuna51

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

Originally Posted by tebasuna51

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

Originally Posted by LoRd_MuldeR

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]

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]

Originally Posted by VincAlastor

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

Originally Posted by VincAlastor

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.

Originally Posted by VincAlastor

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

Originally Posted by VincAlastor

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]

Originally Posted by tebasuna51

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, 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/d...-1_3_beta.html

[Gravitator]

С наступающим
Defect/rustling at a frequency of 16 kHz > OPUS v1.3b-0.1.1.7z

[IgorC]

Originally Posted by LoRd_MuldeR

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?

Originally Posted by Gravitator

С наступающим
Defect/rustling at a frequency of 16 kHz > OPUS v1.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]

Originally Posted by IgorC

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)