Skip to main content
Topic: Opus 1.1.3 (Read 8507 times) previous topic - next topic
0 Members and 1 Guest are viewing this topic.

Opus 1.1.3

Good newz - Opus 1.1.3 was released

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

None of the bugs that were fixed were regressions over previous releases.

A more insight what does experimental ambisonics would be really helpful

For testing  :))


Re: Opus 1.1.3

Reply #2
A more insight what does experimental ambisonics would be really helpful

The ambisonics work so far is mostly so that we can store ambisonics data into Ogg file. See this work in progress IETF draft. Note that at this point, the feature is only there for testing and you should not expect ambisonics files created with 1.1.3 to be compatible with the final spec.

Re: Opus 1.1.3

Reply #3
Quote
Neon optimizations improving performance on ARMv7 and ARMv8 by up to 15%
...
Includes experimental ambisonics work (--enable-ambisonics)
Great  :)
Opus goes  faster and 3D.

I wonder if some  improvements from 1.2 (low bitrate tune) can be applied to higher rates as 64-128 kbps and higher. The recent improvements of intensity stereo could be for sure.  However it's understandable that the main scope of 1.2 is low bitrate and all aditional development of higher rates will mean extra time and resources consumption.  


Re: Opus 1.1.3

Reply #4
I wonder if some  improvements from 1.2 (low bitrate tune) can be applied to higher rates as 64-128 kbps and higher. The recent improvements of intensity stereo could be for sure.  However it's understandable that the main scope of 1.2 is low bitrate and all aditional development of higher rates will mean extra time and resources consumption. 
Well, I had some ideas for how to make the intensity stereo experiment scale to higher bitrate, but it's all vapourware right now. Once I have something, I'll post some samples and you can tell me whether it actually works :-)

Re: Opus 1.1.3

Reply #5
Why is Foobar stil using Opus v1.1.1? This version was included in Foobar2000 1.3.10, which was released in March 2016 after Opus v1.1.2 had been released. Now release 1.3.11 is almost here, which still seems to include Opus v1.1.1.

Anyone know if it's a very difficult update process? Of if there is another reason for the delay?

Re: Opus 1.1.3

Reply #6
I can't speak to the Foobar development process but I know that if you want Opus 1.1.3 (or 1.1.2) on RHEL/CentOS you have to build it yourself because stability matters more than bleeding edge. Sometimes bleeding edge introduces instability not present in known stable versions, so if the version they have works and is stable, they may be conservative on how long it takes to update simply for fear of replacing something stable with something that might have a bug.

I always build my own flac and opus tools, but by doing so any risk of bugs is my risk.

Re: Opus 1.1.3

Reply #7
on RHEL/CentOS you have to build it yourself because stability matters more than bleeding edge.
But this is not a v1.1.1 to v1.2 release. This one fixes bugs, so should be more stable. Many distributions have already upgraded to v1.1.2 (Debian, Ubuntu) and v1.1.3 (Arch, Gentoo), without any known bugs.

Re: Opus 1.1.3

Reply #8
You mean opuslib for decoding? Where do U read the version?

Re: Opus 1.1.3

Reply #9
foobar2000 has documented library updates in the changelog. Latest mention is Opus 1.1.1.

I'm annoyed that Mozilla has stopped compiling official Windows binaries. The last one is from 2015 with libopus 1.1. Compiles I make are slower and third party compiles always seem to require all sorts of new instructions.

Re: Opus 1.1.3

Reply #10
foobar2000 has documented library updates in the changelog. Latest mention is Opus 1.1.1.

I'm annoyed that Mozilla has stopped compiling official Windows binaries. The last one is from 2015 with libopus 1.1. Compiles I make are slower and third party compiles always seem to require all sorts of new instructions.
I've used these WIN builds the last year or so, seems fast and legit:
https://github.com/Chocobo1/opus-tools_win32-build

Re: Opus 1.1.3

Reply #11
That is an example of a compile that requires SSE2 instructions. It can't be bundled with for example foobar's encoder pack as it won't work on older CPUs.

Re: Opus 1.1.3

Reply #12
@Case : Do you realize that a non-SSE2 processor means older than Athlon 64 and older than Pentium 4? (According to the wikipedia, even Intel Atom supports SSE2). And then, I guess one would not use the slowest PC at hand to do an encoding process.
It is reasonable that you think about potential non-SSE2 users (which should be few), but what is usually done is to maintain an older version of the package for them.

Re: Opus 1.1.3

Reply #13
I still build all of my components with extended instruction sets optional, as I support the lowest common denominator. Switching anything to VS 2015 is an exercise in mass spamming the no extensions switch, since that defaults to SSE2.

Re: Opus 1.1.3

Reply #14
I'm just curious is Auro-3D something that can be ambisonics applied to?

Re: Opus 1.1.3

Reply #15
I still build all of my components with extended instruction sets optional, as I support the lowest common denominator. Switching anything to VS 2015 is an exercise in mass spamming the no extensions switch, since that defaults to SSE2.
You can change defaults by editing the Microsoft.Win32/x64.user.props in the property manager.


Re: Opus 1.1.3

Reply #17
I'm annoyed that Mozilla has stopped compiling official Windows binaries. The last one is from 2015 with libopus 1.1. Compiles I make are slower and third party compiles always seem to require all sorts of new instructions.

Chocobo1 over at free codecs dot com put out his version of Opus 1.1.3 (32 bit & 64 bit). A simple search there gets you the link to it.

Re: Opus 1.1.3

Reply #18
Does this update allow us to skip LPF in LFE channel for 5.1 / 7.1 case?

This really downgrades LFE channel performance.

Thanks,

Re: Opus 1.1.3

Reply #19
Does this update allow us to skip LPF in LFE channel for 5.1 / 7.1 case?
This really downgrades LFE channel performance.

You're aware that the LFE isn't supposed to contain any thing above 120 Hz, right? I'm not sure what you're doing with that channel, but if the Opus low-pass is causing you problems, then what you have is no longer an LFE.

Re: Opus 1.1.3

Reply #20
"You're aware that the LFE isn't supposed to contain any thing above 120 Hz, right? I'm not sure what you're doing with that channel, but if the Opus low-pass is causing you problems, then what you have is no longer an LFE.
More...Quote"

--- agreed, but i can't help it if some audio / music content does contain higher frequencies in LFE. I need to somehow not supress it completely. Minor suppression is OK, but not total elimination.

Re: Opus 1.1.3

Reply #21
Opus needs to support atleast some option to disable this LPF for LFE or even to increase the BW of this LPF.

Re: Opus 1.1.3

Reply #22
if some audio / music content does contain higher frequencies in LFE.
These frequencies will be inaudible on proper 5.1 audio system, so what's the point in keeping them?

Re: Opus 1.1.3

Reply #23
"You're aware that the LFE isn't supposed to contain any thing above 120 Hz, right? I'm not sure what you're doing with that channel, but if the Opus low-pass is causing you problems, then what you have is no longer an LFE.
More...Quote"

--- agreed, but i can't help it if some audio / music content does contain higher frequencies in LFE. I need to somehow not supress it completely. Minor suppression is OK, but not total elimination.

Can you please provide an example file/excerpt with LFE content above 120Hz? I can't think of any reason it would exist as the most extreme freq. response I can think of with a subwoofer is the SVS SB-2000 which goes up to 220Hz or so. Subwoofers are placed in a listening space for bass response, meaning if somehow it could reproduce higher frequencies it would cause horrible phase or stereo imaging issues.
I don't think Opus needs to accommodate a seemingly non-existent use case, especially as it is a lossy codec concerned with audible frequencies and efficient compression.

Re: Opus 1.1.3

Reply #24
Opus needs to support atleast some option to disable this LPF for LFE or even to increase the BW of this LPF.

The low-level codec itself doesn't know about LFE or anything so it can encode anything. But then there's a surround layer that attempts to optimize surround encoding, base on knowledge it has about the setup. For example, it knows front-left and front-right tend to be correlated, it knows LFE doesn't contain frequencies above 120 Hz, and so on. I'm not going to remove that knowledge and make surround worse for everyone just to "fix" non-standard files. People who have strange formats can always handle them through a lower-level Opus API and the decoders will handle them fine, but you'd have to write your own encoder. Also, as I pointed out in another thread, if the idea is to do 6.0, then the solution is to just encode 6.1 with a silent LFE. Even if the LFE didn't low-pass, encoding 6.0 by pretending it's 5.1 is a terrible idea since decoders would play it through the wrong speakers.

 
SimplePortal 1.0.0 RC1 © 2008-2018