I just released Opus 1.3-rc2. This is a second release candidate for the upcoming Opus 1.3. Changes include:
- Fixing an issue with bandwidth detection
- Enabling Ambisonics support by default
- Using mapping families 2 and 3 for Ambisonics (instead of experimental families 253 and 254)
- Enabling hardening by default
This release also comes with three other releases:
- libopusenc 0.2
- opusfile 0.11
- opus-tools 0.2
With these releases, opus-tools now depends on both libopusenc for encoding and on opusfile for decoding. The main difference is that opusenc is now able to use look-ahead, which helps when encoding speech and music at low-ish bitrates. Please give all of these a try and report any problems.
Source code: opus-1.3-rc2.tar.gz (https://archive.mozilla.org/pub/opus/opus-1.3-rc2.tar.gz)
Win32 binaries: opus-tools-0.2-win32.zip (https://archive.mozilla.org/pub/opus/win32/opus-tools-0.2-win32.zip)
Win64 binaries: opus-tools-0.2-win64.zip (https://archive.mozilla.org/pub/opus/win64/opus-tools-0.2-win64.zip)
Edit: Add win64 binaries
Great news.
When final release will be ready? O:) ( joking)
Will try it later and report.
Thank you.
When final release will be ready? O:) ( joking)
Actually, the only reason this release was called -rc2 instead of 1.3 is that we've enabled a few things by default (delayed decision, extra checks, ...) and wanted to make sure they're not broken. The final 1.3 will be out as soon as we're confident enough that there's nothing bad in -rc2.
This release also comes with three other releases:
- libopusenc 0.2
- opusfile 0.11
- opus-tools 0.2
jmvalin: Where can we download the 32-bit binaries for opusfile 0.11? The latest version at https://archive.mozilla.org/pub/opus/win32/ (https://archive.mozilla.org/pub/opus/win32/) is still opusfile 0.9.
jmvalin: Where can we download the 32-bit binaries for opusfile 0.11? The latest version at https://archive.mozilla.org/pub/opus/win32/ (https://archive.mozilla.org/pub/opus/win32/) is still opusfile 0.9.
We've not been able to build them at this point. None of us uses Windows and while we generally do our best to provide binaries, it doesn't always work out (in this case I think it was OpenSSL dll problems while cross-compiling).
jmvalin: Where can we download the 32-bit binaries for opusfile 0.11? The latest version at https://archive.mozilla.org/pub/opus/win32/ (https://archive.mozilla.org/pub/opus/win32/) is still opusfile 0.9.
We've not been able to build them at this point. None of us uses Windows and while we generally do our best to provide binaries, it doesn't always work out (in this case I think it was OpenSSL dll problems while cross-compiling).
I think this is a good area to target before the 1.3 release - being able to cleanly build the Opus suite (opus, opusenc, opusfile, and opus-tools) including step by step instructions using the currently maintained tool sets like: msys 1.0, msys-w64, msys 2.0 32bit, and mysys 2.0 64bit.
I'm also a 100% linux user (where auto tools just works), but I recently added Opus support to dosbox via integrating opusfile into SDL Sound, and thus wanted to test various windows builds.. and it was fraught with subtleties.
Why does opusdec.exe include OpenSSL? Doesn't this belong in a program that connects to the web, like a streaming player or browser? No other cli audio decoder has web components in it.
Why does opusdec.exe include OpenSSL? Doesn't this belong in a program that connects to the web, like a streaming player or browser? No other cli audio decoder has web components in it.
opusdec is now based on opusfile, which actually supports streaming, so you need OpenSSL for https.
Thanks for new version. I'm having trubl compiling opus tools.
opusenc.c referes headers and symbols like OggOpusEnc which are defined nowhere. Are there missing headers? (opusenc.h)
Thanks for new version. I'm having trubl compiling opus tools.
opusenc.c referes headers and symbols like OggOpusEnc which are defined nowhere. Are there missing headers? (opusenc.h)
opus-tools now depends on both the libopusenc library (for encoding) and the opusfile library (for decoding). It's more annoying to build, but it means that it's now easy to get Ogg Opus encoding support without having to call an executable.
Oops, I was really missing libopusenc library. You're right it's more annoying to build as I see there even references to speex and speexdsp libs. Are so exhaustive linkage necessary? I think speex is now getting deprecated.
Oops, I was really missing libopusenc library. You're right it's more annoying to build as I see there even references to speex and speexdsp libs. Are so exhaustive linkage necessary? I think speex is now getting deprecated.
There's no dependency on Speex in any of these libraries. We've *copied* the Speex resampler specifically to avoid having to link with it.
For this look-ahead to work does it needs the input to be a file, or this pipe thing from foobar will also work?
For this look-ahead to work does it needs the input to be a file, or this pipe thing from foobar will also work?
It'll work just fine with a pipe. That's the main advantage of delayed decision compared to two-pass encoding. That being said, the whole point of libopusenc is that applications like foobar can now easily link to a library rather than have to call a separate executable.
Can someone post optimized x64 binaries?
My Intel C++ config is now broken so not able to build.
Can someone post optimized x64 binaries?
My Intel C++ config is now broken so not able to build.
What's wrong with our x86-64 binaries (https://archive.mozilla.org/pub/opus/win64/opus-tools-0.2-win64.zip)?
Thanks so much, I was looking only at opus-codec.org/downloads
That being said, the whole point of libopusenc is that applications like foobar can now easily link to a library rather than have to call a separate executable.
Yes, but by design, foobar2000 does not link any encoders into its converter, just strictly a WAV output, piped or temporary file fed into external encoders. It hasn't supported an API for extending the converter with internal encoders since version 0.8.3 was replaced by the 0.9 series, years ago. 0.8.3 also didn't support ID3v2 tags natively, and still supported Win9x.
I compiled a new build of opusenc.exe with some changes:
- Visual Studio Floating Point Model flags. All projects were set to /fp:fast initially. I changed it with other flags depending on the project:
- libopus compiled with/fp:precise (didn't worked with /fp:strict)
- libopusenc and opusenc tool compiled with /fp:strict
- Also in libopusenc I upped the Speex resampler quality from the hardcoded 5 quality to 10.
Includes commits performed up to this point of the day
I don't see the point in slowing the encoding process down needlessly over inaudible quality differences.
Good point, but I like to see my CPU do some hard work 🙂 The good thing of Opus being open source is we can modify it to our likes. I've done 3 modifications so far, one of which was the --tracknumber argument that made it to 1.3 rc2.
Good point, but I like to see my CPU do some hard work 🙂 The good thing of Opus being open source is we can modify it to our likes. I've done 3 modifications so far, one of which was the --tracknumber argument that made it to 1.3 rc2.
Isn't the point of software to be as efficient as possible?
Isn't the point of software to be as efficient as possible?
No, the point of software is to serve the needs of its user(s).
Isn't the point of software to be as efficient as possible?
No, the point of software is to serve the needs of its user(s).
Well, the needs of the users can vary drastically. For example:
- On a mobile phone, a user needs the software to not drain the battery more than absolutely necessary.
- On a supercomputer, a user needs the software to run as correctly and quickly as possible
- At a CD pressing plant owned by Sony or BMG at a certain time in the past, a user needs the software to install itself onto another user's PC as a rootkit.
- On a PC, the user needs other users to not install nefarious software, such as a rootkit, onto their machine AND to play the CD they just bought. The user may or may not prefer a faster encode over smaller files, as well. Personally, I prefer the smaller file.
;)
On-topic: I'm glad to see a new release of the Opus tools! When I first tried converting some of my FLAC files with the 1.2 version opus-tools, I was happily surprised at the size/quality ratio improvement over OGG Vorbis. I also found it far easier than either monkeying around with ripping an audiobook to wav->encoding with speexenc->tagging or using ffmpeg->tagging.
Now, if Rockbox's support for it didn't tend to stutter or crash on my Sansa players, I could switch to using it full-time for everything. :( That's not on anyone here, of course. :)
Now, if Rockbox's support for it didn't tend to stutter or crash on my Sansa players, I could switch to using it full-time for everything. :(
I got a Sansa e250 v1 player running Rockbox and I am pretty sure it's a lack of CPU that causes that stutter with Opus (like navigating menus on Rockbox etc is sluggish). nothing you can really do about it which is why it was nice when I got a hold of a old smart phone just for playing Opus music with the mobile version of Foobar2000 as now 96kbps with Opus is basically better than AAC and using 64kbps is more of a option with Opus (if needed) where as with AAC-LC you generally don't want to go lower than 96kbps.
hell, if you think Opus 'stutter' on Rockbox is bad on a Sansa player, try playing a AAC-HE file as it's even worse and pretty much freezes things which I assume is due to even more CPU usage. at least the Opus files are somewhat usable unlike the AAC-HE stuff on a Sansa device with lack of CPU.
basically if you want to use the Sansa players your pretty much stuck to AAC-LC if you want quality sound at a small file size.
Isn't the point of software to be as efficient as possible?
No, the point of software is to serve the needs of its user(s).
Well, the needs of the users can vary drastically. For example:
- On a mobile phone, a user needs the software to not drain the battery more than absolutely necessary.
- On a supercomputer, a user needs the software to run as correctly and quickly as possible
- At a CD pressing plant owned by Sony or BMG at a certain time in the past, a user needs the software to install itself onto another user's PC as a rootkit.
- On a PC, the user needs other users to not install nefarious software, such as a rootkit, onto their machine AND to play the CD they just bought. The user may or may not prefer a faster encode over smaller files, as well. Personally, I prefer the smaller file.
;)
On-topic: I'm glad to see a new release of the Opus tools! When I first tried converting some of my FLAC files with the 1.2 version opus-tools, I was happily surprised at the size/quality ratio improvement over OGG Vorbis. I also found it far easier than either monkeying around with ripping an audiobook to wav->encoding with speexenc->tagging or using ffmpeg->tagging.
Now, if Rockbox's support for it didn't tend to stutter or crash on my Sansa players, I could switch to using it full-time for everything. :( That's not on anyone here, of course. :)
Couldn't agree more with you.
I do have an AMD Ryzen CPU so setting it up to use level 10 is nothing. Also, if the quality goes up to 10 it is for a reason. If it is disabled, that doesn't mean I can't use it. In fact, I wanted to use level 10 to make the maximum use of the code and the CPU.
Having said that, I, as a developer am setting up a distributed computing server to handle all my encoding demands, which I tested today and worked. I can speed up encoding by a lot this way.
-----
Back on topic,
The Hiby players are capable of decoding Opus really great:-)
You can also use external resampler like SoX (with "Very High Quality" setting). It's still way faster and mathematically more accurate than built-in Speex resampler (q 10)
src.infinitewave.ca
Though being mathematically more accurate doesn't mean audibly superior.
You can also use external resampler like SoX (with "Very High Quality" setting). It's still way faster and mathematically more accurate than built-in Speex resampler (q 10)
src.infinitewave.ca
Though being mathematically more accurate doesn't mean audibly superior.
Yep that works pretty well (for the paranoid like me).
For the curious, here's the one-liner script I have on my linux server that does this for me:
sox-opus.sh:
#!/bin/sh
find "$@" -type f -iname '*.flac' -print0 | nice -n 15 xargs -0 -P 4 -I {} sh -c 'sox "{}" -r 48k -b 24 -C 0 -t flac - | opusenc --vbr --bitrate 144 - /mnt/target/folder/"`basename "{}"`"-$(date +%s).opus'
Since sox & opus run mostly in parallel and because of the parallel execution of multiple files through xargs it's not even that slow.
Since sox command handles everything in integer, clipping can always occur when used without care.
If you are after sox for tiny bit of improvement in mathematical accuracy that likely mean nothing after lossy encoding, why don't you care about clipping?
foobar2000 + sox resampler plugin doesn't have this issue.
Since sox command handles everything in integer, clipping can always occur when used without care.
If you are after sox for tiny bit of improvement in mathematical accuracy that likely mean nothing after lossy encoding, why don't you care about clipping?
foobar2000 + sox resampler plugin doesn't have this issue.
I do care about clipping and am aware of this problem. How does the foobar plugin prevent it? Just by doing everything in floating point? Sadly using foobar2000 isn't really an option on my headless linux server. Also I'm not sure that pushing individual samples to 0db results in any audible degradation, as opposed to real life clipping where the actual waveform is damaged, as multiple samples are clipped.
I'm no sox expert and I just started to use it for 'peace of mind'. Is there anything I can do to make my processing chain better?
On linux, you could use ffmpeg (need to be built with soxr resampler enabled) instead of sox:
ffmpeg -i INPUT -af aresample=48000:resampler=soxr -c:a pcm_f32le -f wav OUTPUT
Not easy to type/remember, should not matter for scripting.
I do care about clipping and am aware of this problem. How does the foobar plugin prevent it? Just by doing everything in floating point? Sadly using foobar2000 isn't really an option on my headless linux server. Also I'm not sure that pushing individual samples to 0db results in any audible degradation, as opposed to real life clipping where the actual waveform is damaged, as multiple samples are clipped.
I'm no sox expert and I just started to use it for 'peace of mind'. Is there anything I can do to make my processing chain better?
Actually, if you just let opusenc do the job everything will be just fine because its processing chain is all float and there will be no intermediate clipping. Seriously, the quality degradation from the resampling is far far less than even what you get from 510 kb/s Opus. So if you're concerned with resampling, why are you using a lossy codec in the first place?
@jmvalin any chance you or any opus-tools developers could review this Pull Request?
https://github.com/xiph/opus-tools/pull/38
It basically allows encoding without specifying an output filename. Using the input filename and changing the extension to .opus if no output name is provided :-)
Actually, if you just let opusenc do the job everything will be just fine because its processing chain is all float and there will be no intermediate clipping. Seriously, the quality degradation from the resampling is far far less than even what you get from 510 kb/s Opus. So if you're concerned with resampling, why are you using a lossy codec in the first place?
Okay to reiterate: I'm just using the sox->opus chain because of the supposed mathematical superiority of sox's resampling algorithm. I'm not making any claims about audible quality, I'm just totally fine with wasting a few CPU cycles to get a slightly improved result, that's inaudible in all likely scenarios.
Now in regards to clipping. This is interesting and I've wondered about the introduction of clipping before. As an example I'll attach a screenshot from a track that I've recently converted, where I noticed sox warning me about clipping.
On the top is the original flac. In the middle is the result after processing with sox->opus and the last one is just using opusenc.
Finally I also tested foobar2000 with the sox plugin -> opus chain. Looks pretty much the same, but maybe I'm misunderstanding what nu774 was referring to. I assume ffmpeg is going to be similar.
As far as I understand it, this kind of clipping is pretty much unavoidable when converting to a sampling rate that doesn't have a divisor from the original sampling rate. At first glance it seems sox is doing a little bit better here, but I couldn't find a function to count the amount of clipped samples in audacity on the fly.
Any overs introduced by either Opusenc or SoX plugin are recoverable by reducing the gain in floating-point mode (such as ReplayGain in Foobar or some other software). You can test it by encoding a 32-bit file that has significant audible positive peaks. Clipping added by sox command line utility is hard and permanent. It appears that the test files have been converted to 16-bit fixed-point during loading in Audacity and have been permanently clipped too, which is a flaw in this program or process used to perform this test.
I wouldn't worry too much about clipping from a resampler if the end format is lossy at lowish bitrate. The codec, especially Opus, will change the waveform much more. Clipping could potentially occur during downmixing multichannel or in synthesised music from video games. It is easy to eliminate this issue by using 32-bit accuracy during processing.
Or you could, like, continue using the built-in resampler and not really notice a difference.
Another bonus of the built-in resampler: It has the same license as the rest of the library, whereas the SoX resampler is... GPL of some version, I believe?
Okay to reiterate: I'm just using the sox->opus chain because of the supposed mathematical superiority of sox's resampling algorithm. I'm not making any claims about audible quality, I'm just totally fine with wasting a few CPU cycles to get a slightly improved result, that's inaudible in all likely scenarios.
Except that in all likelihood, you're spending extra CPU cycles to make the final result slightly *worse*, for multiple reasons:
- If your intermediate data is 16-bit PCM (and opusenc doesn't currently take anything else), then you have the clipping issue, and if you scaledown like was suggested then you have more quantization noise
- If your intermediate data is 16-bit PCM, then just the fact that you're rounding between the resampling and the encoding adds noise
- The difference between different different resampler qualities is how much of the bandwidth gets retained below Nyquist. Except that when converting from 44.1 kHz to 48 kHz, the Nyquist rate is 22.05 kHz and Opus will actually throw away anything above 20 kHz, so as long as your resampler doesn't cut anything below 20 kHz, you've good.
- Because Opus uses the MDCT to cut what's above 20 kHz, there's going to be a tiny bit of aliasing left and any frequency above 20 kHz that gets removed by the resampler will actually *improve* quality because it won't go through the MDCT
- All resamplers cause small amounts of (mostly inaudible) echo and pre-echo due to the filter size (ringing), so the higher the resampler quality, the larger the filter and the more ringing you get. Again, I've never been able to hear that, but it's another example of longer filters being theoretically worse.
So overall, there's exactly zero reasons why using SoX will sound better, but several reasons for which it could sound very slightly worse (I doubt you'd be able to ABX). So if you actually want to be on the safe side, just let the encoder handle the resampling.
As a general comment, if some simple processing actually gave you better quality, trust us that it would already be in Opus and enabled by default (or easily accessible through an option if it increased the CPU by a lot). I like to believe that we're not complete idiots... and if you don't believe that claim then why are you using Opus in the first place :-)
- If your intermediate data is 16-bit PCM (and opusenc doesn't currently take anything else),
I'm using 24 bit FLAC as intermediate format. Seems to work fine for opusenc.
- If your intermediate data is 16-bit PCM (and opusenc doesn't currently take anything else),
I'm using 24 bit FLAC as intermediate format. Seems to work fine for opusenc.
I'm pretty sure that opusenc can eat up to 32bit float just fine.
I guess this "currently" just refers to the script in your post, but maybe I'm wrong.
Anyway, I don't understand why you choose FLAC as an intermediate format (instead of uncompressed format) , and re-quantization/clipping occurs even when you pick 24bit.
Anyway, I don't understand why you choose FLAC as an intermediate format (instead of uncompressed format) ,
It preserves tags and is not as easy to fuck up the audio as with handling raw PCM streams. It just works *shrug*
and re-quantization/clipping occurs even when you pick 24bit.
Sure. Did you look at the screenshots? I'm biased, but it _looks_ like my method introduced less clipping than just using opusenc or your proposal of foobar2000 sox&opus. This is not a hill I wish to die on, but it's you who brought up the supposed problem of clipping: Can you point to what I'm doing (or how I'm thinking) wrong if you still believe foobar2000 to be superior here? I'm attaching screenshots of the fb2k setup.
(acoustic) "Love Interruption" Jack White Acoustic Recordings 1998-2016 which is 24/96 flac and only 2:37 long.
I converted it to 160kbps. It came out to 14.4 MB.
I'm using 24 bit FLAC as intermediate format. Seems to work fine for opusenc.
OK, then strike point #2. The four other points still stand. Mostly the few extra Hz of bandwidth you're preserving with the better resampler are the first things Opus will throw away.
Sure. Did you look at the screenshots? I'm biased, but it _looks_ like my method introduced less clipping than just using opusenc or your proposal of foobar2000 sox&opus.
Your test is flawed. Your initial SoX conversion clips the signal and reduces peaks so the Opus will have less peaks too. Here's real demonstration how your method clips and floating point pipeline doesn't. Screenshots from Opus converted to 32-bit WAV, as Audition doesn't support Opus directly.
command line SoX -> FLAC -> Opus:
(https://i.imgur.com/A2MG9pV.png)
foobar2000 SoX -> Opus:
(https://i.imgur.com/cONhluT.png)
jmvalin: quick question unrelated to this silly debate. Will there be new windows builds for opus-tools that incorporate the fix in libopusenc about gapless buffering? Or is it not somethign that I'd have to worry about when using the 1.3-rc2 builds available here?
jmvalin: quick question unrelated to this silly debate. Will there be new windows builds for opus-tools that incorporate the fix in libopusenc about gapless buffering? Or is it not somethign that I'd have to worry about when using the 1.3-rc2 builds available here?
you can use recent appveyor build.
https://ci.appveyor.com/project/rillian/opus-tools
Opus-tools v0.2-1-g488abd9 (using libopus 1.3-rc2-2-ga8e2a2b1) (http://www.mediafire.com/file/0z2z4va1karh52l/)
Built on October 06, 2018, GCC 7.3.0(32bit)/8.2.0(64bit)
[Moderator note: fixed broken link]
To discussion about resampler.
Even if quality doesn't matter, SoX is able to provide the same quality as Speex while being much faster. Isn't it?
Thank you. :)
(acoustic) "Love Interruption" Jack White Acoustic Recordings 1998-2016 which is 24/96 flac and only 2:37 long.
I converted it to 160kbps. It came out to 14.4 MB.
The size of the source material (24/96) determines the finial size opus?
The size of the source material (24/96) determines the finial size opus?
Did you copy over a very large embedded artwork?
No cover. It's a HDtracks download (http://www.hdtracks.com/jack-white-acoustic-recordings-1998-2016).
To discussion about resampler.
Even if quality doesn't matter, SoX is able to provide the same quality as Speex while being much faster. Isn't it?
Yes, but Speex resampler is nothing compared to the encoder itself. You'll be shaving fractions of a percent off the total encoding time.
And don’t forget about the more restrictive license on that resampler.
I guess opus, being a low delay codec, will never choose libsoxr officially because of it's much longer delay.
However, from a user point of view, delay doesn't matter when you convert to a file using fb2k for example, and nothing can stop you from using sox resampler plugin.
And don’t forget about the more restrictive license on that resampler.
In this case it is worth to ask SoX authors if they allow to use their resampler with more permissive licence. Probably, they would not be against it =)
I guess opus, being a low delay codec, will never choose libsoxr officially because of it's much longer delay.
It is always possible to add a new option (e.g. --soxresampler) to satisfy everybody.
Personally, I don't think that it is a required thing. But as far as I remember, people complain about the resampler for years, and probably it is worth to include the resampler just to reduce amount of the negative noise from these complains according to Opus. Less complains, more people who are indecisive now (and too lazy to investigate if these complains are really reasonable) will choose Opus as their next lossy codec =)
Opus Tools are provided under a two clause BSD license, while libsoxr is provided under the LGPL. The resampler would need to be supplied with binaries as a DLL module, with a clearly defined API, with clear instructions with how to compile your own replacement. All so a handful of you can enjoy the added Placebo and negligible performance difference. But I suppose until someone here does the hard work of implementing it for you, you won't be satisfied that you have benchmarked it and Proven that it is Way Faster, and therefore Measurably Better. I think I'll stop responding to this topic now, nobody cares anyway.
Speex resampler is nothing compared to the encoder itself. You'll be shaving fractions of a percent off the total encoding time.
Core i3 3245, HDD WD Green, Encoding FLAC 44.1/16 from RAM-disc to opus on HDD with fb2k, opus 32bit build from NetRanger's post (https://hydrogenaud.io/index.php/topic,116618.msg963060.html#msg963060)
Direct encoding to opus:
~45xPre-resampling with SoX plugin (0.8.4) (Passband 95%, Normal quality, No aliasing) and encoding:
~65xSo, no, this is not "fractions of a percent".
Whoa I never benchmarked sox+opus vs using opus directly. I had no idea it was faster.
I'm quite disappointed that no one informed me of my obvious misconception, since I kept going on and on about how I'd be wasting a bit of time by going with the sox method.
I think you guys should really consider painting the side of your resampler with a green marker. Makes a huge difference in quality!
Okay. So maybe a few seconds worth of encoding time difference. For a two minute input sample, that's a difference of 0.8 seconds.
So, if you encode a 100Gb set of FLAC files for your smartphone, it would save significant amount of time.
Yes, it would make a difference of 2 whole hours on something you'll probably do once in your lifetime. That probably balances the two plus hours it would take someone to actually code this into the native application for you.