I'm happy to announce Opus 1.3.1. It is a minor release that fixes an issue with the analysis on files with digital silence (all zeros), especially on x87 builds (mostly affects 32-bit builds). It also includes two new features:
- A new OPUS_GET_IN_DTX query to know if the encoder is in DTX mode (last frame was either a comfort noise frame or not encoded at all)
- A new (and still experimental) CMake-based build system that is eventually meant to replace the VS2015 build system (the autotools one will stay)
Source code: opus-1.3.1.tar.gz (https://archive.mozilla.org/pub/opus/opus-1.3.1.tar.gz)
Win32 binaries: opus-tools-0.2-opus-1.3.1.zip (https://archive.mozilla.org/pub/opus/win32/opus-tools-0.2-opus-1.3.1.zip)
Please report any problem you encounter. Enjoy!
Has the gapless playback issue from here (https://hydrogenaud.io/index.php/topic,116605.0.html) also been taken care of?
Can anyone please elaborate a bit about the practical benefits brought by this new feature?
> A new OPUS_GET_IN_DTX query to know if the encoder is in DTX mode (last frame was either a comfort noise frame or not encoded at all)
Thanks for the update, great as usual :)
Can anyone please elaborate a bit about the practical benefits brought by this new feature?
> A new OPUS_GET_IN_DTX query to know if the encoder is in DTX mode (last frame was either a comfort noise frame or not encoded at all)
This is only useful is you're writing a VoIP/videoconferencing application and you've asked Opus to stop transmitting when there's no speech.
No love for Windows 64-Bit?
Win32 binaries: opus-tools-0.2-opus-1.3.1.zip (https://archive.mozilla.org/pub/opus/win32/opus-tools-0.2-opus-1.3.1.zip)
Tool: libopus 1.3-26-ge85ed772, libopusenc 0.2.1-2-g9cb17c6
Small issue but it looks kinda messy. Older version is fine: libopus 1.3, libopusenc 0.2.1
No love for Windows 64-Bit?
There is a 64-bit (and 32-bit) alternate build in the package here: https://github.com/Chocobo1/opus-tools_win32-build/releases (https://github.com/Chocobo1/opus-tools_win32-build/releases)
Thanks!!
There is a 64-bit (and 32-bit) alternate build in the package here: https://github.com/Chocobo1/opus-tools_win32-build/releases (https://github.com/Chocobo1/opus-tools_win32-build/releases)
IDK, if there's any advantage, but VS2019 is available.
One advantage: It doesn't support compiling for XP.
Actually, it supports compiling for XP using VS2017 toolkit. Though it is deprecated in VS2019.
There is a 64-bit (and 32-bit) alternate build in the package here: https://github.com/Chocobo1/opus-tools_win32-build/releases (https://github.com/Chocobo1/opus-tools_win32-build/releases)
The 64-bit version crashes on Windows 7 x64 when trying to encode a file in all cases.
opusenc test.wav test.opus
Crash!
(https://i.imgur.com/dnpgH4R.png)
Do you have the VS2017 redist installed? You might also want to try the 64-bit build here:
https://moisescardona.me/wp-content/uploads/2019/04/opus-tools-x64-2019-04-13-using-libopus-1.3.1.zip (https://moisescardona.me/wp-content/uploads/2019/04/opus-tools-x64-2019-04-13-using-libopus-1.3.1.zip)
Do you have the VS2017 redist installed? You might also want to try the 64-bit build here:
https://moisescardona.me/wp-content/uploads/2019/04/opus-tools-x64-2019-04-13-using-libopus-1.3.1.zip (https://moisescardona.me/wp-content/uploads/2019/04/opus-tools-x64-2019-04-13-using-libopus-1.3.1.zip)
I do have the MSVC17 runtimes. Just downloaded and installed the latest just in case. Still crashes. I'll try building my own 64-bit.
Both 32-bit and 64-bit encoders from Chocobo1 crash here.
If you click on "Build Log" link on that github page, you'll see that it was compiled with "/arch:AVX" option to compile opus:
https://ci.appveyor.com/project/Chocobo1/opus-tools-win32-build/builds/23820862#L210
https://ci.appveyor.com/project/Chocobo1/opus-tools-win32-build/builds/23820862#L649
So it will crash on pre-AVX processors.
It seems that opus_functions.cmake from opus library is buggy...
This part doesn't make any sense for me:
if(MSVC) # To avoid warning D9025 of overriding compiler options
if(AVX_SUPPORTED) # on 64 bit and 32 bits
add_definitions(/arch:AVX)
elseif(CMAKE_SIZEOF_VOID_P EQUAL 4) # if AVX not supported then set SSE flag
if(SSE4_1_SUPPORTED OR SSE2_SUPPORTED)
add_definitions(/arch:SSE2)
elseif(SSE1_SUPPORTED)
add_definitions(/arch:SSE)
endif()
endif()
endif()
I'm just trying to figure out how to make it. There is NO documentation. I have Visual Studio, and I can make opus-1.3.1, but that doesn't produce opusenc and opusdec. When I try to build opus-tools-0.2 I get errors that it can't find ogg/ogg.h, but there is no such file in any of the sources I can find.
Why can't they just document how to build it?
Opus-tools v0.2-3-gf5f571b (using libopus 1.3.1-1-g296d556d)
Built on April 18, 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
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.
I'm having trouble building it with cmake. So I downloaded 1.3.1 source code, then "cd ~/Downloads/opus-1.3.1", "mkdir _cmake", "cd _cmake", "cmake .." - error, "CMake Error at CMakeLists.txt:19 (include): include could not find load file: opus_buildtype.cmake"
For some reason that file is in git, but not in tar.gz you can download from the release page. Just checked out v1.3.1 of xiph.org/opus.git and it built just fine (opus_buildtype.cmake is there)
For some reason that file is in git, but not in tar.gz you can download from the release page. Just checked out v1.3.1 of xiph.org/opus.git and it built just fine (opus_buildtype.cmake is there)
Yeah, that file was added at the last minute, but it didn't get added to the list of things to include in the tarball releases. That's now fixed for next time. Thanks for reporting the problem.
Opus-tools v0.2-3-gf5f571b (using libopus 1.3.1-2-g86e5f5ea)
Built on April 26, 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
Opus encoder both the native ffmpeg and opusenc are improving fast. 24 kbps has little 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.
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.
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
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
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?
Apparently opus-tools requires some additional libraries (opus-tools, libopusfile, libogg, ...).
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.
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.
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.
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
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?
Opus-tools v0.2-14-g95d0495 (using libopus 1.3.1-41-gfad505e8)
Built on June 09, 2020, GCC 10.1.0
https://github.com/xiph/opus
https://github.com/xiph/opusfile
https://github.com/xiph/libopusenc
https://github.com/xiph/opus-tools
Thanks NetRanger!
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 (https://opus-codec.org/release/stable/2019/04/12/libopus-1_3_1.html)? Win32 only?
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.
more than decent it sounds acceptable. Decent is 128 kbps for opus in my opinion.
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.
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.
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.
Opus-tools v0.2-14-g95d0495 (using libopus 1.3.1-41-gfad505e8)
Built on June 09, 2020, GCC 10.1.0
https://github.com/xiph/opus
https://github.com/xiph/opusfile
https://github.com/xiph/libopusenc
https://github.com/xiph/opus-tools
Is this the most recent opusenc.exe win64 available on the internet?
Opus-tools v0.2-20-gae5d6d5 (using libopus 1.3.1-91-g7b05f44f)
Built on March 28, 2021, GCC 10.2.0
https://github.com/xiph/libopusenc
https://github.com/xiph/opus
https://github.com/xiph/opusfile
https://github.com/xiph/opus-tools
Opus-tools v0.2-20-gae5d6d5 (using libopus 1.3.1-93-gdfd6c88a)
Built on May 13, 2021, GCC 10.2.0
https://github.com/xiph/libopusenc
https://github.com/xiph/opus
https://github.com/xiph/opusfile
https://github.com/xiph/opus-tools
Opus-tools v0.2-23-g7de1299 (using libopus 1.3.1-97-g6b6035ae)
Built on July 09, 2021, GCC 10.3.0
Opus-tools v0.2-27-gb982c4c (using libopus 1.3.1-98-ga8e6a77c)
Built on October 25, 2021, GCC 11.2.0
Opus-tools v0.2-27-gb982c4c (using libopus 1.3.1-98-ga8e6a77c)
Built on October 25, 2021, GCC 11.2.0
How do i use this in foobar?
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.
- https://wiki.hydrogenaud.io/index.php?title=Foobar2000:Converter
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
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.
- https://wiki.hydrogenaud.io/index.php?title=Foobar2000:Converter
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
Thanks so much for the help!
Opus-tools v0.2-27-gb982c4c (using libopus 1.3.1-99-gec64b3c5)
Built on December 17, 2021, GCC 11.2.0
Opus-tools v0.2-28-g5d0ac20 (using libopus 1.3.1-101-g66d060c7)
Built on January 28, 2022, GCC 11.2.0
Opus-tools v0.2-28-g5d0ac20 (using libopus 1.3.1-103-gc6f98577)
Built on March 08, 2022, GCC 11.2.0
Thank you NetRanger!
And now I hope there is someone out there that could fork Opus and modify it so it behaves like all the other codecs in the Replaygain arena like FLAC, M4A, MP3 and Vorbis! Opus just wrecks havoc with players that can not read or handle that special little R128 gain header correctly. Opus is an auditory nuisance when you have a mixed playlist when each selection is using a different codecs. Sorry for the rant, I love opus but I don't think any developer out there is going to make special accommodations for Replaygain compliance for Opus in their player(s). I would love to use Opus as my primary codec but it is on that Replaygain beat of its own and that is why I can't use it so forkit!
And now I hope there is someone out there that could fork Opus and modify it so it behaves like all the other codecs in the Replaygain arena like FLAC, M4A, MP3 and Vorbis! Opus just wrecks havoc with players that can not read or handle that special little R128 gain header correctly. Opus is an auditory nuisance when you have a mixed playlist when each selection is using a different codecs. Sorry for the rant, I love opus but I don't think any developer out there is going to make special accommodations for Replaygain compliance for Opus in their player(s). I would love to use Opus as my primary codec but it is on that Replaygain beat of its own and that is why I can't use it so forkit!
I'm not sure what you think forking the codec will achieve, because
- if the forked codec still produces the same format, then you're still facing the exact same issue as with libopus, and
- if the format produced by the forked codec isn't compatible with the current Opus format, then you're facing an entirely separate - and worse - issue, which is that your forked format isn't even playable anywhere.
What you can do if you're desperate, is to either manually add the
REPLAYGAIN_ALBUM_GAIN,
REPLAYGAIN_ALBUM_PEAK,
REPLAYGAIN_REFERENCE_LOUDNESS,
REPLAYGAIN_TRACK_GAIN and
REPLAYGAIN_TRACK_PEAK Vorbis comment fields to Opus with a tagging tool which supports custom metadata field entries like TagScanner (https://www.xdlab.ru/en/download.htm), or to use an encoding tool/frontend which automatically copies these fields to the created Opus files if the source files (presumably FLAC) contain them, like XMedia Recode (https://www.xmedia-recode.de/en/index.php).
Now, it's important to note that these Vorbis comment fields are
discouraged - but technically
not unsupported - by the Opus format specification (https://datatracker.ietf.org/doc/html/rfc7845#section-5.2.1):
To avoid confusion with multiple normalization schemes, an Opus
comment header SHOULD NOT contain any of the REPLAYGAIN_TRACK_GAIN,
REPLAYGAIN_TRACK_PEAK, REPLAYGAIN_ALBUM_GAIN, or
REPLAYGAIN_ALBUM_PEAK tags, unless they are only to be used in some
context where there is guaranteed to be no such confusion.
with the phrase "
SHOULD NOT" explicitly meaning (https://datatracker.ietf.org/doc/html/rfc2119#section-4):
4. SHOULD NOT This phrase, or the phrase "NOT RECOMMENDED" mean that
there may exist valid reasons in particular circumstances when the
particular behavior is acceptable or even useful, but the full
implications should be understood and the case carefully weighed
before implementing any behavior described with this label.
That said, I know for a fact that Rockbox supports using these fields for ReplayGain purposes, but I haven't tried it with any other players, so your mileage may vary.
Opus-tools v0.2-28-g5d0ac20 (using libopus 1.3.1-107-gccaaffa9)
Built on April 02, 2022, GCC 11.2.0
https://github.com/xiph/libopusenc
https://github.com/xiph/opus
https://github.com/xiph/opusfile
https://github.com/xiph/opus-tools
I remember reading on the codec's official website that the goal was to keep improving, but several years have passed and there have been no improvements in terms of quality. Version 1.3.1 had no significant changes in that, what future holds for Opus?
You have to divorce from the notion that software always has to be updated. As long as it is around, performing, stable, compatible, and simple is all we should care about. It is good enough.
How long has it been since LAME had any changes that theoretically would lead to quality improvements? Over a decade?
(My point is as far as I can tell, most CODECs have probably gotten all the low hanging quality improvements)
LAME hasn't had any major quality improvements since 3.99 beta 0 in 2011 or so, but that's also around the same time Opus was released. It seems Opus reached maturity much faster than LAME did, which isn't too surprising, since the field of lossy audio compression was well established by then.
AFAIK Vorbis's full potential likely remains unachieved. Maybe that's just how the cookie crumbles - the formats are designed with headroom for improvement potential that just becomes too cumbersome to reach.
Presumably by now only MP3 is in the opposite of that situation.
There are developments in lossy audio, depending on its intended use. Sound quality isn't all, sometimes latency is more important. And in the age of COVIDeoconferences there will often be so much bandwidth that squeezing audio size isn't the chief concern. The listening tests subforum has some food for thought. E.g. https://hydrogenaud.io/index.php?topic=120997.0 and several threads by
@Kamedo2 It would surprise me if Opus couldn't be improved in some areas, but are those what it will be used for? If not, ... fine! That said, when https://wiki.xiph.org/OpusTodo still has "To do" for 1.2 when we are at 1.3, ...
(As for Vorbis' potential, it provided for bit peeling - did anyone ever get a working implementation?)
AFAIK Vorbis's full potential likely remains unachieved. Maybe that's just how the cookie crumbles - the formats are designed with headroom for improvement potential that just becomes too cumbersome to reach.
Vorbis's main purpose was to be an open competitor to MP3, and now that Opus exists and does everything Vorbis did, except better, there's probably no point in trying to improve Vorbis further. I doubt the lack of development is due to technical limitations; it probably just stems from a lack of developer interest. Why work on Vorbis when you could work on Opus?
now that Opus exists and does everything Vorbis did, except better, there's probably no point in trying to improve Vorbis further. I doubt the lack of development is due to technical limitations; it probably just stems from a lack of developer interest. Why work on Vorbis when you could work on Opus?
That was kinda the situation a number of years ago, I guess when WebM and YouTube went full Opus.
Now ... why work on Opus when Opus works by itself?
(Uh, and Theora is long forgotten I guess.)
Vorbis's main purpose was to be an open competitor to MP3
Is "open competitor to mp3" really even a selling point now since the last known mp3 patent expired over 5 years ago?
And this is coming from someone, who to riff off of the "most interesting man in the world" meme, can say "I don't always encode lossy audio, but when I do, I encode to Opus."
AFAIK Vorbis's full potential likely remains unachieved. Maybe that's just how the cookie crumbles - the formats are designed with headroom for improvement potential that just becomes too cumbersome to reach.
Vorbis's main purpose was to be an open competitor to MP3, and now that Opus exists and does everything Vorbis did, except better, there's probably no point in trying to improve Vorbis further. I doubt the lack of development is due to technical limitations; it probably just stems from a lack of developer interest. Why work on Vorbis when you could work on Opus?
I mean sure, but the question is incomplete - what was the incentive for making a technical improvement to Vorbis in the form of Opus, when Vorbis itself wasn't even developed to the point that its technical limitations started being a hindrance?
It's a sort of chicken-and-egg problem - sure,
once you have a new format that's better than a pre-existing one, it doesn't make much sense to further develop the older format (although it's debatable how much that applies to Vorbis, because the hardware support for Opus is lagging behind Vorbis even more than it is lagging for Vorbis behind MP3 - just check any currently manufactured portable media player). But in order for that new format to come into existence in the first place, a shift of energy and effort away from improving the pre-existing format and into the development of the new format was necessary. And that clearly can't be explained by the new format being better than the old one, because the new format doesn't even exist before it is developed.
And also, is this what awaits Opus itself as well? Opus likewise still has room for improvement, yet it seems the energy and pace of development has sort of lulled.
I suppose the crucial question is - are lossy audio format developers stuck in that same loop I get stuck in with Bethesda games, where I'm all excited about creating a new character, but then when I actually start playing the game with that new character, I get bored?
Vorbis's main purpose was to be an open competitor to MP3
Is "open competitor to mp3" really even a selling point now since the last known mp3 patent expired over 5 years ago?
No, but note the past tense in what you quote.
And - I guess with the exception of YouTube before they turned Opus - Vorbis never really turned out to be as much of an open
competitor as it served as a
threat of such competition. Thus it fulfilled part of its purpose by chilling Fraunhofer and other MP3 IP claimants at bay. Read the introduction of the Wikipedia entry (https://en.wikipedia.org/wiki/Vorbis) about that. It refers to https://www.xiph.org/about/ for this - see the headline "
Example: An 'open' standard closes".
That was 1998. Fifteen years later, Vorbis had helped - not single-handedly though - achieve quite a few of the objectives for launching it, by just being there and being good enough. Fraunhofer had to think twice over trying to charge a cent for each .mp3 file created. And the DRM infestation could have fared much better hadn't the big competition - which turned out to be MP3, but which might have been "MP3 & Vorbis" had Fraunhofer & friends been more careless - been so much more tempting.
... dang, the Xiph.org wiki still hasn't picked up that Opus
even allowed in WebM: https://wiki.xiph.org/index.php?title=OpusFAQ&oldid=13856#Will_Opus_replace_Vorbis_in_video_files.3F
(Uh, and Theora is long forgotten I guess.)
Theora was an open competitor to DivX/XviD, and all of them were obsoleted by VP8/H.264, so I don't blame Xiph for abandoning Theora at all.
And also, is this what awaits Opus itself as well? Opus likewise still has room for improvement, yet it seems the energy and pace of development has sort of lulled.
I suppose that's possible, but it seems like the momentum on lossy audio development has slowed overall, perhaps because it's reached the point of diminishing returns. Although AAC and Opus are superior to MP3, they don't even manage to reach a 2X compression advantage over MP3 if you're trying to reach transparency. HA listening tests indicate that 96 kbps AAC/Opus are very respectable but not quite transparent, whereas 128 kbps MP3 is very respectable but not quite transparent, either, at least as far as the test samples are concerned.
Compatibility is also a huge factor. I see no reason to use AAC or Opus at ~128 kbps when LAME V3 has essentially perfect compatibility and produces only slightly larger files.
Is it possible to come up with a new lossy codec that will achieve transparency on most material at 64 kbps? Maybe, but considering how fast Internet speeds are and how large hard drives have become, is there any point in trying to develop that codec when current lossy options are more than adequate?
There are other reasons to use Opus than sound quality. It was developed for low latency. Of course it had to perform well in order to be adopted, but with all the know-how of twenty years of lossy compression (and the CPU available to do the compression job!), it isn't much of a suprise to see it outperform MP3 in tests.
As for compatibility ... sure, MP3 plays everywhere, but what current players cannot handle AAC in MP4 container?
Myself I started using Opus for portable use because at the time, all my .opus files would be transcodes and I would know they were therefore disposable. Besides, it was for a while fun to hear 32 kbit/s sounding like music, but the "disposable" part came into play quite soon. (At the risk of TOS8 violation here, but ... I guess the intransparency of 32 kbit/s isn't controversial.)
And also, is this what awaits Opus itself as well? Opus likewise still has room for improvement, yet it seems the energy and pace of development has sort of lulled.
I suppose that's possible, but it seems like the momentum on lossy audio development has slowed overall, perhaps because it's reached the point of diminishing returns. Although AAC and Opus are superior to MP3, they don't even manage to reach a 2X compression advantage over MP3 if you're trying to reach transparency. HA listening tests indicate that 96 kbps AAC/Opus are very respectable but not quite transparent, whereas 128 kbps MP3 is very respectable but not quite transparent, either, at least as far as the test samples are concerned.
Compatibility is also a huge factor. I see no reason to use AAC or Opus at ~128 kbps when LAME V3 has essentially perfect compatibility and produces only slightly larger files.
Is it possible to come up with a new lossy codec that will achieve transparency on most material at 64 kbps? Maybe, but considering how fast Internet speeds are and how large hard drives have become, is there any point in trying to develop that codec when current lossy options are more than adequate?
Pretty much everything you've said provides all the more reason for me to wish you had addressed the
first question I've posed in that post (as well as the elaboration of the rationale behind it in the 2nd paragraph), rather than the second one which was more of a rhetorical aside.
IIRC there was some disagreement regarding whether Vorbis was truly unencumbered by patents, so perhaps Xiph simply wanted a clean break to ensure the next format would be indisputably open. As for any technical reasons why it made more sense to start developing Opus instead of continuing to improve Vorbis, I'm not qualified to make such an assessment. All I know is Opus uses some newer techniques (CELT, CELP, SILK), so maybe those techniques are so much better than the plain MDCT approach that Vorbis uses that improvements to Vorbis would not transfer over to Opus. Maybe a developer can give a definitive answer to your question.
I was hoping for better gapless and glitchness encoding: https://hydrogenaud.io/index.php?topic=116605.0
All right, that is a point. 1990s called and wanted their MP3 back ...
Opus-tools v0.2-29-gecd50e5 (using libopus 1.3.1-107-gccaaffa9)
Built on May 23, 2022, GCC 12.1.0
John at rarewares has just uploaded 32 bit and 64 bit compiles of Opus 1.3.1
https://rarewares.org/opus.php
John at rarewares has just uploaded 32 bit and 64 bit compiles of Opus 1.3.1
https://rarewares.org/opus.php
I'm using that one and get abysmal results. Wondering is something is wrong. On long sawwave kind of pads/drones, it is kind of ducking/oscillating. Will show samples tomorrow as I'm still wondering if there's something wrong in my side. It's on fb2k convert "--quiet --bitrate 128 --vbr --music - %d" - I hear easily audible and annoying loudness instability, as in ducking, as popular in IDM, all over the place. EDIT: It's not in the opus->wav convert. Good, so it must be something wrong in the fb2k decoding process.
Opus-tools v0.2-29-gecd50e5 (using libopus 1.3.1-110-g57ddf37c)
Built on June 27, 2022, GCC 12.1.0
https://www.mediafire.com/file/m6s1hv7eycvj5yc/
I'm using that one and get abysmal results. Wondering is something is wrong. On long sawwave kind of pads/drones, it is kind of ducking/oscillating. Will show samples tomorrow as I'm still wondering if there's something wrong in my side. It's on fb2k convert "--quiet --bitrate 128 --vbr --music - %d" - I hear easily audible and annoying loudness instability, as in ducking, as popular in IDM, all over the place. EDIT: It's not in the opus->wav convert. Good, so it must be something wrong in the fb2k decoding process.
Would be appreciated if you could share a sample file that plays incorrectly in foobar2000 yet decodes correctly using Opus tools.
Thanks.
Would be appreciated if you could share a sample file that plays incorrectly in foobar2000 yet decodes correctly using Opus tools.
Will do tomorrow, I'm definitely interested in what exactly was going on here.
Hi Peter, it was an issue of a massive volume boost, not precisely related to OPUS.
https://hydrogenaud.io/index.php/topic,122631.msg1012146.html#msg1012146
John at rarewares has just uploaded 32 bit and 64 bit compiles of Opus 1.3.1
https://rarewares.org/opus.php
I'm using that one and get abysmal results. Wondering is something is wrong. On long sawwave kind of pads/drones, it is kind of ducking/oscillating. Will show samples tomorrow as I'm still wondering if there's something wrong in my side. It's on fb2k convert "--quiet --bitrate 128 --vbr --music - %d" - I hear easily audible and annoying loudness instability, as in ducking, as popular in IDM, all over the place. EDIT: It's not in the opus->wav convert. Good, so it must be something wrong in the fb2k decoding process.
Out of interest did you try the netranger compile? The rarewares compiles seem to be alot bigger then other builds I've seen so wondered if any difference in sound quality.
Opus-tools v0.2-29-gecd50e5 (using libopus 1.3.1-142-gcaf56aab)
Built on July 09, 2022, GCC 12.1.0
DL :
https://www.mediafire.com/file/eixdfn72l14ekqn/
The rarewares compiles seem to be alot bigger then other builds I've seen so wondered if any difference in sound quality.
There are many possible reasons a compile of the same code can be larger. For example
- Duplicating functions optimized for different CPUs
- Including debugging symbols
- Including (part of) the C runtime
- Including optional code/features
For example, flac compiled with minGW can be around 1400kb while compiled with Visual Studio it is only 300kb. This difference is because of the first three reasons mentions above.
These reasons seem a far more likely explanation than anything that has to do with quality of the output.
General question out of interest, and as I'm not really into Opus: Is the codec "actively" developed on the psychoacustic level (Ie I do not mean improvements in tag handling etc...) or rather... "set"? Because it's 3 years now... Thx guys
With "active" I mean..., e.g., see TAK lossless. Nobody uses it except some very few people, but it's always improved.
Is the codec "actively" developed on the psychoacustic level (Ie I do not mean improvements in tag handling etc...) or rather... "set"? Because it's 3 years now...
You kind of answered your own question. Do you consider a period of three years since the last quality improvement to mean that Opus is no longer meaningfully improved? It sounds like you do.
Do you consider a period of three years since the last quality improvement to mean that Opus is no longer meaningfully improved? It sounds like you do.
I was off the audio scene. So I asked. Three years mean nothing, it's just an amount of years. "Quite a few people are often tuning the codec enthusiastically" is a possibility, but also "there is one guy, now he works for a big corp, we haven't heard of him for 2 years".
Is the codec "actively" developed on the psychoacustic level (Ie I do not mean improvements in tag handling etc...) or rather... "set"? Because it's 3 years now...
You kind of answered your own question. Do you consider a period of three years since the last quality improvement to mean that Opus is no longer meaningfully improved? It sounds like you do.
"Opus development finished", said IgorC.
https://hydrogenaud.io/index.php/topic,120007.msg997568.html#msg997568
"Opus development finished", said IgorC.
Too bad that one have to type:
opusenc file.wav file.opusinstead like with oggenc, simply:
oggenc *It force to write a bash script to encode multiple files :(
"Opus development finished", said IgorC.
Too bad that one have to type:
opusenc file.wav file.opus
instead like with oggenc, simply:
oggenc *
It force to write a bash script to encode multiple files :(
You can use foobar2000 to make encoding much, much easier. If you are using linux, it works under wine very well. ;)
Opus-tools v0.2-29-gecd50e5 (using libopus 1.3.1-158-gbce1f392)
Built on September 08, 2022, GCC 12.2.0
DL :
https://www.mediafire.com/file/eydfo2k81xno6li/
Is the codec "actively" developed on the psychoacustic level (Ie I do not mean improvements in tag handling etc...) or rather... "set"? Because it's 3 years now...
You kind of answered your own question. Do you consider a period of three years since the last quality improvement to mean that Opus is no longer meaningfully improved? It sounds like you do.
"Opus development finished", said IgorC.
https://hydrogenaud.io/index.php/topic,120007.msg997568.html#msg997568
Since xiph.org foundation released the latest Opus version 1.3.1, they are experimenting to increase encoding efficiency, about 30% bitrate reduction with the same speech and sound quality.
The compatibility of the old existing playback applications is maintained.
have a look there.
sheets:
https://arxiv.org/pdf/1905.04628v1.pdf
Repositories, branches:
https://github.com/xiph/LPCNet
https://gitlab.xiph.org/xiph/opus/-/tree/exp_neural_fec2
https://gitlab.xiph.org/xiph/opus/-/tree/neural_plc
https://gitlab.xiph.org/xiph/opus/-/tree/exp_plc_hack4
Opus-tools v0.2-29-gecd50e5 (using libopus 1.3.1-158-gbce1f392)
Built on September 08, 2022, GCC 12.2.0
DL :
https://www.mediafire.com/file/eydfo2k81xno6li/
thank you! Do you know if there has been any update this year?
There sure have been changes: https://github.com/xiph/opus/commits/master
3 commits fixing stuff users aren't worried with, so that last build can still be considered up-to-date
Opus-tools v0.2-29-gecd50e5 (using libopus 1.3.1-160-g8cf872a1)
Built on February 08, 2023, GCC 12.2.0
DL :
https://www.mediafire.com/file/147bjlue1zlk4xy/
Opus-tools v0.2-29-gecd50e5 (using libopus 1.3.1-160-g8cf872a1)
Built on February 08, 2023, GCC 12.2.0
Can someone please compile this for AMD Zen3 CPUs? :))