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.
Thanx jmvalin, I attach initial builds, ofcourse for testing only :))
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.
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.
From: https://community.amd.com/message/2789076
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
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.
@Kamedo2 please test my build. compiled with GCC 7.1. FYI i use --enable-update-draft in configure.
Idk how old is Ryzen 5
Brand spanking new, just released this year. Should definitely support everything up to AVX2.
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.
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)
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
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.
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.
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.
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).
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.
Opus-tools v0.1.10-9-gbd65450 (using libopus 1.2-rc1-7-g4de224e2)
32 & 64 bit Windows Binaries
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.
["","--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.
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
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.
See the 1.2 announcement thread at: https://hydrogenaud.io/index.php/topic,114234.0.html