Skip to main content

Notice

Please note that most of the software linked on this forum is likely to be safe to use. If you are unsure, feel free to ask in the relevant topics, or send a private message to an administrator or moderator. To help curb the problems of false positives, or in the event that you do find actual malware, you can contribute through the article linked here.
Topic: Opus 1.3 is out! (Read 62462 times) previous topic - next topic
0 Members and 1 Guest are viewing this topic.

Re: Opus 1.3 is out!

Reply #50
Except you can't do that on Windows: OpenSSL is not commonly distributed with Windows.

Re: Opus 1.3 is out!

Reply #51
I just cross-compiled the Opus master branch (all xiph audio stuff actually) with mingw 8.2 on the fedora docker image. If someone wants to try it and compare with the official builds, it is attached.
As I said they were cross-compiled, so any self-tests were impossible, please test everything properly before replacing your converters with these ones.

Re: Opus 1.3 is out!

Reply #52
Opus-tools v0.2-3-gf5f571b (using libopus 1.3-8-g9791b22b)
Built on December 14, 2018, GCC 7.4.0(32bit)/8.2.1(64bit)

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


Re: Opus 1.3 is out!

Reply #54
1. Is there a reason why a resampler quality setting is not available when using opusenc instead of having to hard code it?
2. On Linux (have not tried other OS), I can't set --framesize 120 when using terminal but using freac and the system's own opusenc by deleting freacs own opusenc file works with --framesize 120. Why is it like this?

Thanks in advance.

Re: Opus 1.3 is out!

Reply #55
framesize 120 has no benefit over the default one, IIRC
or was that also changed recently?
a fan of AutoEq + Meier Crossfeed


Re: Opus 1.3 is out!

Reply #57
1. Is there a reason why a resampler quality setting is not available when using opusenc instead of having to hard code it?
2. On Linux (have not tried other OS), I can't set --framesize 120 when using terminal but using freac and the system's own opusenc by deleting freacs own opusenc file works with --framesize 120. Why is it like this?

Thanks in advance.

To answer #1, it's because of "no significant or audible differences". The only way to change the quality value is by modifying the code and recompiling. Unfortunately, I don't see the developers modifying this behavior, or approve a Pull Request that would enable such thing, given that they just give the excuse of inaudible differences.

For example, this PR: https://github.com/xiph/opus-tools/pull/28

It added the option to the decoder, but it has since been ignored because the devs cannot find quality improvements...

There are more pull requests that haven't been merged into the main repository and instead they just comment out it and that's basically it...

Re: Opus 1.3 is out!

Reply #58
To answer #1, it's because of "no significant or audible differences". The only way to change the quality value is by modifying the code and recompiling. Unfortunately, I don't see the developers modifying this behavior, or approve a Pull Request that would enable such thing, given that they just give the excuse of inaudible differences.

For example, this PR: https://github.com/xiph/opus-tools/pull/28

It added the option to the decoder, but it has since been ignored because the devs cannot find quality improvements...

If you want them to change the resampler quality i think you need to provide evidence that you can detect differences in the first place... so don't hesitate to upload samples and ABX logs.

Good luck ABXing a high quality resampler...
| QAAC ~ 192 kbps |

Re: Opus 1.3 is out!

Reply #59
To answer #1, it's because of "no significant or audible differences". The only way to change the quality value is by modifying the code and recompiling. Unfortunately, I don't see the developers modifying this behavior, or approve a Pull Request that would enable such thing, given that they just give the excuse of inaudible differences.

For example, this PR: https://github.com/xiph/opus-tools/pull/28

It added the option to the decoder, but it has since been ignored because the devs cannot find quality improvements...

If you want them to change the resampler quality i think you need to provide evidence that you can detect differences in the first place... so don't hesitate to upload samples and ABX logs.

Good luck ABXing a high quality resampler...

And that's exactly what's wrong. Why would they add a variable quality setting if they will just hardcode it with no option to the end-user? It just doesn't make sense. Hence, that PR should be merged, even if the devs think it doesn't improve anything at all.

The user SHOULD be able to select the quality REGARDLESS of if there's any quality improvement or not.

Re: Opus 1.3 is out!

Reply #60
The user SHOULD be able to select the quality REGARDLESS of if there's any quality improvement or not.

Adding switches usually conveys a message to the users that the developers think that meaningful changes can be accomplished by toying around with theses options. Some users will waste brain cycles thinking about the meaning of the setting and, when in doubt, choose a "high quality" setting that as of yet has not been demonstrated to make any observable difference beside CPU load. I don't consider this good interface design.

In doubt, I'd decode at 48 kHz and use whatever resampler I like.

Another alternative is to fork  opusdec to spinaldec and add a bunch of switches that go up to 11 but don't really do anything meaningful. ;-)

Re: Opus 1.3 is out!

Reply #61
There is no significant audio quality difference, because frame sizes over 20ms are simply a bunch of 20ms frames concatenated together into a single unit. It merely increases latency.

Re: Opus 1.3 is out!

Reply #62
Regarding the general desire to withhold mathematical accuracy until its recognizable by a human  in the name of saving extra CPU cycles during encoding (I'm assuming the speex resampler is ABX'able at accuracy-level 4 but not at 5): does anyone know if this effort has been applied throughout the code, not just the resampler?

Let's take this to its logical conclusion: If you can drop some decimal places here and there throughout the code, move some 32 bit values down to 16 bit, and 64 bit values to 32 bit -- maybe you can save more CPU cycles or let the compiler use 16 SIMD registers instead of 8, then why not?  Maybe entire logical portions of the algorithm could be adjusted to withhold some fidelity if people aren't able to ABX it?

On the flip side - I can see the argument: the most efficient codec withholds more data than inferior codecs, all else being equal.  Why not apply it to mathematical accuracy too; wasted CPU cycles mean more latency for realtime applications, and possibly not running on CPU-limited or old hardware.


Re: Opus 1.3 is out!

Reply #63
And that's exactly what's wrong. Why would they add a variable quality setting if they will just hardcode it with no option to the end-user? It just doesn't make sense. Hence, that PR should be merged, even if the devs think it doesn't improve anything at all.
Well, it makes perfect sense to me because Speex resampler at Quality 5 setting is already overkill quality. The user doesn't really need to change that setting. And i doubt Opus devs will change that just to appease users' paranoia.

Anyway... all this resampler paranoia got me curious so here's a quick ABX test just for the sake of testing : )
Code: [Select]
foo_abx 2.0.5 report
foobar2000 v1.4.2 beta 1
2019-01-07 22:49:40

File A: sample1-speexQ1.flac
SHA1: 4c43030347b56331a98265420fc71d1d61fca6d0
Gain adjustment: -6.17 dB
File B: sample1-SoXBest.flac
SHA1: 7a939eac303badc0e6ee79edcd595613dc3d3e3c
Gain adjustment: -6.20 dB

Output:
DS : Primary Sound Driver
Crossfading: YES

22:49:40 : Test started.
22:50:11 : 01/01
22:50:42 : 01/02
22:51:12 : 01/03
22:51:42 : 02/04
22:52:14 : 03/05
22:52:43 : 03/06
22:53:14 : 03/07
22:53:43 : 04/08
22:54:14 : 04/09
22:54:43 : 05/10
22:55:15 : 05/11
22:55:48 : 05/12
22:55:48 : Test finished.

 ----------
Total: 5/12
Probability that you were guessing: 80.6%

 -- signature --
214275c2580e7471bdc3280753c61b5bf38b9f9b
So it seems that even Speex Q1 is enough to fool my 27 years old ears... and i really tried hard but simply failed to detect any difference.

Note: to resample from 44100 to 48000 i used foobar2000 SoX and Speex components both by lvqcl. The original sample (sample1.flac) can be found here.

That's all for today...
| QAAC ~ 192 kbps |

Re: Opus 1.3 is out!

Reply #64
I'm assuming the speex resampler is ABX'able at accuracy-level 4
Well, Shinsekai showed that it's unlikely.

move some 32 bit values down to 16 bit, and 64 bit values to 32 bit
CPU has no such thing as 16-bit floating point instructions, and I suspect that Opus already uses 32-bit float instead of 64-bit float where it's possible.

Maybe entire logical portions of the algorithm could be adjusted to withhold some fidelity if people aren't able to ABX it?
I agree. Any ideas how to do it?

Re: Opus 1.3 is out!

Reply #65
Opus-tools v0.2-3-gf5f571b (using libopus 1.3-11-g9f2a0c70)
Built on January 29, 2018, GCC 7.4.0(32bit)/8.2.1(64bit)

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

Re: Opus 1.3 is out!

Reply #66
Opus-tools v0.2-3-gf5f571b (using libopus 1.3-18-gdb082963)
Built on March 05, 2019, GCC 7.4.0 (32bit)/8.3.0 (64bit)

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

Re: Opus 1.3 is out!

Reply #67
Hi.
Happy to say that somwhere between 1.3-11 and 1.3-18 versions Opus team have fixed one problem which was stopping me from moving from 1.2 to 1.3 encoder version. Previously in 1.3-branch versions there was a very noticeable loss of high frequences in the beginning of the "trouble" sample.

Thank you, NetRanger.
Thanks to all Opus developers.

Re: Opus 1.3 is out!

Reply #68
Happy to say that somwhere between 1.3-11 and 1.3-18 versions Opus team have fixed one problem which was stopping me from moving from 1.2 to 1.3 encoder version. Previously in 1.3-branch versions there was a very noticeable loss of high frequences in the beginning of the "trouble" sample.

Good to hear. It was an issue with digital silence on x87 FPUs (so mostly just 32-bit x86). The issue was already present in previous versions, but it only happened when delayed decision was on (which was only implemented in the latest opus-tools).

Re: Opus 1.3 is out!

Reply #69
Hi.
Happy to say that somwhere between 1.3-11 and 1.3-18 versions Opus team have fixed one problem which was stopping me from moving from 1.2 to 1.3 encoder version. Previously in 1.3-branch versions there was a very noticeable loss of high frequences in the beginning of the "trouble" sample.
Thank you, NetRanger.
Thanks to all Opus developers.
Thank YOU too Seymour for bringing this to the forum.  I am one of the "32-bit x86" people jmvalin mentions so I've already replaced my opusenc.exe with NetRanger's new build.

@jmvalin:  is a "1.3.1" official version of opustools  on the horizon?


Re: Opus 1.3 is out!

Reply #71
It was an issue with digital silence on x87 FPUs (so mostly just 32-bit x86).
Thanks for the info. Does this correlate with the x64 binary that ran on Core 2 Duo E6300 Intel CPU? To be sincer, it's unclear to me how are the compilers utilizing the variety of modern (and not) instruction sets, all I see from my experience is that floating point calculations sometimes are much more harder to keep stable (compared to the integer ones).