Good newz - Opus 1.1.3 was released
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 :))
Windows builds for those interested: https://github.com/Chocobo1/opus-tools_win32-build/releases. Haven't tested.
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 (https://tools.ietf.org/html/draft-graczyk-codec-ambisonics). 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.
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) (https://hydrogenaud.io/index.php/topic,111798.msg922687.html#msg922687) 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.
I wonder if some improvements from 1.2 (low bitrate tune) (https://hydrogenaud.io/index.php/topic,111798.msg922687.html#msg922687) 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 :-)
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?
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.
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.
You mean opuslib for decoding? Where do U read the version?
foobar2000 has documented library updates in the changelog (http://www.foobar2000.org/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.
foobar2000 has documented library updates in the changelog (http://www.foobar2000.org/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
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.
@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.
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.
I'm just curious is Auro-3D something that can be ambisonics applied to?
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.
foobar2000 has documented library updates in the changelog (http://www.foobar2000.org/changelog). Latest mention is Opus 1.1.1.
Genuine question: is there a good reason to update the decoder on foobar2000?
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.
Does this update allow us to skip LPF in LFE channel for 5.1 / 7.1 case?
This really downgrades LFE channel performance.
Thanks,
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.
"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.
Opus needs to support atleast some option to disable this LPF for LFE or even to increase the BW of this LPF.
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?
"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.
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.
What is the LFE channel?
5.1-channel audio consists of five discrete, full range main channels (Left, Center,
Right, Left Surround, and Right Surround) plus an optional band-limited LowFrequency
Effects (LFE) channel.
In contrast to the main channels, the LFE channel delivers bass-only information
(<120 Hz) and has no direct effect on the perceived directionality of the reproduced
soundtrack. Its purpose is to supplement the overall bass content of the program or
to ease the burden on the other channels. The LFE channel was originally devised
for 70 mm movie productions to deliver a separate bass signal to one or more
additional subwoofers placed behind the movie screen
LFE does not equal subwoofer
Dolby Digital programs may include a bass-only LFE channel, but this channel
does not correspond directly to a subwoofer output. It is possible for a program to
contain an LFE channel, but a decoder may provide no subwoofer output because
all of the bass information in the program, including the LFE channel, can be
reproduced by the main speakers.
Source : https://www.dolby.com/uploadedFiles/Assets/US/Doc/Professional/38_LFE.pdf
I guess Dolby is a good enough source for talking about surround sound :)
(btw, that is the first result on google when searching for : "audio 5.1 lfe meaning")
I'm just curious is Auro-3D something that can be ambisonics applied to?
See https://docs.google.com/spreadsheets/d/1t2c0UXzKa-vRhOlwqIj3bn070P1KJWULNc5mYuHnTQ0/edit#gid=0
The only commonality is that they're able to store 3D audio. The rest (paradigm, cost, etc) is completely different.
You can convert, but there's costs as A3D isn't free, and you'll lose quality converting as paradigm differs.
Any update to Opus 1.1.3