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 1.3.1 (Read 46474 times) previous topic - next topic
0 Members and 1 Guest are viewing this topic.

Re: Opus 1.3.1

Reply #25
Opus encoder both the native ffmpeg and opusenc are improving fast. 24 kbps hasn't too artifacts. Only bass a bit lacks punch at various bitrates, but they are nightly build, you can't pretend high quality on music. Do they import code from one encoder to another? Or is hard work only? How does it work? I don't know nothing other that open source developers run tests.

Re: Opus 1.3.1

Reply #26
If I want to run the latest opusenc, should I compile libopus 1.3.1 or libopus 1.3-rc2?

I'm looking to the one that can do the highest quality encoding :P


Re: Opus 1.3.1

Reply #28
Opus-tools v0.2-4-g2e62a7c (using libopus 1.3.1-4-gad8fe90d)
Built on June 05, 2019, GCC 9.1.0

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

I'm using linux. I'm trying to compile it from source but I am struggling... I compiled both opus-1.3.1.tar.gz and opus-tools-0.2.tar.gz but opus-tools fails because of some kind of opusfile? Yeah I'm dumb :/

Shouldn't opus-tools be all I needed to compile?

Re: Opus 1.3.1

Reply #29
Apparently opus-tools requires some additional libraries (opus-tools, libopusfile, libogg, ...).

Re: Opus 1.3.1

Reply #30
Why can't they just document how to build it?
The appveyor (rightmost build passing) on the opus-codec.org development page kinda is that, just not really what some imagine. To build opus-tools you need to also build the libraries for Flac, LibOgg, Opus, LibOpusEnc, Opusfile, and OpenSSL (1.0.2-stable). You'll also need perl and nasm for the OpenSSL libraries (it eventually also uses nmake on the command line) and to copy some of the code from other repositories into multiple other repositories' include folder (like ogg\ogg.h in LibOgg). It's a fun little adventure.
If you switch from Release-HTTP to Release you can avoid all the godawful OpenSSL crap. I have no intention of ever encoding from a URI, so that's my default.

I'm using linux. I'm trying to compile it from source but I am struggling... I compiled both opus-1.3.1.tar.gz and opus-tools-0.2.tar.gz but opus-tools fails because of some kind of opusfile? Yeah I'm dumb :/

Shouldn't opus-tools be all I needed to compile?
Opus-tools is just the final runtimes. Pretty much everything in Linux is structured with separate lib* vs *-tools, you always need the libs. I don't know what distro you run, but all of the major distros have the latest versions of the whole suite built in, so you shouldn't even need to build anything unless you need a bleeding edge feature (which there aren't any, Opus has been pretty quiet since the last release). Alternately, you can just yum install or apt-get opus-devel which will download all of its dependencies for an easy build.

Building from raw git is more for people who are modifying things in some way. Grabbing a release is the way to go if you aren't a developer.

Re: Opus 1.3.1

Reply #31
If you switch from Release-HTTP to Release you can avoid all the godawful OpenSSL crap. I have no intention of ever encoding from a URI, so that's my default.
My bad, in opusfile it's Release-NoHTTP rather than Release.

 

Re: Opus 1.3.1

Reply #32
Why can't they just document how to build it?
The appveyor (rightmost build passing) on the opus-codec.org development page kinda is that, just not really what some imagine. To build opus-tools you need to also build the libraries for Flac, LibOgg, Opus, LibOpusEnc, Opusfile, and OpenSSL (1.0.2-stable). You'll also need perl and nasm for the OpenSSL libraries (it eventually also uses nmake on the command line) and to copy some of the code from other repositories into multiple other repositories' include folder (like ogg\ogg.h in LibOgg). It's a fun little adventure.

Yes, I slammed into many of these, and tried to help the devs here:
https://github.com/xiph/opusfile/issues/10

If you skim the open issues for all of the opus, ogg, and vorbis stack of code you will see a common theme of build issues because of subtle problems like this. 

xiph really need someone focusing on integration and release, who can kick the tires on a handful of platforms and build tools (mingw, msys, latest gcc stack, older gcc stack, clang/osx, etc) andd wring out these issues.

Likewise, they could provide a script to build and link "latest and greatest" opus-tools and vorbis-tools.

Re: Opus 1.3.1

Reply #33
I'm using linux. I'm trying to compile it from source but I am struggling... I compiled both opus-1.3.1.tar.gz and opus-tools-0.2.tar.gz but opus-tools fails because of some kind of opusfile? Yeah I'm dumb :/

Shouldn't opus-tools be all I needed to compile?

You can build statically linked opus-tools using this bash script: https://gist.github.com/spvkgn/60c12010d4cae1243dfee45b0821f692

Re: Opus 1.3.1

Reply #34
NetRanger, a year has passed since you compiled v0.2-4-g2e62a7c (using libopus 1.3.1-4-gad8fe90d) build.
Could you be so kind to compile a fresh one?
• 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 1.3.1

Reply #36
Thanks NetRanger!

Re: Opus 1.3.1

Reply #37
Opus-tools v0.2-14-g95d0495 (using libopus 1.3.1-41-gfad505e8)
Built on June 09, 2020, GCC 10.1.0
Thanks! This is good/stable version for convert/delete original?

How soon will the official new version be released? The most current official version here? Win32 only?

Re: Opus 1.3.1

Reply #38
Do not delete original flacs.
And if you have lossy files like mp3 you can put them in another folder and don't convert them due to generation loss. The quality is a bit improved, opus 41 sounds decent at 49 kbps, at 128 kbps I don't know, but is a test build so it's normal that it sounds nasal with some samples/parts.

Re: Opus 1.3.1

Reply #39
more than decent it sounds acceptable. Decent is 128 kbps for opus in my opinion.

Re: Opus 1.3.1

Reply #40
It depends as i would say...

If you use higher bitrates to convert music into Opus - 192 kbps (or theoretically even higher) - if you are utterly happy with the results... theoretically you could delete the source files, but be aware a second conversion afterwards is not at all recommended ;)

At least that is what i do.

Re: Opus 1.3.1

Reply #41
Anyone know the Debian maintainer for the opus packages? Those packages have been stuck in 2018. Affecting everything based on debian-testing, like Ubuntu, etc.

I compiled my own, but it's still an inconvenience for everyone, especially those who don't know how to compile.

Re: Opus 1.3.1

Reply #42
NetRanger, a year has passed since you compiled v0.2-4-g2e62a7c (using libopus 1.3.1-4-gad8fe90d) build.
Could you be so kind to compile a fresh one?
Regarding new builds,  libopus 1.3 (Oct 18, 2018) was the last build which contained improvements of audio quality.

All newer builds contain fixes, new features related to  programme itself but  there are no audio quality enhancements for the way  which most of us use the codec.







Re: Opus 1.3.1

Reply #49
How do i use this in foobar?
If you want to use the default Opus encoder profile, it will prompt you for path to opusenc.exe if it does not already have one. Else you can change it in advanced settings, I think.

Or you can make a custom converter profile/ setting, telling foobar2000 what excact EXE to use in that profile.
Example command line parameter for VBR 128kbps.
  • --quiet --bitrate 128 --vbr --ignorelength - %d