Skip to main content ↑ ↓

Notice

Please note that most of the software linked on this forum is likely to be safe to use. If you are unsure, feel free to ask in the relevant topics, or send a private message to an administrator or moderator. To help curb the problems of false positives, or in the event that you do find actual malware, you can contribute through the article linked here.
Topic: Opus v1.5.1 (Read 6296 times) previous topic - next topic
0 Members and 1 Guest are viewing this topic.

Opus v1.5.1

Opus 1.5 is the first release to make extended use of ML in the encoder and decoder. You can read all the details in the release demo page. In summary, major changes since 1.4 include:

    Significant improvement to packet loss robustness using Deep Redundancy (DRED)
    Improved packet loss concealment through Deep PLC
    Low-bitrate speech quality enhancement down to 6 kb/s wideband
    Improved x86 (AVX2) and Arm (Neon) optimizations
    Support for 4th and 5th order ambisonics

In addition to the improvements above, this release includes many minor bug fixes. Opus 1.5.1 fixes the meson build that was broken in 1.5.

https://opus-codec.org/release/stable/2024/03/04/libopus-1_5_1.html
https://opus-codec.org/demo/opus-1.5/

Re: Opus v1.5.1

Reply #1 –
I am impressed from listening to the samples on their demonstration page.

Re: Opus v1.5.1

Reply #3 –
should I re-encode my music library again or likely no improvements for ~128kbps opus?

Re: Opus v1.5.1

Reply #4 –
Quote from: bozzis on
should I re-encode my music library again or likely no improvements for ~128kbps opus?
The main focus for 1.5 was on real-time communications, so no need to re-encode your library.

Re: Opus v1.5.1

Reply #5 –
Nice to see my trusty >5 year old phone (Mi 8, SDM845 SoC) making the cut.

Re: Opus v1.5.1

Reply #8 –
That low bitrate speech enhancement is really interesting. I've been encoding some talks at 36 kbps, and the demo at 9 kbps with NoLACE already sounds perceptibly pleasant. That's a 4x reduction in file size.

Re: Opus v1.5.1

Reply #9 –
Quote from: sld on
That low bitrate speech enhancement is really interesting. I've been encoding some talks at 36 kbps, and the demo at 9 kbps with NoLACE already sounds perceptibly pleasant. That's a 4x reduction in file size.
I wish that opus would have a customizable music/speech detector where I could set speech bitrate and music bitrate. This would maybe be good for low bitrate radio and podcasts to not sound too bad during music.

Re: Opus v1.5.1

Reply #10 –
I've always wondered why Opus even in VBR mode still makes us select a bitrate target, instead of having quality presets like LAME mp3 or Musepack. Or is it already present but not well-known?

Re: Opus v1.5.1

Reply #11 –
Quote from: punkrockdude on
Quote from: NetRanger on
Opus-tools v0.2-34-g98f3ddc (using libopus 1.5.1)
Built on March 04, 2024, GCC 13.2.0
Is this compiled with Ml-based features enabled?

AFAIK, i dont think the Ml based features are enabled?  I could be wrong but i have encode a song using 1.4, then encode the same song at 1.5.  The size is exactly at 4.7 MB.  I thought it would be at most 3.0 MB.  Maybe using foobar is a bad idea?  Is there any encoder that could take advantage of the ML features?

Re: Opus v1.5.1

Reply #12 –
Quote from: MinPower on
AFAIK, i dont think the Ml based features are enabled?  I could be wrong but i have encode a song using 1.4, then encode the same song at 1.5.  The size is exactly at 4.7 MB.  I thought it would be at most 3.0 MB.  Maybe using foobar is a bad idea?  Is there any encoder that could take advantage of the ML features?

Valin said that Opus 1.5 was mainly focused on real-time communication, so we shouldn't expect any changes for music encoding.
Also, just out of curiosity I did the same test encoding a song with opus 1.4 and opus 1.5, results are the file size are different and the files are bit-wise different as well, so even for music something has changed although I couldn't ABX the two files.

Encoded with Opus 1.4 (settings: --bitrate 128):


Encoded with Opus 1.5.1 (settings: --bitrate 128):


Interestingly, even the average bitrate increased by 1 when encoding with Opus 1.5.

Anyway, as I failed to ABX them both when comparing to the original .flac, and with Valin's answer earlier, I decided to not re-encode my music library.

Re: Opus v1.5.1

Reply #15 –
Quote from: MinPower on
Quote from: punkrockdude on
Quote from: NetRanger on
Opus-tools v0.2-34-g98f3ddc (using libopus 1.5.1)
Built on March 04, 2024, GCC 13.2.0
Is this compiled with Ml-based features enabled?

AFAIK, i dont think the Ml based features are enabled?  I could be wrong but i have encode a song using 1.4, then encode the same song at 1.5.  The size is exactly at 4.7 MB.  I thought it would be at most 3.0 MB.  Maybe using foobar is a bad idea?  Is there any encoder that could take advantage of the ML features?
The ML improvements are decoder-side. This repository has them enabled, you can see the author's confirmation in a closed issue:
https://github.com/Chocobo1/opus-tools_win32-build

Audio players would need to update their own decoders accordingly, I surmise.

Re: Opus v1.5.1

Reply #16 –
I updated the sharing files, now the 6 entries in English, French and German are in a single file, already compressed at different bitrates and provided in different containers to avoid compatibility problems.

From my tests it emerged that Safari on iPhone now also decodes Opus in Webm, previously it only occurred on iPad and macOS which are less widespread.

The same goes for Opus in ISOBMFF, it will take me time to try about it but I feel like I can write that, Opus can now be used with HTML5 audio and video markers in all updated operating systems when combined with Webm (which takes away some of the efficiency compared to other containers).

For comparison, I have also included some examples in MP3, still widely used in podcasts (it cannot be replaced by Opus without updating the apps), in AAC and MPEG-D USAC, the latter is currently the only one that can be used in podcasts in the absence of deep inspections of ISOBMFF content.

By contrast, MPEG-D USAC, which works from Amazon's Fire TV sticks to all cell phones and tablets, requires third-party software to decode on Windows 10, Linux and others too.

Re: Opus v1.5.1

Reply #17 –
I wonder what Discord is going to do with this update. It's possibly the application with the biggest userbase that's gonna have one of the most significant quality of service changes due to this update.

Re: Opus v1.5.1

Reply #18 –
Users outside the golden billion read the announcement.



Quote
Opus Gets a Serious Machine Learning Upgrade
No doubt, the vocal cords of Skynet terminators will use Opus.

Quote
In the end, most users should not notice the extra cost, but people using older (5+ years) phones or microcontrollers might.
So it will be possible to warm your hands in the winter by playing Opus on the smartphone.
Also Opus will refresh you on a sultry summer afternoon by making the desktop cooler howl.
• Join our efforts to make Helix MP3 encoder great again
• Opus complexity & qAAC dependence on Apple is an aberration from Vorbis & Musepack breakthroughs
• Let's pray that D. Bryant improve WavPack hybrid, C. Helmrich update FSLAC, M. van Beurden teach FLAC to handle non-audio data

Re: Opus v1.5.1

Reply #19 –
Quote from: Kraeved on
So it will be possible to warm your hands in the winter by playing Opus on the smartphone.
Also Opus will refresh you on a sultry summer afternoon by making the desktop cooler howl.

Can you elaborate on that? I haven't used it in years, but I'm pretty sure my ancient (2003?) iriver with rockbox installed can still decode opus.

All of these new features are client side and optional.

Re: Opus v1.5.1

Reply #20 –
Quote from: Deathcrow on
Quote from: Kraeved on
So it will be possible to warm your hands in the winter by playing Opus on the smartphone.
Also Opus will refresh you on a sultry summer afternoon by making the desktop cooler howl.

Can you elaborate on that? I haven't used it in years, but I'm pretty sure my ancient (2003?) iriver with rockbox installed can still decode opus.

All of these new features are client side and optional.
I have a Rockboxed iRiver H120 and a Sansa e270 and when I used Opus on it (the Sansa), it wasn't that happy at all. I posted about it here

Re: Opus v1.5.1

Reply #21 –
Quote from: NetRanger on
    Significant improvement to packet loss robustness using Deep Redundancy (DRED)
    Low-bitrate speech quality enhancement down to 6 kb/s wideband

Is there any way to find out if a stream (ogg file) uses DRED, LACE, noLACE (or if SILK and/or CELT is used)? The opusinfo app seems to be blissully ignorant of such nerdy details...

Re: Opus v1.5.1

Reply #22 –
CELT/SILK can be easily detected by looking at the first byte of opus frame (TOC byte).
LACE/NoLACE is post-processor that works after SILK decoder and can be optionally enabled at decode time. In other words, there's no difference on the encoded bitstream.

As far as I know, opusdec currently doesn't support setting decoder complexity. So, there's no way to enable LACE/NoLACE by opusdec.
Also, LACE/NoLACE requires libopus specially built with --enable-osce which is off by default.

For now, you can try NoLACE by qaac 2.82 https://github.com/nu774/qaac/releases/tag/v2.82 with libopus binary attached there, although it works only for MP4 container.
qaac also supports decoding ordinary .opus file, but it's supported by libsndfile. Therefore qaac has no direct control over libopus in that case, hence NoLACE cannot be enabled .


Re: Opus v1.5.1

Reply #23 –
Here's the x64 version of opus-tools based on opus 1.5.1 with --enable-dred and --enable-osce configured,
since DRED and LACE/NoLACE was affected at decode stage, I also attach a modified opusdec with dec_complexity init at 10.
 

Re: Opus v1.5.1

Reply #24 –
Quote from: nu774 on
LACE/NoLACE is post-processor that works after SILK decoder and can be optionally enabled at decode time. In other words, there's no difference on the encoded bitstream

Thanks for the explanation - I have to admit that after reading the 1.5 release news. I didn't understand that there's no encoder side change at all.  I hope apps will enable noLACE decoding - alas, it's probably hard to tell, esp. because there seems to be little difference at moderate bitates (I'm usually encoding podcasts at 24 kbps).

Another question: The release notes state "LACE and NoLACE are currently only applied when the frame size is 20 ms." (https://opus-codec.org/demo/opus-1.5/) - is this just for the time being at this will expand to other frame sizes? Until now, I've used 60 ms for podcast offline encoding to save a little file size...