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

Opus 1.3-rc2

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
Win32 binaries: opus-tools-0.2-win32.zip
Win64 binaries: opus-tools-0.2-win64.zip

Edit: Add win64 binaries

Re: Opus 1.3-rc2

Reply #1
Great news.

When  final release will be ready?    O:)  ( joking)

Will try it later and report.

Thank you.

Re: Opus 1.3-rc2

Reply #2
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.


Re: Opus 1.3-rc2

Reply #4
jmvalin:  Where can we download the 32-bit binaries for opusfile 0.11?  The latest version at 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).

Re: Opus 1.3-rc2

Reply #5
jmvalin:  Where can we download the 32-bit binaries for opusfile 0.11?  The latest version at 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.

Re: Opus 1.3-rc2

Reply #6
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.

Re: Opus 1.3-rc2

Reply #7
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.

 

Re: Opus 1.3-rc2

Reply #8
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)

Re: Opus 1.3-rc2

Reply #9
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.

Re: Opus 1.3-rc2

Reply #10
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.

Re: Opus 1.3-rc2

Reply #11
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.


Re: Opus 1.3-rc2

Reply #13
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.

Re: Opus 1.3-rc2

Reply #14
Can someone post optimized x64 binaries?

My Intel C++ config is now broken so not able to build.


Re: Opus 1.3-rc2

Reply #16
Thanks so much, I was looking only at opus-codec.org/downloads

Re: Opus 1.3-rc2

Reply #17
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.

Re: Opus 1.3-rc2

Reply #18
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

Re: Opus 1.3-rc2

Reply #19
I don't see the point in slowing the encoding process down needlessly over inaudible quality differences.

Re: Opus 1.3-rc2

Reply #20
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.

Re: Opus 1.3-rc2

Reply #21
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?


Re: Opus 1.3-rc2

Reply #23
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. :)

Re: Opus 1.3-rc2

Reply #24
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.
For music (especially on-the-go)...
-I suggest Opus @ 96kbps (or... 64kbps minimum, 128kbps maximum). *preferred choice*
-I suggest AAC(Apple) @ 96kbps (q45 TVBR) or 128kbps (q64 TVBR). *secondary choice*
-I use Foobar2000 (/w Encoders Pack etc) to convert FLAC to Opus/AAC(Apple).

 
SimplePortal 1.0.0 RC1 © 2008-2018