I'm happy to announce that Opus 1.3 was just released. This major release again brings quality improvements, new features, and bug fixes. You can read all the details in this release demo page (https://people.xiph.org/~jm/opus/opus-1.3/).
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
Source code: opus-1.3.tar.gz (https://archive.mozilla.org/pub/opus/opus-1.3.tar.gz)
Win32 binaries: opus-tools-0.2-opus-1.3.zip (https://archive.mozilla.org/pub/opus/win32/opus-tools-0.2-opus-1.3.zip)
Please report any problem you encounter. Enjoy!
Thanx, 64 bit binaries please?
Thanx, 64 bit binaries please?
Here's my x64 build, with the added bonus of resample quality of 10 in both opusenc and opusdec ;)
Thanx, 64 bit binaries please?
Win64 build: opus-tools-0.2-opus-1.3-win64.zip (https://archive.mozilla.org/pub/opus/win64/opus-tools-0.2-opus-1.3-win64.zip)
I have been waiting on this (the x64 build) so I can re-rip my entire collection from FLAC to Opus @ 64kbps or 96kbps etc.
Thanks.
The improved stereo speech + new speech/music detection helped a lot with encoding ASMR, thank you very much!
Playing around with my Klipsch Pro-Media speakers on the PC with the 'release demo page' (the OP linked to) I can notice differences on the speech samples (like while the audio file is playing I switch back and fourth between Opus versions at the following rates)...
-9kbps = noticeable difference between v1.2 and v1.3 as it's a bit less muffled/more clear in v1.3. between v1.1 and v1.2 I don't notice any difference on this 9kbps setting.
-12kbps = noticeable difference between v1.1 and v1.2 but nothing between v1.2 and v1.3 as far as I can tell. NOTE: I would say this one is harder to spot a difference between v1.1 and v1.2 vs the 9kbps and 16kbps settings I mentioned which are easier to spot.
-16kbps = noticeable difference between v1.1 and v1.2 (basically less muffled and a bit more clear sounding) but I don't notice anything between v1.2 and v1.3.
-20kbps = things start to get harder to notice between the versions but I think I can spot some difference between v1.1 and v1.2.
-24kbps = I can 'maybe' notice a difference between v1.1 to v1.2.
-32kbps/40kbps = I can notice some change in sound between v1.2 and v1.3. basically a bit more clarity I guess I could say.
-48kbps = I can't say I notice anything here between Opus versions.
NOTE: from what I have noticed so far in general with my limited testing with my speech files... I prefer no lower than 13kbps with Opus v1.3 and 14kbps with Opus v1.2.1 for general speech at the minimum.
NOTE: I know headphones are optimal but I just thought I would list the above info for whatever it's worth ;)
opusdec.exe was 206KB in the previous release, and now it is 1264KB. What is the cause of this significant increase of size?
opusdec is now based on opusfile, which actually supports streaming
Today I was testing Opus 1.3 and find something strange.
I was testing two builds, first from opus-codec.org, and second from foobar Encoder Pack.
They gave two slightly different streams.
I encode .flac to .opus and again to .flac, and final files have different audio MD5 checksum.
I attach a spectrogram of a difference between two streams (Clash, London Calling for example).
Does anyone have any idea why is that so?
Different compilers and possibly different optimization settings. The encoder pack one is compiled with Visual Studio 2017 and Xiph's one is most likely with GCC.
Different compilers - i understand, different optimization - i understand less. But doesn't it all describe how codec do his work, instead of what he do. I mean, I understand if compiler / optimization can increase the speed of the program, compatibility with new CPU instructions, etc. But i really don't understand how it can impact on the result of the program (opus algorithm in this case).
I see using Foobar2000's 'Encoders Pack', which is 32bit, vs the the 64bit one the OP linked to...
-Encoders Pack version (which is 32bit) reports as... "opusenc from opus-tools 0.2"
-The x64 one the OP linked to reports as... "opusenc from opus-tools 0.2-3-gf5f571b"
but for 'Tool' they both report as... "libopus 1.3, libopusenc 0.2.1"
I assume this is a non-issue? ; I am using Foobar2000 to do the encodes. there is a 1byte difference in file size.
p.s. the Foobar2000 Encoder Pack version, which is 32bit, encodes a 64kbps Opus v1.3 file at 66-67x. the 64bit one the OP linked to does that same file encoded at 64kbps at 80x speed. I got a i3-2120 CPU. NOTE: I converted from the same FLAC level 8 file to Opus v1.3 for this quick speed test of the 32bit vs 64kbps versions I mentioned.
Great news!
Gonna encode to ~85-96kpbs and listen for improvements.
But i really don't understand how it can impact on the result of the program (opus algorithm in this case).
Different optimizations -> different order of floating-point instructions -> different results.
For example,
(a+b)+c usually is not the same as
a+(b+c).
Different optimizations -> different order of floating-point instructions -> different results.
For example, (a+b)+c usually is not the same as a+(b+c).
Actually, that's one of the few things compilers are *not* allowed to do when optimizing. OTOH, the compiler *is* allowed to use more bits than required by the program (especially on old x87 FPUs that had 80-bit float, but I think even for 32->64 bit float). Also, Opus uses transcendental math functions (sin, exp, log, ...) that are not required by the relevant standards to be accurate down to the LSB rounding. I suspect there may be a few other details that can cause differences, but the order of operations definitely must be preserved, otherwise overflows and underflows could cause massively wrong results.
Actually, that's one of the few things compilers are *not* allowed to do when optimizing.
You mean, to replace (a+b)+c with a+(b+c)? Well, Visual Studio Opus project has FloatingPointModel==Fast in Release configuration.
According to MSDN (https://msdn.microsoft.com/en-us/library/e7s85ffb(v=vs.140).aspx?appid=dev14idef1&l=en-us&k=k(vc.project.vcclcompilertool.floatingpointmodel)&rd=true),
The compiler may reorder operations or perform algebraic transforms—for example, by following associative and distributive rules—without regard to the effect on finite precision results.
Actually, that's one of the few things compilers are *not* allowed to do when optimizing.
You mean, to replace (a+b)+c with a+(b+c)? Well, Visual Studio Opus project has FloatingPointModel==Fast in Release configuration.
According to MSDN (https://msdn.microsoft.com/en-us/library/e7s85ffb(v=vs.140).aspx?appid=dev14idef1&l=en-us&k=k(vc.project.vcclcompilertool.floatingpointmodel)&rd=true), The compiler may reorder operations or perform algebraic transforms—for example, by following associative and distributive rules—without regard to the effect on finite precision results.
Yes, Visual Studio projects are set to compile by default with FloatingPointModel==Fast. My own builds are done using FloatingPointModel==Strict or FloatingPointModel==Precise if Strict fails. This of couse will cause floating point differences due to the way each mode is handled.
You mean, to replace (a+b)+c with a+(b+c)? Well, Visual Studio Opus project has FloatingPointModel==Fast in Release configuration.
I actually recommend against enabling that for Opus without very careful testing. gcc --fast-math used to cause problems until we added code specifically to address it (mostly NaN-related).
Just skimmed through several speech,music and mixed materials without finding anything wrong. New detector works really great.
Thank You for a new version and demo. :)
You mean, to replace (a+b)+c with a+(b+c)? Well, Visual Studio Opus project has FloatingPointModel==Fast in Release configuration.
I actually recommend against enabling that for Opus without very careful testing.
Hm, that wasn't entirely clear to me... Do you mean that fast math hasn't been tested with Visual Studio builds? That's how I read it, but as lvqcl says, the Release configuration for the Opus project does use FloatingPointModel==Fast (though the ReleaseDLL configuration uses Precise). See https://git.xiph.org/?p=opus.git;a=blob;f=win32/VS2015/common.props
(Also, any particular reason to set StructMemberAlignment to 16 bytes? Just curious.)
so... is 1.3 now the recommended version to use?
so... is 1.3 now the recommended version to use?
Why wouldn't the last version of anything be the recommended version to use?
as far as i remember there were some "problems" during the beta test. means, some people reported it actually sounded *worse* on some samples than 1.2.1
i might be wrong though, i am not a "heavy reader" here.
I am sure they released a stable version after they addressed those "problems" and tested it.
so... is 1.3 now the recommended version to use?
Why wouldn't the last version of anything be the recommended version to use?
You're kidding, right? Haven't heard about the OS Windows 10?
In today's age of crapware usually an older version is the most usable. (Sometimes a much older one)
I don't even know how to reply to that, comparing an OS to an open source audio codec.
Also, yes I've tried Windows 10 and it's their best, there is a little more to clean in the beginning but once setup properly it's the most compatible with all the new hardware and drivers, as expected, it's their latest.
I don't even know how to reply to that, comparing an OS to an open source audio codec.
YOU did that comparison! Right now...
I responded to what I quoted "Why wouldn't the last version of anything be the recommended version to use". And explained that the newest usually sucks.
Also, yes I've tried Windows 10 and it's their best, there is a little more to clean in the beginning but once setup properly it's the most compatible with all the new hardware and drivers, as expected, it's their latest.
And you came to this conclusion because fo the constant bugs, performance regressions to older windows versions and the crippling issues at every single major update. The last time (a week or two ago) they had to withdraw the update, because of data loss, users files got permanently erased...
so... is 1.3 now the recommended version to use?
Why wouldn't the last version of anything be the recommended version to use?
You're kidding, right? Haven't heard about the OS Windows 10?
In today's age of crapware usually an older version is the most usable. (Sometimes a much older one)
"Yeah, well, you know, that's just like, uh... your opinion, man!"
If you ask any DEVELOPER what their recommended version to use, it will typically be their latest. Except if you have a specific reason not to. I don't think speculation is a valid reason.
* Mainstream support for Windows 7, Windows 8 and Windows 8.1 has already ended.
* Any support for Windows 7 RTM without service packs ended on April 9, 2013. (and any older OS)
* Only extended support remains for Windows 7 SP1, Windows 8 and Windows 8.1
Meaning they will only fix security bugs on the old OS, and the less Critical they are the less likely they are to fix them. Forget about any non-security bug.
Then there's hardware and software support. For example DirectX 12 is only supported on Windows 10.
It's only a matter of time before you have to upgrade an old OS. And support for these OS is likely to expire before Windows 11 or whatever they call it comes out. For Windows 7 SP1: January 14, 2020
No developer wants to introduce new bugs. That's why they test, and release betas and release candidates. Even final releases are spread out slowly these days.
In the case of Opus, you may find the news here because it's an audio related forum. But It will take a while before it's announced in other news websites. And even more time for it to be actually incorporated in software. And last would be the point where you are getting the software pretty much automatically.
In the case of Windows, it's very similar. Microsoft has internal betas, then they have windows insider betas. And when they finally decide to release. Usually they let those explicitly looking for the update to get it first, Then they start pushing to a minor group, and gradually grow from there.
The bigger biannual updates are not even forced thru auto-updates until at least one month or more. They might nag you, but you still initially have the choice.
So my OPINION is, do get the latest updates, but you don't have to jump on the boat on release day. I give it a week and let others test the waters. Unless it's a non-critical piece of software in my day to day, then I can take the release day risk.
"Yeah, well, you know, that's just like, uh... your opinion, man!"
No "just". Also wast amounts of negative experience. It's only ever worth updating after a significant time have passed so people can get screwed and complain about it on the internet which one can research. And after tasting the new version isolated from the old one. This is just the way of the world...
It's only a matter of time before you have to upgrade an old OS.
Perhaps. But it may be a lot of time. Which apparently win10 needs to become not such a horrible, buggy crap pile.
And support for these OS is likely to expire before Windows 11 or whatever they call it comes out.
Not necessarily. 10 has a Vista vibe to it, which also sucked, and I skipped it in its totality. Though 10 is supposed to be forever, constantly being updated. (It just gest worse all the time...)
No developer wants to introduce new bugs. That's why they test, and release betas and release candidates. Even final releases are spread out slowly these days.
But they might don't give a sh*t about it. Seeing as MS demolished its testing team completely, it certainly belongs into this category.
In the case of Opus, you may find the news here because it's an audio related forum. But It will take a while before it's announced in other news websites. And even more time for it to be actually incorporated in software. And last would be the point where you are getting the software pretty much automatically.
Unlike Windows it will probably work out well, for Opus. (It's also nowhere near as complex)
as far as i remember there were some "problems" during the beta test. means, some people reported it actually sounded *worse* on some samples than 1.2.1
That's why it's called "beta". Regressions are there for sure.
Later all founded audible issues were fixed. RC1 was already excellent.
Not necessarily. 10 has a Vista vibe to it, which also sucked, and I skipped it in its totality. Though 10 is supposed to be forever, constantly being updated. (It just gest worse all the time...)
I liked Vista. On 1GB of RAM.
... Now I'm running Kubuntu 18.04.1 on 32GB of RAM. *shrug*
I tend to agree with
@Makaki as Windows 10 is generally all around better than Windows 7 as long as your hardware supports it. plus, with Windows 7 support ending in Jan 2020 it makes it all that more important one changes to a newer version of Windows. so even those die hard Windows 7 users will inevitably be forced to change over to Windows 10 at some point unless of course they dump Windows entirely which is not much of a option for most people because Windows is the standard.
but as a general safety buffer.... avoid those major updates that happen twice a year until the general public has had a chance to test them because it seems like with each major release in March/September of each year there is some semi-major/major issues and after maybe a handful of updates things start to stable out again. I tend to adopt each major update a bit before the official release which is usually once the tech sites pretty much confirm the build is the final version which will be released to the general public soon. but before I do upgrade from the previous version of Windows 10 to the current one, I use Clonezilla (free hard drive imaging software) and make a image of my boot drive (to a image file on another hard drive I got) just in case all hell brakes loose I can always revert like the upgrade never happened.
also, at least for us USA users I think one can still obtain Windows 10 for free if you got a valid Windows 7 etc license by using the official tool from Microsoft (i.e. https://www.microsoft.com/en-us/software-download/windows10 ) and selecting the 'upgrade' option as there was a article from July 2018 of this year saying that still works (i.e. https://www.zdnet.com/article/heres-how-you-can-still-get-a-free-windows-10-upgrade/ ). I did it back in Dec 2017, on a 10 year old laptop I got used that same month, and I could still obtain a free Windows 10 license at that point by upgrading from Win7 to Win10 (then I simply used the ISO and wiped the drive and installed Win10 from scratch after I confirmed it activated). but I currently have Linux Mint v19 on that laptop (HP DV5-1002nr) and put in a Intel 545s 128GB SSD (I got that SSD for only $31.99 a bit earlier this year which is the best SSD I have seen for around $30 so far) as it's decent enough for a basic internet machine as I think if that was my main computer I would likely put Windows 10 back on it and connect a actual mouse to it as using a computer for any length of time a mouse is far easier on your hand than using that crappy touchpad which is slow/clunky to navigate stuff. but one area Linux Mint is better than Windows 10 on that old laptop is the right side of the touchpad, the one that's used to scroll webpages, does not work on Windows 10 as there is apparently no drivers for it where as with Linux Mint it works perfectly fine.
@mzso You said, "Which apparently win10 needs to become not such a horrible, buggy crap pile."
It's not as bad as some claim it is as it's been solid on my main computer (i3-2120 CPU etc). sure, for some people it can be a clear problem at times but for the vast majority it's a solid upgrade from Windows 7 overall. I have been on Windows 10 since Dec 1st 2015 and while I did have some issues here and there it's generally been solid enough. I remember it had a big problem back in Jan 2018 (I think it was build 16299.192) with my 10 year old laptop causing it to basically get stuck in a upgrade and revert loop as it happened to have one of the CPU's effected by that. like it would boot up fine, attempt the 16299.192 update, it would install fine, and upon reboot it would hang at Windows loading screen and I would have to hard power off etc and eventually it would revert (after it goes into repair mode etc) to the previous build and things would be fine again but then Windows Update would attempt to install 16299.192 again and that process started all over again. that's pretty much the biggest problem I had on Windows 10 and, like I say, this was just on a backup laptop computer as my main PC was fine.
but I will say that bug recently, which only effected a small amount of users, with Win10 17763.1 (i.e. 1809) which was released on Oct 2nd and I think they pulled it on Oct 5th (I had 17763.1 installed late September) that took out the Documents etc folders was obviously a major screw up on Microsoft's part. but I did not have the issue as it appears that bug either takes out everything or nothing and I still had the small amount of Documents still intact so I was good. but in general I avoid storing files in their default locations and generally save them to different hard drives so even if I did get effected the damage would be minimal. but currently there is a problem with .zip files on 1809 (even the newest 17763.104) but only if you use the built in .zip manager which I don't use as I always use 7-zip and that appears to be fine along with other programs besides the default Windows 10 one.
with that said... if one wants to play it a bit safer, just avoid installing the major upgrades, which happen twice a year, until they have been tested by a decent portion of the general public. that should keep your chances of any major bugs to a minimum since that's usually what happens as on initial release they have some decent screw ups but after a handful of updates or so things stable out again until the next major release.
You said, "10 has a Vista vibe to it, which also sucked, and I skipped it in its totality."
The only Microsoft OS I skipped completely, as in never had it installed on my main PC, was Windows 8 because upon release it's interface was horrible for Desktop/Laptop users and after that it got a bad image and never recovered. because I temporarily tried it in a virtual machine and instantly hated it due to the interface as it made basic tasks a chore to do and changed things too much from what we have been all used to for ages now. it's pretty much the only OS from Microsoft I never had on my main computer at some point or another and I have been using PC's since the mid-1990's basically. so basically in my case I have been using Windows since Windows v3.11/Windows 95 era to date.
but from what I have noticed with Microsoft is they tend to have a pattern which held true since Windows 98 to date (which is pretty much when computers went mainstream).... Win98(good)/WinME(bad)/WinXP(good)/WinVista(bad)/Win7(good)/Win8(bad)/Win10(good). NOTE: I left off Win2k as while that was basically the first stable OS from Microsoft that the average user could use (I used it at one point back in the day), it was not marketed towards the common person so I did not count it.
Win98(good)/WinME(bad)/WinXP(good)/WinVista(bad)/Win7(good)/Win8(bad)/Win10(good).
I think that pattern broke because eight is good and 10 sucks. You only need to replace the start menu and it's much like 7, only more efficient. Meanwhile 10 brings perpetual performance issues, severe bugs, pointlessly removed features
8 was insanely bad, 8.1 was one of their best but we are OT.
jmvalin: Have there been any improvements on the decoding side of Opus 1.3? I read through the changes since 1.2.1 on the Opus site but it's not clear to me if the changes were all on the encoding vs. the decoding performance. Thanks for any info.
jmvalin: Have there been any improvements on the decoding side of Opus 1.3? I read through the changes since 1.2.1 on the Opus site but it's not clear to me if the changes were all on the encoding vs. the decoding performance. Thanks for any info.
On the decoder side, only two things have changed since 1.2:
- The minor spec changes in RFC 8251 are now enabled by default (they were there but disabled by default in 1.2), which slightly improves voice quality around 16 kb/s and makes mono decodes default to disabling phase inversions.
- There's been security hardening improvements, which makes it even harder for someone to cause problems with malicious files. No change in quality.
In general, all quality improvements have to be in the encoder since decoders can't change for compatibility reasons. To give you an idea, the very minor changes I mentioned to the decoder output are the only ones we made since 2012 and required years of standardization work.
8 was insanely bad, 8.1 was one of their best but we are OT.
Indeed we're off topic. (I blame your naive "why wouldn't the latest version be recommended" question :P )
Anyway, 8.1 is not really a separate OS, only an update of the 8 (regardless of marketing BS). (Naturally I don't use a pre-8.1 version)
OT: still 10 is better than any <10. It's not personal here, I don't care about MS, Apple, Linux, BSD or any other, I just use what's usable for my life and work. I use all of them in different areas.
On the decoder side, only two things have changed since 1.2:
- The minor spec changes in RFC 8251 are now enabled by default (they were there but disabled by default in 1.2), which slightly improves voice quality around 16 kb/s and makes mono decodes default to disabling phase inversions.
- There's been security hardening improvements, which makes it even harder for someone to cause problems with malicious files. No change in quality.
Thanks very much for the information jmvalin and all your hard work on this terrific codec.
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
So no improvements whatsoever for high fidelity >100kb/s stuff?
I wonder where even <20kbps audio is even relevant in this day and age.
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
So no improvements whatsoever for high fidelity >100kb/s stuff?
I wonder where even <20kbps audio is even relevant in this day and age.
Mobile connections in the states.
Mobile and home internet for many developing countries, especially satellite and DSL.
Maintaining call integrity for VOIP.
Recordings of lectures, speeches, anything long.
Opus has never prioritized complete transparency at higher bitrates. We have AAC and MP3 that do a great job. Opus sounds very good as well.
Like all codecs, I'm sure they will wring out as much performance as possible over time. But high bitrate is the land of diminishing returns and there is so much room for improvement/much to be gained at lower bitrates.
Opus has never prioritized complete transparency at higher bitrates. We have AAC and MP3 that do a great job. Opus sounds very good as well.
Like all codecs, I'm sure they will wring out as much performance as possible over time. But high bitrate is the land of diminishing returns and there is so much room for improvement/much to be gained at lower bitrates.
Mostly, high bitrate is the first thing that got done because in some ways it's easier. It's once you start lowering the bitrate that things start to fall apart and you have to be increasingly creative to make audio sound decent despite being really short on bits, and that's why Opus has been consistently pushing the frontier on the low end. At high bit-rate things are already pretty good, so even small improvements are really hard. That's in part because you're mostly constrained by the laws of information theory (you're not going to get any better than a 6 dB improvement per extra per bit), but also because any small improvement you might come up with will be nearly impossible to verify when almost all your material is already transparent (or very close to transparent). There's a good reason we haven't seen 128 kb/s AAC/Opus listening tests. It's because everything's so close to transparent you'd need hundreds of samples and hundreds of listeners to get anything statistically significant (as opposed to everything being transparent except for one codec randomly hitting a killer sample). Even the last 96 kb/s test was pushing it.
There's a good reason we haven't seen 128 kb/s AAC/Opus listening tests. It's because everything's so close to transparent you'd need hundreds of samples and hundreds of listeners to get anything statistically significant (as opposed to everything being transparent except for one codec randomly hitting a killer sample). Even the last 96 kb/s test was pushing it.
It’s true. I can explain in which exactly way the last two 96 kbps tests were pushing it.
Most of average listeners hear artifacts at 48-64 kbps for HE-AAC and Opus encoders.
The listeners who have participated in 64 kbps have commented that they couldn’t submit a high number of results if any for 96k tests (because they hardly could ABX it).
During 96k tests a number of submitted results per each week drop to less than 50% than during 64 kbps test!
48-64 kbps tests- average listeners prevail.
96 kbps tests - average listeners + experienced listeners (roughly ~50%/50%)
128 kbps test - highly experienced and trained listeners mainly (hence not representative as a real-life scenario)
The results of public test 96k https://listening-test.coresv.net/results.htm
Opus - 4.65
Apple AAC - 4.40
MP3@128, Vorbis - 4.24If those average listeners who participated in low 64k test could have submitted their results for 96k test as well then the scores would look like this for 96k test:
Opus - 4.80
Apple AAC - 4.70
MP3@128, Vorbis - 4.5-4.6 (and yes, I can calculate it with a pretty acceptable precision of +/- 0.1)
Looking at these numbers it’s pretty clear that there is no reason to test 128k as Opus and Apple AAC would be clipping near transparent score 5.0 (at 4.8-4.9 scores).
If somebody uses Opus or AAC at 128k or higher that's fine to stay on safe side. But asking for tuning at >100 kbps hasn't any sense as both Opus and AAC already reached limits of transparency at those rates.
Congratulations for the new release, updated :)
jmvalin: Have there been any improvements on the decoding side of Opus 1.3? I read through the changes since 1.2.1 on the Opus site but it's not clear to me if the changes were all on the encoding vs. the decoding performance. Thanks for any info.
Nowadays a vast majority of mobile devices will decode mp3, he/aac, opus or vorbis with the same impact on battery life.
Last time I've checked Opus decoder consumed 20-25 MHz (Cortex A7 or A53) which is very small amount considering that at least one core will still run at ~200-600 MHz even in idle mode. :P
At 13.2 kbps with cvbr or vbr, specifying --speech switches from fullband to wideband even though by default fullband audio is always used at this bitrate with cvbr or vbr. Also music mode never seems to be used unless --music is specified. Is this intentional behavior?
At 16.4 kbps cbr I found a song that is classified as speech during the first second. It is a really inconsequential but the difference is audible as some noise during the first second before music mode is enabled. The mistake doesn't exist with cvbr or vbr. The song is Uncharted Worlds from the game Mass Effect. I attached a flac with a portion of the beginning as well as some opus encodes if anyone cares.
Opus-tools v0.2-3-gf5f571b (using libopus 1.3-7-g054acff3)
Built on November 06, 2018, GCC 7.3.0(32bit)/8.2.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
opusdec.exe was 206KB in the previous release, and now it is 1264KB. What is the cause of this significant increase of size?
The default is now Release-HTTP for streaming, which requires OpenSSL, which is frickin' gigantic. That's the real reason; the HTTP code is relatively tiny. I don't build my personal binaries with it, but in the grans scheme of things a megabyte isn't the end of the world.
opusdec.exe was 206KB in the previous release, and now it is 1264KB. What is the cause of this significant increase of size?
The default is now Release-HTTP for streaming, which requires OpenSSL, which is frickin' gigantic. That's the real reason; the HTTP code is relatively tiny. I don't build my personal binaries with it, but in the grans scheme of things a megabyte isn't the end of the world.
It also depends whether it's compiled Static or Shared. My builds are shared and so the binary ends up being a little more than 400kb :)
Except you can't do that on Windows: OpenSSL is not commonly distributed with Windows.
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.
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
Thanx, 64 bit binaries please?
Here's my x64 build, with the added bonus of resample quality of 10 in both opusenc and opusdec ;)
Can you compile the dll files to so that I can use them with Freac, please?
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.
framesize 120 has no benefit over the default one, IIRC
or was that also changed recently?
framesize 120 has no benefit over the default one, IIRC
or was that also changed recently?
The option is there so I think it is reasonable of me to have questions about it.
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...
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...
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.
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. ;-)
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.
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.
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 : )
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 (https://hydrogenaud.io/index.php/topic,67373.0.html) and Speex (https://hydrogenaud.io/index.php/topic,67373.msg732180.html#msg732180) components both by lvqcl. The original sample (sample1.flac) can be found here (https://hydrogenaud.io/index.php/topic,91302.msg931374.html#msg931374).
That's all for today...
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?
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
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
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.
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).
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?
@jmvalin: is a "1.3.1" official version of opustools on the horizon?
I assume you mean 1.3.1 version of *Opus*, but yes I'm hoping that get that out soonish.
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).
I assume you mean 1.3.1 version of *Opus*, but yes I'm hoping that get that out soonish.
Yes I did :-[ and, good to hear! :)