Skip to main content

Topic: Opus 1.2-rc1 (Read 5008 times) previous topic - next topic

0 Members and 1 Guest are viewing this topic.
  • jmvalin
  • [*][*][*][*][*]
  • Developer
Opus 1.2-rc1
I'd like to announce the release of Opus 1.2-rc1. It is the first release candidate of the upcoming Opus 1.2 release. If no issues are found with it, it will soon become 1.2-final, so we encourage everyone to give it a try. Changes compared to 1.2-beta include:
  • Improved quality on files with powerful tones that cause MDCT leakage
  • Improved bit allocation on mode transitions (CELT to/from SILK/hybrid)
  • More ARM Neon optimizations
  • Fixes to the speech/music detection at the very beginning of files
  • Fixes to the unit tests (fixes illegal instructions and –disable-static)

You can get it from the download page: https://www.opus-codec.org/downloads/

Please try it and report any issues you find.

  • Anakunda
  • [*][*][*][*][*]
Re: Opus 1.2-rc1
Reply #1
Thanx jmvalin, I attach initial builds, ofcourse for testing only  :))


  • Kamedo2
  • [*][*][*][*]
Re: Opus 1.2-rc1
Reply #2
Thanx jmvalin, I attach initial builds, ofcourse for testing only  :))
Are there any builds that support older CPUs?
I've got this error on Ryzen 5.
Code: [Select]
opusinfo.exe --help

Please verify that both the operating system and the processor support Intel(R) X87, CMOV, MMX, FXSAVE, SSE, SSE2, SSE3, SSSE3, SSE4_1, SSE4_2, MOVBE, POPCNT, F16C, AVX, FMA, BMI, LZCNT and AVX2 instructions.

  • LithosZA
  • [*][*][*][*]
Re: Opus 1.2-rc1
Reply #3
From: https://community.amd.com/message/2789076
Quote
SOLVED!
I was told (on Intel Developer Zone Forum) the culprit was my wrong usage of /Qxsse4.1 instead of  /archSSE4.1 , the first checks whether the CPU is Intel whereas the second uses the extension without checking:
Code compiled as SSE4.1 crashes under Ryzen 1800X

  • Anakunda
  • [*][*][*][*][*]
Re: Opus 1.2-rc1
Reply #4
Are there any builds that support older CPUs?
I've got this error on Ryzen 5.

Idk how old is Ryzen 5, these opus tools are built with cross platform optimizations (--Qax...) but possibly older CPUs aren't supported yet and I can't help. Wait for other builds then.
In case of complains about missing Intel runtimes, these were forgotten to include but can be found in opus alpha.
  • Last Edit: 10 June, 2017, 03:06:40 AM by Anakunda

  • Emre
  • [*]
Re: Opus 1.2-rc1
Reply #5
@Kamedo2

please test my build. compiled with GCC 7.1. FYI i use --enable-update-draft in configure.

  • kode54
  • [*][*][*][*][*]
  • Administrator
Re: Opus 1.2-rc1
Reply #6
Idk how old is Ryzen 5
Brand spanking new, just released this year. Should definitely support everything up to AVX2.

  • LithosZA
  • [*][*][*][*]
Re: Opus 1.2-rc1
Reply #7
Idk how old is Ryzen 5
Brand spanking new, just released this year. Should definitely support everything up to AVX2.
3 Months old :)

The GCC builds work fine.
Maybe a '/Qx.. ' switch was accidentally used in the Intel compiler. It should be '/Qax..' combined with '/arch...' or just '/arch...' alone.

  • [JAZ]
  • [*][*][*][*][*]
Re: Opus 1.2-rc1
Reply #8
Intel core i7 6700. Run with default parameters on a Windows 10 64bits:
Anakunda's icc x86:  52x realtime
Anakunda's icc x64:  61x realtime
Emre gcc x64: 73x or 91x realtime .
Ok explanation: As i see, the realtime indicator uses integer seconds to determine the speed, and for the gcc encoding it shows 4 seconds or 5 seconds depending on the run. Probably takes something like 4.9xxx and others 5.0xxx ( or  4.4xxx and 4.5xxx) but due to truncating/rounding, that difference is shown as reported.

That's for a 6 minutes song at 96Khz. Times are almost the same for another 6 minute wav at 44Khz.

There is also a difference in bytes, probably an indication of different floating point modes (or instructions):
gcc:
         Wrote: 5269602 bytes, 18256 packets, 368 pages
       Bitrate: 114.643kbit/s (without overhead)
 Instant rates: 57.2kbit/s to 192.8kbit/s
                (143 to 482 bytes per packet)
icc:
         Wrote: 5272107 bytes, 18256 packets, 368 pages
       Bitrate: 114.697kbit/s (without overhead)
 Instant rates: 58.4kbit/s to 192.8kbit/s
                (146 to 482 bytes per packet)
  • Last Edit: 11 June, 2017, 08:48:42 AM by [JAZ]

  • [JAZ]
  • [*][*][*][*][*]
Re: Opus 1.2-rc1
Reply #9
Hi again.
I was doing some bitrate tests and found a difference that I don't know if it is intentional or not.

I generated a 10 second 440Hz -6dbFS mono sine wave and encoded it with --bitrate 32 using 1.1.2 and 1.2

1.1.2: Bitrate: 34.3082kbit/s Instant rates: 30.4kbit/s to 35.6kbit/s
1.2: Bitrate: 65.0331kbit/s  Instant rates: 50.8kbit/s to 66.4kbit/s
(I also did the same test with stereo at 64kbps, which resulted in 95kbit/s for 1.1.2 and 117kbit/s for 1.2.)

Audibly, they sound the same, but on the spectogram one can see that there is more noise in the 32kbps 1.1.2 encoding (probably because it uses half the bitrate of 1.2).

Also...is this normal too? Is a sine wave one of the most difficult signals to encode for Opus?
  Output: 1 channel (1 uncoupled) 20ms packets, 256kbit/sec VBR
       Bitrate: 283.752kbit/s (without overhead)
 Instant rates: 275.6kbit/s to 442kbit/s
----------------------------------------------
  Output: 2 channels (2 coupled) 20ms packets, 512kbit/sec VBR
       Bitrate: 510.4kbit/s (without overhead)
 Instant rates: 510.4kbit/s to 510.4kbit/s


  • IgorC
  • [*][*][*][*][*]
Re: Opus 1.2-rc1
Reply #10
I generated a 10 second 440Hz -6dbFS mono sine wave and encoded it with --bitrate 32 using 1.1.2 and 1.2
I'm not a codec developer but we were through this many times (especially here on HA) 
It's useless to test codecs on pure tones or any other synthetic kind of signals those are not classified as  speech, music, mix speech/music or some kind of ambient/natural sounds.
The same way nobody tests video codecs on squares of different colors.

Audibly, they sound the same, but on the spectogram ...
...

Is a sine wave one of the most difficult signals to encode for Opus?
Yes, Opus is a low delay codec and  tonal samples are difficult due to spectral leakage. Opus keeps high quality on tonal samples by increasing/allocating bitrate on them in CBR/ABR/VBR modes.
 
  • Last Edit: 11 June, 2017, 03:48:08 PM by IgorC

  • [JAZ]
  • [*][*][*][*][*]
Re: Opus 1.2-rc1
Reply #11
It's useless to test codecs on pure tones or any other synthetic kind of signals those are not classified as  speech, music, mix speech/music or some kind of ambient/natural sounds.
Well, recently we were also talking about chiptunes too, OPL3, SID...
I was just looking for a simple signal that generated a low bitrate but I clearly choose the wrong type of sample.

What still remains, and the only point of my thread is if the increase of bitrate that I've seen is intentional or unintentional.

Audibly, they sound the same, but on the spectogram ...
If the words "spectogram","spectrum", or whatever other method to graphically represent a sound become taboo words here, we will need to avoid talking about the fourier transforms, frequencies, waves and any other thing that represents sound.
I did NOT use it to talk about quality. I was specifically asking if the increase of bitrate had to do with what was visible on the spectrum.

  • jmvalin
  • [*][*][*][*][*]
  • Developer
Re: Opus 1.2-rc1
Reply #12
What still remains, and the only point of my thread is if the increase of bitrate that I've seen is intentional or unintentional.
It is absolutely intentional. What happens is that in 1.1.x we were explicitly preventing bitrate from varying too much. That's now gone in 1.2, which has helped increase low bitrate quality.

  • IgorC
  • [*][*][*][*][*]
Re: Opus 1.2-rc1
Reply #13
What still remains, and the only point of my thread is if the increase of bitrate that I've seen is intentional or unintentional.
That's fine.
But even if the increase of bitrate was unintentional it still wouldn't change anything.
Nobody will move a finger to "fix" non existent problem (an increase of bitate on pure tone sample).

  • Klimis
  • [*]
Re: Opus 1.2-rc1
Reply #14
I don't know if anything changed since the last time I updated the binary but OPUS (atleast to me) seems to have surpassed AAC by alot on multichannel audio. I'm in the process of ABX'ing a couple of BluRay albums and the transparency thresshold seems to have dropped in bitrates lower that what I have tested with AAC.

  • NetRanger
  • [*][*][*]
Re: Opus 1.2-rc1
Reply #15
Opus-tools v0.1.10-9-gbd65450 (using libopus 1.2-rc1-7-g4de224e2)
32 & 64 bit Windows Binaries

  • Kamedo2
  • [*][*][*][*]
Re: Opus 1.2-rc1
Reply #16
I encoded opus with all those combinations of parameters below, using Emre's build. There were no crashes, nor failure to output the files. 10x4x7x8x4 x 9 = 80,640 encoded opus files.
Code: [Select]
                 ["","--bitrate 8.000", "--bitrate 16.000", "--bitrate 32.000", "--bitrate 48.000", "--bitrate 64.000", "--bitrate 96", "--bitrate 128", "--bitrate 160", "--bitrate 320"],
                 ["","--vbr", "--cvbr", "--hard-cbr"],
                 ["","--framesize 2.5", "--framesize 5", "--framesize 10", "--framesize 20", "--framesize 40", "--framesize 60"],
                 ["","--comp 0", "--comp 2", "--comp 4", "--comp 6", "--comp 8", "--comp 9", "--comp 10"],
                 ["","--expect-loss 75","--expect-loss 50", "--expect-loss 25"]
20 seconds of 7 artificial signal tracks and about 20 seconds of 2 music tracks, total 9 tracks were used as test tracks.
Code: [Select]
19.95	spray_can_noise_right.wav
19.86 Tom's Diner.wav
20 sin_441Hz.wav
20 sin_20000Hz.wav
20 maxwave_88k_20.wav
20 sinsweep_88k_20.wav
20 noise_20.wav
20 pinknoise_88k_20.wav
20 whitenoise_88k_20.wav

  • Emre
  • [*]
Re: Opus 1.2-rc1
Reply #17
Opus 1.2 is here.
built with GCC 7.1.0 for 64bit. --enable-update-draft used in configure so Low-Bitrate Hybrid Folding and Decoder Mono Downmix enabled in this build.

Cheers.

  • jmvalin
  • [*][*][*][*][*]
  • Developer
Re: Opus 1.2-rc1
Reply #18
See the 1.2 announcement thread at: https://hydrogenaud.io/index.php/topic,114234.0.html