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 vs EVS at lowest bit rates (Read 7875 times) previous topic - next topic
0 Members and 1 Guest are viewing this topic.

Opus vs EVS at lowest bit rates

I've been playing around with EVS recently, and it totally annihilated Opus and all the flavours of AAC I tried (latest FDKAAC) at low bit rates. I'm talking 6-16 kbps for mono at 48 kHz, EVS at its lowest 5900 bps (real output with MIME overhead is around 6300 bps) is as good as Opus at 16 kbps.
Is it a known issue?

Re: Opus vs EVS at lowest bit rates

Reply #1
You mean for voice or music?

Re: Opus vs EVS at lowest bit rates

Reply #2
An old comparison between EVS and old version of  Opus . https://www.researchgate.net/publication/282605143_Subjective_quality_evaluation_of_the_3GPP_EVS_codec

The last version of Opus performs much better.

I'm talking 6-16 kbps for mono at 48 kHz, EVS at its lowest 5900 bps (real output with MIME overhead is around 6300 bps) is as good as Opus at 16 kbps.
EVS 6 kbps is WB (16 kHz) while Opus 16 kbps is FB (48 kHz).  It would be strange  if EVS would perform that good.


Re: Opus vs EVS at lowest bit rates

Reply #3
I was testing speech only, namely "The birch canoe slid...". Opus might improve a lot since then (actually I don't like the latest trade-off of wider band for more distortions, I prefer JM Valin's original tuning), but imo the lowest bit rates are still much much worse than EVS. There are some encodings I made (decoder output is there too, it's raw s16le LPCM, 1 channel, 48 kHz - you can do Import -> Raw Data in Audacity and listen to them side by side): https://we.tl/t-NpMQvM3txD

Re: Opus vs EVS at lowest bit rates

Reply #4
Btw, I'm not affiliated to EVS in any way, I was just doing some research to chose the best VOIP codec for the app I'm working on. I do really like Opus, it's free, flexible and easy to integrate, my main goal here is to push the Opus devs to improve low bit rate performance :)

Re: Opus vs EVS at lowest bit rates

Reply #5
well, in this age of fast connections and big storages
I'd rather have it be free from issues on various edge cases where it becomes non transparent with any bitrate (I'm talking about situations where there's a lot of low frequency energy and there's almost nothing above them to mask distortion which Opus creates)
but to each their own
a fan of AutoEq + Meier Crossfeed

Re: Opus vs EVS at lowest bit rates

Reply #6
What is the original sample? if it is free, can you send me the link? In 2020, it will be a successor of EVS codec?


Re: Opus vs EVS at lowest bit rates

Reply #8
There's an interesting secret knob JMV used for Opus 1.3 demo (ENCODER_OPTIONS=--bitrate 48 --set-ctl-int 4000=2048), gonna try it to see if it helps

Re: Opus vs EVS at lowest bit rates

Reply #9
EVS files are lowered in pitch.

Re: Opus vs EVS at lowest bit rates

Reply #10
EVS files are lowered in pitch.
I don't think they are any different from the original other than loss of high frequencies at low bit rates (at 16.4 kbps it's as good as the reference imo). I compared spectra and waveforms and found no signs whatsoever of any sort of frequency shifts or pitch discrepancies (I can send some screenshots from Audacity if needed). So how did you come to this conclusion? Did you import them with wrong sampling rate? (I think Audacity's default is 44.1k while I used 48k)

Re: Opus vs EVS at lowest bit rates

Reply #11
EVS 6 kbps is WB (16 kHz) while Opus 16 kbps is FB (48 kHz).  It would be strange  if EVS would perform that good.
You're right, I listened to it a few times more, and my conclusion is 9.6 kbps EVS (it's SWB at this rate, Audacity shows 14 kHz band) sounds very similar to Opus at 16.4 kbps. Opus' high frequencies are a bit messed up at this bit rate though, it sounds like hiss and makes speech kinda mushy, EVS sounds cleaner

Re: Opus vs EVS at lowest bit rates

Reply #12
EVS files are lowered in pitch.

The pitch isn't different, but the RAW files are 24KHz versus the original 48KHz.

I've tested Opus 1.3 with a number of settings, and the results are still messy. EVS is just better optimized for voice quality under 13kbps.

Re: Opus vs EVS at lowest bit rates

Reply #13
Amongst other things, Opus has a significantly lower latency than EVS (an order of magnitude lower if you really want to push it) and this surely doesn't help the quality at these bitrates.  Opus aimed to be many things, but low latency was nearer the top of the list than absolute highest quality.  It also aims to do almost everything very well, but there are certainly specific tasks where other codecs perform better. I've never tried EVS, but as a relatively modern codec optimised for high quality speech at very low bitrates, it wouldn't surprise me that it could do better than Opus.  Very much non-free though.

Re: Opus vs EVS at lowest bit rates

Reply #14
Opus has a significantly lower latency than EVS (an order of magnitude lower if you really want to push it)
I do want to push it. Any links to actual latency comparisons? Quick googling leads me to conclusion that Opus in SILK mode produces 20 + 5 + 1.5 ms latency (https://jmvalin.ca/papers/aes135_opus_celt.pdf), while for EVS it's 20 + 12 ms (http://www.voiceage.com/EVS.html). Is it an order of magnitude in your opinion?

Re: Opus vs EVS at lowest bit rates

Reply #15
The pitch isn't different, but the RAW files are 24KHz versus the original 48KHz.
Every single raw file I uploaded is sampled 48 kHz. Some of them are band-limited of course (both EVS and Opus) - every half-decent audio encoder does low pass filtering before encoding if the requested bit rate is too low to produce quality full-band output

Re: Opus vs EVS at lowest bit rates

Reply #16
The default algorithmic delay in Opus is 26.5 ms (in SILK mode or hybrid mode, 22.5 ms in CELT-only mode).  However, if latency is your main concern, you can reduce this to as low 5 ms.  This hurts the quality.  At low bitrates it hurts the quality badly.  You might like to try encoding with 2.5 ms frames and see what you think.  More practically, 10 ms frames can be used at low bitrates without major headaches.  This gives an algorithmic delay of 16.5 ms.

Re: Opus vs EVS at lowest bit rates

Reply #17
Every single raw file I uploaded is sampled 48 kHz.
I see, Foobar was reading them as stereo, hence half the correct rate to make them work...  :-[

Re: Opus vs EVS at lowest bit rates

Reply #18
@lithopsian I’m actually interested in longer frames in order to reduce TLS/DTLS overhead. Even 20 ms is unnecessary short when you can get 50-100 ms jitter on WiFi link alone (that’s what I observe when two machines on the same WiFi ping each other)

 

Re: Opus vs EVS at lowest bit rates

Reply #19
@theislander: I believe you don't understand what codec latency means.

* Codec latency means how many audio samples do I need before I can create the smallest portion of audio that I can generate.
* Transport latency and jitter (your example) means how long it might take for the data to go from the sender to the receiver.
(Additionally, bandwidth means the amount of data that can be sent over the span of one second which depends on multiple factors so lower latency doesn't necessarily mean higher bandwidth).
* And then we have sound driver latency, which is the maximum time it will take for something sent to the audio buffer to reach the speakers (or the recording application)

When a codec is meant to be used for realtime interaction ( chat/phone , or other interactive audio applications) you want low latency on all three of these places, because the latency accumulates rather than compensate.

In other words, If I have a codec with 100ms latency,  a net connection with 100ms latency+max jitter + an audio buffer of 100ms,  I have 300ms of latency, not 100.

Another example, codec latency of 10ms, net connection latency of 10ms + audio latency of 10ms. You have 30ms there.
Then, somehow you get jitter of 10ms so the audio stops, and the application decides to increase the connection buffer to avoid skips. You then have a codec latency of 10ms, net connection latency of 10ms, application buffer of 10ms and audio buffer of 10ms for a total of 40ms.

Of course, if you are after reducing the amount of fixed size network packets, obviously they need to have more data in there, but you are trading audio latency for bandwidth, not for network latency.

Re: Opus vs EVS at lowest bit rates

Reply #20
@theislander: I believe you don't understand what codec latency means
I've been working professionally on audio/video compression and streaming for the last 18 years and I do know a thing or two about latencies, don't waste your breath

Re: Opus vs EVS at lowest bit rates

Reply #21
@theislander
Out of curiosity.  Are You in conditions actually to deploy EVS in your VoIP app? I mean license agreements, costs etc.
I'm asking because I haven't see any application which uses EVS. As far as I know EVS was developed by and for big [mainly] Telco corporations in their infrastructures.

It's evident that EVS is better than Opus at low bitrates.  However even such big company like Cisco uses Opus for its applications (Webex etc.). A little bit of extra bandwidth cost is cheaper than EVS licensing (?) https://www.cisco.com/c/en/us/products/collateral/conferencing/webex-meetings/white_paper_c11-691351.html

There is no one who use new formats EVS/USAC/AC-4 on this forum either . https://hydrogenaud.io/index.php?topic=118233.msg976864#new
No available implementations, nada.

Re: Opus vs EVS at lowest bit rates

Reply #22
actually to deploy EVS in your VoIP app? I mean license agreements, costs etc.
It's probably a pain in the back, still waiting for feedback from the management. EVS is implemented in hardware in virtually every decent modern phone (Apple is using EVS-capable Qualcomm modems since iPhone 7, Snapdragons 8XX support it too), but there's no software encoding/decoding API neither on Android nor iOS. I guess Qualcomm is not exactly easy-going about their proprietary technologies.
Anyway, my point is EVS shows there's still a lot of space for improvement for Opus. JVM, please do something :)