The new OPUS codec
I was reading a thread on Reddit about a new audio codec, and I was going to post a reply to someone who was wrong on the internet. People were talking like mp3 was going to disappear and Linux would have the year of the desktop, and I was going lash out at the naiveity, but the TFA and related sites are pretty clear on the actual purpose of this codec.
From boingboing's article:
"The IETF has finished its standardization effort for Opus, a new free/open audio codec that reportedly outperforms all other codecs on all axes."
Obviously wary about a huge claim like that, I had to dig a bit. From IETF's abstract:
"This document describes the Opus codec, designed for interactive speech and audio transmission over the Internet."
Audio enthusiast site HydrogenAudio does real testing of digitally treated audio and supposedly has demonstrated that all existing formats encoded at over 128kbps yield inconclusive results in double-blind testing and so OPUS is apparently untested in that area.
OPUS focuses on low latency in the 64-96kbps@48k range, which makes this a decent option for for large-scale network streaming, exactly like the project claims. Encoding one single stream at that quality is not even noticeable on modern CPU, and this codec is not primarily for high fidelity listening even though the authors claims it can be used for music up to 512kbps@48k. It's designed to deal with network latency and packet drops.
Now, what got me thinking was that since HA does not even test files over 128kbps, yet I have often been able to recognize them when I had higher qualities available.
I was wondering what kind of demography HA did this test on. Was it musicians, producers and the like or was it a random group? It matters because if you work a lot with sound and music, you will eventually be able to identify a low bitrate song
This post by IgorC on is interesting and got me questioning the testing procedure. They are operating with sample sizes around 30 and 40, which I think is small, and considering the facts about subjects IgorC points out, maybe the grounds for a claim to beat every other codec on the planet is a bit high at this time. Even the authors does not claim that their fresh 1.0.1 release competes with the best implementations of other codecs out there
Testing
A ~50MB .wav file (Metallica,'Figth Fire With Fire') was encoded to FLAC level 8 and it took 7 seconds with flac.exe trough Traders Little Helper.
Encoding the .wav to mp3 with 128kbps@44100 took 22.2 seconds with the latest VLC. For 48000khz, about 32 seconds. That is just the default settings, no encoder options. The output mp3 was about 4.5MB.
Using winLame 2010 with LAME 3.99 and "-V2 --vbr-new" took 7 seconds, and 10 with the best compression "-b 320 --cbr". The 7-second output mp3 was 11.1MB.
Then it was time to try out the OPUS encoder, which still is a CLI only app.
OPUS with default setting produced a file of 3.4MB running at 94kbps in 6 seconds.
Using OPUS with --bitrate 256 produced a 8.5MB file with 255.6kbps bitrate in 7 seconds.
That would be about the same speed as FLAC, if you can even compare these two, since FLAC produces lossless quality at nearly 1Mbit bitrate, nearly triple as much data troughput as OPUS.
I further tried --96, and --128 and they use the same amount of time, around 6-7 seconds.
Streaming
Using rtp via VLC, streaming the first 128kbps mp3 encoded from an instance of VLC to another on the same host takes between 0 to 1 % in the encoding thread, and you can't even tell that the playback thread uses CPU time.
That would be about the same speed as FLAC, if you can even compare these two, since FLAC produces lossless quality at nearly 1Mbit bitrate, nearly triple as much data troughput as OPUS.
I further tried --96, and --128 and they use the same amount of time, around 6-7 seconds.
Streaming
Using rtp via VLC, streaming the first 128kbps mp3 encoded from an instance of VLC to another on the same host takes between 0 to 1 % in the encoding thread, and you can't even tell that the playback thread uses CPU time.
The 11MB maximum-encoded mp3 file was then streamed, at almost the same CPU usage as the file nearly 1/3 as big. Occasional spikes to 2%, but mostly 0% and 1%.
I am inconclusive about streaming, since VLC doesn't support OPUS yet, but it seems to me that all three formats hoovers around 1% for decoding.
I am inconclusive about streaming, since VLC doesn't support OPUS yet, but it seems to me that all three formats hoovers around 1% for decoding.
Conclusion
From these simple tests, I have to conclude that OPUS is much slower to encode than recent FLAC and LAME releases at the moment. LAME and FLAC used about 30% and 37% CPU respectively while encoding, but OPUS used around 24%.
Playing back the OPUS file using the official CLI tools showed that the process doesn't even cross 1% to decode. FooBar2000 added support already, and shows a 1-2% CPU usage.
If this new codec can help huge organizations save bandwidth and CPU cycles, then good for them. It's irrelevant to end users not trapped in ISDN-land, but it may be a cost-saver if you are big inside the streaming industry.
Ofcourse, it's always nice to have more royalty-free codecs, but mp3 will be around a lot longer. And just to be clear, OPUS has already gotten attention from patent trolls, although the project claims these threats are groundless.(Qualcom and Huawei)
Further reading about audio:
XIPH.org explains why it's no point in being audiophile.
Ofcourse, it's always nice to have more royalty-free codecs, but mp3 will be around a lot longer. And just to be clear, OPUS has already gotten attention from patent trolls, although the project claims these threats are groundless.(Qualcom and Huawei)
Further reading about audio:
XIPH.org explains why it's no point in being audiophile.
