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.

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.

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.

Removing and installing Widcomm drivers

Trying to cut down on my heavy headset casualty record, I needed something wireless. I got Teknikmagasinet's custom BT500 headset. My 1-2 year old Targus Bluetooth USB mini dongle would not run handsfree audio correctly under the supplied Vista drivers. Even Windows 7 pointed me to new drivers available from Broadcom, so I downloaded these drivers. This software complains about old BlueTooth software already installed, only problem is there was no uninstaller. Uninstalling drivers from device manager did not do it. After some testing, I found this to work:

On another Win7 box:

1. Disable automatic driver updates
2. Insert dongle 
3. Answer no to install WHQ drivers
4. Wait until all the USB discovering is over... could take a minute or two. (does not depend on your computer speed!)
5. Install SE software
6. Answer yes to all drivers from here on
7. I had to cancel and reinsert dongle during device verification
8. Copy Users/User/Appdate/Widcomm/Software to target machine

On target machine:

1. Repeat steps 1-4
2. Install retail drivers
3. Install software from other box

I ended up having an unknown defect device in the device manager but everything works. So it appears the old 64 bit drivers from Vista works, only the software itself needed to be upgraded. Choosing this approach was better than a system reinstall, and not even 1 hour in regedit would let me hack my way out of the Widcomm registry mess.

Recording studio box setup. (Updated)

This is a single core P4 2.39Ghz on an Intel board with a pretty standard SoundMax AC97 integrated audio, driving a secondary sound monitor.



It's centered around a EWS 88MT system (Digital 8 track recorder with external breakbox), PCI, used as main recording hardware. There's also two FireWire connectors on a PCI card I just added in case I would ever need it.


I have a ESP Ltd F200 guitar hooked to a Fender Mustang 1 guitar amp by USB in addition to regular cabling, of course. The only problem here is that the audio jack will be disabled when you connect the USB and fire up the Mustang software. So if you need the advanced amp settings, you need to store them locally on the amp it self. (Not true, I had some setup errors.) The only feature I miss from the Mustang is to be able to monitor the guitar trough the amp itself while also pushing the signal trough the jack out. (Which doubles as line out)

Also, a Creative Soundblaster Live! PCI card for driving a Sony Digital Amplifier (not pictured yet) for main monitoring.

EWS88MT front connectors

Overview

The Fender amp doesn't have a line out, but it has a phone jack which can be used.

Special cable resembling a parallell cable connects the breakbox to a PCI card. (bottom card)
It also has digital out/in jacks and a mini jack monitor output.

Drivers for the 88MT can be found at TerraTec's FTP server
There is drivers for Linux, 98->XP.
Supposedly the download for Phase88 (mixer app for the card) contains drivers that should work with Windows 7. (citation needed!)

This setup gave a very clear guitar recording. A very very slight hiss could be heard at times when I did not touch the guitar. Much better than onboard capturing that usually records PCI bus noise as well. I can't tell if the almost non-existing noise was from the amp or the computer I played it back at.

Installing a good digital amp reduced playback noise considerably as well. Initially I had a Nvidia GeForce FX 5500 card installed, but I decided to downgrade to the fanless 440MX card instead to further reduce system noise. I could also turn off both the NIC and onboard audio as well as other controllers if I wanted, but it seems pretty quiet now.

Only having one video monitor, I use Nvidia's virtual desktop to have separate desktops for recording, mixer panels, and so on. Also, I spent a good hour on setting the computer up for being mostly mouse driven. Added window autofocus, and had all studio applications pinned to the start menu, etc. This is pretty handy when you're still holding the guitar while needing to do something on the computer.

Applications used:


GNU Solfege, for ear training
Reaper for recording, has low latency, comprehensible UI and a good routing/monitoring interface
Audacity and CoolEdit for secondary editing. CoolEdit used to be my favourite (now Adobe Audition) but it did not play nice with my hardware this time)
VLC and FooBar2000 for media playback, will probably reinstall WinAmp again purely for the fact that it is the only application I know that rewinds on pressing the arrow keys. (Vital for my guitar practice)

This is now pretty much a self contained studio and could be moved around to do various recordings. It can to at least 8 tracks at once, though both the SoundBlaster and the integrated audio has more recording slots. The breakbox has one additional 9 pin mic as wel,l and it's card has two SPDIF's as well. All this at 16, 24 or 32 bits samples up to 96Khz. Seems most of the audio hardware and drivers are proper, since the CPU seems rather unaffected by activity in the audio applications.