After much waiting, Opus 1.1.1 is finally here. The main changes are:
- x86 SSE, SSE2 and SSE4.1 optimizations contributed by Cisco,
- MIPS optimizations contributed by Imagination Technologies,
- ARM Neon optimizations contributed by Linaro and ARM,
- many architecture-independent optimizations,
- memory footprint reductions, and
- several minor bug fixes.
The quality of the encoder should be mostly unchanged compare to version 1.1. The code is available from the downloads page at: http://www.opus-codec.org/downloads/ (http://www.opus-codec.org/downloads/) or at: http://downloads.xiph.org/releases/opus/opus-1.1.1.tar.gz (http://downloads.xiph.org/releases/opus/opus-1.1.1.tar.gz)
In other news, we're currently working on improving low bit-rate quality (< 48 kb/s) for both speech and music. Stay tuned.
Good job, guys.
it's reported that Opus 1.1.1 decoder is even faster than Vorbis on ARM9E
https://www.hydrogenaud.io/forums/index.php...st&p=909049 (https://www.hydrogenaud.io/forums/index.php?s=&showtopic=110284&view=findpost&p=909049)
Opus 1.1.1 beta
Clip Zip in rockbox (ARM9E):
opus111b_128k.opus 490.68% realtime Decode time - 35.85s 48.91MHz
vorbis_128k.ogg 475.53% realtime Decode time - 36.99s 50.47MHz
nero_lc_128k.m4a 525.56% realtime Decode time - 33.48s 45.66MHz
In other news, we're currently working on improving low bit-rate quality (< 48 kb/s) for both speech and music. Stay tuned.
Improving quality at <48 kbps makes perfect sense in my opinion as now Opus has highest quality among available formats at 64-96 kbps and higher bitrates.
Let's us know when there will be a test build.
P.S. 1.1.2(AVX optimizations) and 1.2(quality improvements) are planned too. https://wiki.xiph.org/OpusTodo (https://wiki.xiph.org/OpusTodo)
Good job, guys.
it's reported that Opus 1.1.1 decoder is even faster than Vorbis on ARM9E
https://www.hydrogenaud.io/forums/index.php...st&p=909049 (https://www.hydrogenaud.io/forums/index.php?s=&showtopic=110284&view=findpost&p=909049)
Opus 1.1.1 beta
Clip Zip in rockbox (ARM9E):
opus111b_128k.opus 490.68% realtime Decode time - 35.85s 48.91MHz
vorbis_128k.ogg 475.53% realtime Decode time - 36.99s 50.47MHz
nero_lc_128k.m4a 525.56% realtime Decode time - 33.48s 45.66MHz
Interesting. Is there any way I could update the decoder on android (building from source or something?). Currently, opus still seems to be using more processing power than vorbis on my Helio X10, resulting in worse battery life.
Could somebody compile a 32 and 64bit release.
In other news, we're currently working on improving low bit-rate quality (< 48 kb/s) for both speech and music. Stay tuned.
Improving quality at <48 kbps makes perfect sense in my opinion as now Opus has highest quality among available formats at 64-96 kbps and higher bitrates.
Let's us know when there will be a test build.
For those interested in testing, you can follow the exp_lbr_tune branch in the Opus git repository (http://git.xiph.org/?p=opus.git;a=shortlog;h=refs/heads/exp_lbr_tune). There only one change so far (which already makes a difference), but there will be more. Please give this branch a try and report any improvements/regressions compared to master or 1.1.1.
Could somebody compile a 32 and 64bit release.
Opus-1.1.1 for test
http://www70.zippyshare.com/v/OaSumsrn/file.html (http://www70.zippyshare.com/v/OaSumsrn/file.html)
Hi, how good is the integrated opus resampler?
I note everything is resampled to 48kHz so if I preprocess source with external resampler, the resampler of opus is bypassed, right?
Both 86 and 64 isn't starting for me. The RC releases worked fine.
Win 7 64bit fully updated.
Is it really safe to resample 44.1 kHz to 48 kHz? I thought it can lead to some mathematical error?
So what? Opus is not a lossless codec anyway.
Is it really safe to resample 44.1 kHz to 48 kHz? I thought it can lead to some mathematical error?
I don't see anything bad that can happen when resampling from 44.1 to 48 or vice versa.
Both 86 and 64 isn't starting for me. The RC releases worked fine.
Win 7 64bit fully updated.
Works fine here. Windows 10 x64
Is it really safe to resample 44.1 kHz to 48 kHz? I thought it can lead to some mathematical error?
I don't see anything bad that can happen when resampling from 44.1 to 48 or vice versa.
Well I read somewhere it say resampling from 44.1 kHz to 48 kHz cause rounding error
@soundping: Try encoder with dynamic runtime linking
http://www16.zippyshare.com/v/xBbYbOSq/file.html (http://www16.zippyshare.com/v/xBbYbOSq/file.html)
Is it really safe to resample 44.1 kHz to 48 kHz? I thought it can lead to some mathematical error?
I don't see anything bad that can happen when resampling from 44.1 to 48 or vice versa.
Well I read somewhere it say resampling from 44.1 kHz to 48 kHz cause rounding error
I think the point is that such an error in inaudible, particularly relative to other artifacts that could arise when using lossless encoding.
My only concern with the fixed sample rate at 48kHz is that I think the Sansa Fuze plays back 44kHz sources better than 48kHz... but I can't remember where I read that, or if the difference would be audible anyway.
Good job, guys.
it's reported that Opus 1.1.1 decoder is even faster than Vorbis on ARM9E
https://www.hydrogenaud.io/forums/index.php...st&p=909049 (https://www.hydrogenaud.io/forums/index.php?s=&showtopic=110284&view=findpost&p=909049)
Opus 1.1.1 beta
Clip Zip in rockbox (ARM9E):
opus111b_128k.opus 490.68% realtime Decode time - 35.85s 48.91MHz
vorbis_128k.ogg 475.53% realtime Decode time - 36.99s 50.47MHz
nero_lc_128k.m4a 525.56% realtime Decode time - 33.48s 45.66MHz
That is actually synced to a Jan 2014 version of libopus, not 1.1.1.
My only concern with the fixed sample rate at 48kHz is that I think the Sansa Fuze plays back 44kHz sources better than 48kHz... but I can't remember where I read that, or if the difference would be audible anyway.
Wherever you read that, it is not true.
@soundping: Try encoder with dynamic runtime linking
http://www16.zippyshare.com/v/xBbYbOSq/file.html (http://www16.zippyshare.com/v/xBbYbOSq/file.html)
I'm using dBPoweramp.
That upload didn't work as well.. Could not write to the encoder process [clEncoderExternal::EncodeBlock]
That upload didn't work as well..
If I run it in command prompt window it writes:
Please verify that both the operating system and the processor support Intel® SSE4_2, MOVBE, POPCNT, F16C, AVX, FMA, BMI, LZCNT and AVX2 instructions.
I'm running an AMD system. AMD FX-8350 Eight-Core Processor.
Its compiled with /arch:CORE-AVX2, /QxCORE-AVX2, /QxHost or /fast then.
Opus 1.1.1 x64 built with MSVS 2010: https://www.hydrogenaud.io/forums/index.php?showtopic=110691 (https://www.hydrogenaud.io/forums/index.php?showtopic=110691)
Opus-tools win32+win64 binaries
Statically linked against:
* libopus 1.1.1
* libflac 1.3.1
* libogg 1.3.2
Built in a safe GNU/Linux environment with:
mingw-w64 4.0.4 / GCC 5.2.0
https://archive.org/download/Opus-tools_sta...in32+win64).zip (https://archive.org/download/Opus-tools_static_binarieswin32win64/opus-tools_static_binaries(win32+win64).zip)
Opus-tools win32+win64 binaries
Both 32 & 64bit worked great on my system.
Win7 64 / AMD.
For those interested in testing, you can follow the exp_lbr_tune branch in the Opus git repository (http://git.xiph.org/?p=opus.git;a=shortlog;h=refs/heads/exp_lbr_tune). There only one change so far (which already makes a difference), but there will be more. Please give this branch a try and report any improvements/regressions compared to master or 1.1.1.
Tried opusenc from opus-tools v0.1.9-git-aa7e018
Just tested on few clips
At 48kbps , it sounded OK but center imaging sounded mono
At 40kbps, it started to sounded rough
At 32kbps, need a lot of work here.
Ongoing testing
I've tried the snapshot "Quality: removes VBR attenuation at low bitrate (https://git.xiph.org/?p=opus.git;a=commit;h=4806de1c480c9f57a7dc8741968536847a1cb623)" at 48 kbps.
This change produces 2 kbps(4%) extra on average comparing to 1.1.1 48 kbps on my set of albums which are fairly representative like the compilation of different music genres (SoundProLab Absolute Sampler, Chesky Records - The Ultimate Demonstration Disc, etc ).
As this changes removes constrain on VBR so it does go higher on difficult parts, this part is predictable. But it doesn't go low enough. Not sure if it's good thing but monish speech samples still get high enough bitrates. Stereo savings probably could justify a few-several kbps to save there (?) or speech in the other hand requires this bitrate because of its tonal parts (?).
Or this rather can be fixed by bitrate calibration.
Sample The speech sample (https://drive.google.com/folderview?id=0ByvUr-pp6BuUVFhxeU15aUNLSVE&usp=sharing)
I've compared Opus 1.1.1 48 kbps vs 4806de 46 kbps on 7 samples in this moment. Yes, it has wider VBR bitrates but it doesn't necesary translate to higher audible quality. The average scores for both builds were the same.
Interesting. Is there any way I could update the decoder on android (building from source or something?).
I think it's better to ask to developers of particular software player
Currently, opus still seems to be using more processing power than vorbis on my Helio X10, resulting in worse battery life.
Uhm. Opus decoder (1.0-1.1 versions) may use somewhere around ~30-50 MHz on Cortex-A ARM processors (1-2 GHz) so it can't cause worse battery life on a smartphones unless something is really broken. It's not easy to perform apples-to-apples comparison on battery life because real usage of smarthpone varies a lot (background apps, updates, wifi, display etc..). However I've performed battery life test on Moto G (1st gen) which has Cortex-A7 1.2 GHz with Android Rockbox (http://rasher.dk/rockbox/android/). The battery has lasted 35 hours 32 minutes (with headphones turned on realistic volume). It's a lot.
Good job, guys.
it's reported that Opus 1.1.1 decoder is even faster than Vorbis on ARM9E
https://www.hydrogenaud.io/forums/index.php...st&p=909049 (https://www.hydrogenaud.io/forums/index.php?s=&showtopic=110284&view=findpost&p=909049)
Opus 1.1.1 beta
Clip Zip in rockbox (ARM9E):
opus111b_128k.opus 490.68% realtime Decode time - 35.85s 48.91MHz
vorbis_128k.ogg 475.53% realtime Decode time - 36.99s 50.47MHz
nero_lc_128k.m4a 525.56% realtime Decode time - 33.48s 45.66MHz
That is actually synced to a Jan 2014 version of libopus, not 1.1.1.
Oh, then 1.1.1 should be even faster
Thanks, thought you'd given up on Opus for Daala, nice to see some new things happening
Interesting. Is there any way I could update the decoder on android (building from source or something?).
I think it's better to ask to developers of particular software player
I'm talking about the built-in android decoder, android (kind of) supports opus since version 5. Of course, players using a custom decoder can update it, but waiting for an OS update, especially on a non-nexus device is an exercise in futility.
Currently, opus still seems to be using more processing power than vorbis on my Helio X10, resulting in worse battery life.
Uhm. Opus decoder (1.0-1.1 versions) may use somewhere around ~30-50 MHz on Cortex-A ARM processors (1-2 GHz) so it can't cause worse battery life on a smartphones unless something is really broken. It's not easy to perform apples-to-apples comparison on battery life because real usage of smarthpone varies a lot (background apps, updates, wifi, display etc..). However I've performed battery life test on Moto G (1st gen) which has Cortex-A7 1.2 GHz with Android Rockbox (http://rasher.dk/rockbox/android/). The battery has lasted 35 hours 32 minutes (with headphones turned on realistic volume). It's a lot.
It's not a question of being "a lot" or not, but a question of which of them performs better
I haven't done a proper benchmark yet, mostly because I'm constantly using my phone at the moment, but judging by short-term running tests in airplane mode, the CPU spikes to higher states much often with opus than it does with vorbis, and stays in higher CPU usage state overall. (opus: 1.1GHz - 1.4GHz, vorbis: 800MHz - 1.3GHz on a Helio X10 SoC). However, this is using a BT headset, so it probably has some overhead for transcoding opus/ogg to sbc. The question would be, if this overhead is larger than driving regular wired headphones and if it's different between opus and vorbis. I'll probably do a proper benchmark sometime, just to be sure. I can rule out any bias against opus on my part at least, as I find the codec awesome and would like to use it as my lossy codec of choice.
edit: as for android rockbox, it has been and still is a crashfest on several phones I tried it on - maybe it just hates me.
Does Opus still use phase inverted intensity stereo? I ask because I use FM wireless headphones that downmix to mono when I go too far from the reciever and a person here on HA stated to have warbling artifacts caused by phase cancellation https://www.hydrogenaud.io/forums/index.php...st&p=840503 (https://www.hydrogenaud.io/forums/index.php?s=&showtopic=101764&view=findpost&p=840503) . This was confirmed below as a known issue https://www.hydrogenaud.io/forums/index.php...st&p=840586 (https://www.hydrogenaud.io/forums/index.php?s=&showtopic=101764&view=findpost&p=840586) . So was the stereo model improved to not exhibit this artifact or is the stated "hack" of the encoder/decoder to not invert phase by 180 degrees easily available?
Does Opus still use phase inverted intensity stereo? I ask because I use FM wireless headphones that downmix to mono when I go too far from the reciever and a person here on HA stated to have warbling artifacts caused by phase cancellation https://www.hydrogenaud.io/forums/index.php...st&p=840503 (https://www.hydrogenaud.io/forums/index.php?s=&showtopic=101764&view=findpost&p=840503) . This was confirmed below as a known issue https://www.hydrogenaud.io/forums/index.php...st&p=840586 (https://www.hydrogenaud.io/forums/index.php?s=&showtopic=101764&view=findpost&p=840586) . So was the stereo model improved to not exhibit this artifact or is the stated "hack" of the encoder/decoder to not invert phase by 180 degrees easily available?
Opus still uses phase-inverted stereo. However, in an update (not yet available), I'm planning on making it optional, both on the encoder side and on the decoder side for an already encoded stream. Keep in mind that it's a feature that generally improves quality in cases where you're not down-mixing.
I've tried the snapshot "Quality: removes VBR attenuation at low bitrate (https://git.xiph.org/?p=opus.git;a=commit;h=4806de1c480c9f57a7dc8741968536847a1cb623)" at 48 kbps.
This change produces 2 kbps(4%) extra on average comparing to 1.1.1 48 kbps on my set of albums which are fairly representative like the compilation of different music genres (SoundProLab Absolute Sampler, Chesky Records - The Ultimate Demonstration Disc, etc ).
As this changes removes constrain on VBR so it does go higher on difficult parts, this part is predictable. But it doesn't go low enough. Not sure if it's good thing but monish speech samples still get high enough bitrates. Stereo savings probably could justify a few-several kbps to save there (?) or speech in the other hand requires this bitrate because of its tonal parts (?).
Or this rather can be fixed by bitrate calibration.
Sample The speech sample (https://drive.google.com/folderview?id=0ByvUr-pp6BuUVFhxeU15aUNLSVE&usp=sharing)
I've compared Opus 1.1.1 48 kbps vs 4806de 46 kbps on 7 samples in this moment. Yes, it has wider VBR bitrates but it doesn't necesary translate to higher audible quality. The average scores for both builds were the same.
Interesting. On my own calibrating set, the bitrate is the same for 1.1.1 and the new VBR work. What does the quality look like if you compare 48 kbps to 48 kbps? Also, any areas where the new encoder sounds worse than 1.1.1?
When will the update that makes phase inverted intensity stereo optional be available? Also, at what bitrates it is generally used, how does it make sense psychoacoustically (I understand regular intensity stereo destroys phase information, but I fail to see how does inverting one channel by 180 degrees alleviate this to any extend as I don't think any natural signal has 2 channels phase inverted from each other) and can you somehow view how many frames of a file are phase-inverted IS encoded?
Thanks for responding and apart from this issue, your codec astounded me by quality, even at very low bitrates.
When will the update that makes phase inverted intensity stereo optional be available?
When I have time. There's many things that need to be addressed in Opus. This is one of them and it's being addressed in this Opus update draft (https://tools.ietf.org/html/draft-ietf-codec-opus-update-01).
Also, at what bitrates it is generally used, how does it make sense psychoacoustically (I understand regular intensity stereo destroys phase information, but I fail to see how does inverting one channel by 180 degrees alleviate this to any extend as I don't think any natural signal has 2 channels phase inverted from each other) and can you somehow view how many frames of a file are phase-inverted IS encoded?
Essentially, intensity stereo destroys relative phase between the channels. In some cases, the original phase of one channel is more than 90 degrees from the other channel (diffuse noise), so inverted phase is a way to (slightly) help with this kind of signal.
Does it always invert the phase on intensity stereo bands or only when it decides so? How much lower will the quality be without that?
Does it always invert the phase on intensity stereo bands or only when it decides so? How much lower will the quality be without that?
There's a per-band flag to invert the phase, so the encoder chooses whether it sets the flag on each band of each frame. Right now, choosing not to do so is just a one-line hack in the encoder, but I also want to make it an option, and make it an option for the decoder to ignore that flag and never invert phase. In terms of quality, the difference is small, but (when tested several years ago) measurable.
Interesting. On my own calibrating set, the bitrate is the same for 1.1.1 and the new VBR work. What does the quality look like if you compare 48 kbps to 48 kbps? Also, any areas where the new encoder sounds worse than 1.1.1?
Some results. The logs of number of trials weren't recorded because I tested in a training mode. The results (both 1.1.1 and wide VBR at 48 kbps) (https://drive.google.com/file/d/0ByvUr-pp6BuUZzg4aDQ4OER6Q3c/view?usp=sharing)
The bitrate on relatively easy sample of french speech confirms that wider VBR has bitrate bias. Alright, I buy the increase of bitrate on a difficult samples but the bitrate doesn't go lower and in fact a tiny fraction is higher for this easy sample. Conclusion: there is a bitrate bias and no real audible quality improvement as the scores are the same for 1.1.1. 48 kbps vs wider VBR 46 kbps. I really like the idea of very wide VBR and want to hear any kind of improvement. It's just not there yet .
..., in an update (not yet available), I'm planning on making it optional, both on the encoder side and on the decoder side for an already encoded stream.
This statement confuses me. Wouldn't making something optional in the DEcoder move away from full compliance to the IETF specification of Opus? I assume that the band-wise inverted-intensity bit already exists (I.e. has been specified since the first version but might not be set to 1 by current ENcoders)?
Chris
..., in an update (not yet available), I'm planning on making it optional, both on the encoder side and on the decoder side for an already encoded stream.
This statement confuses me. Wouldn't making something optional in the DEcoder move away from full compliance to the IETF specification of Opus? I assume that the band-wise inverted-intensity bit already exists (I.e. has been specified since the first version but might not be set to 1 by current ENcoders)?
The decoder part of the change -- despite nor affecting compatibility in any way -- indeed has implications with respect to the spec. This is why it needs to go through the full IETF process for approval. This is in part to ensure that there is no negative impact of making that (optional) change.
Some results. The logs of number of trials weren't recorded because I tested in a training mode. The results (both 1.1.1 and wide VBR at 48 kbps) (https://drive.google.com/file/d/0ByvUr-pp6BuUZzg4aDQ4OER6Q3c/view?usp=sharing)
I parsed the results and I'd like to share it.
wider normal
3.0 2.8 01.castanets
2.5 2.5 02.fatboy_30sec
3.7 3.4 03.EIG
2.7 2.7 05.Enola
4.0 4.0 11.female_speech
5.0 3.0 05.Linchpin
I parsed the results and I'd like to share it.
wider normal
3.0 2.8 01.castanets
2.5 2.5 02.fatboy_30sec
3.7 3.4 03.EIG
2.7 2.7 05.Enola
4.0 4.0 11.female_speech
5.0 3.0 05.Linchpin
Unless I missed something, the Linchpin score for "wider" was 2.8 and not 5.0.
I assumed it was the ranked reference, because only it had the different filename.
1R = C:\Audio\Samples\Opus wider VBR 48 kbps\Linchpin.wav
2R = C:\Audio\Samples\Opus 1.1.1 VBR 48 kbps\05. Linchpin Opus 1.1.1 48 kbps VBR.wav
---------------------------------------
General Comments:
---------------------------------------
1R File: C:\Audio\Samples\Opus wider VBR 48 kbps\Linchpin.wav
1R Rating: 2.8
1R Comment:
---------------------------------------
2R File: C:\Audio\Samples\Opus 1.1.1 VBR 48 kbps\05. Linchpin Opus 1.1.1 48 kbps VBR.wav
2R Rating: 3.0
2R Comment:
---------------------------------------
Agree, it wasn't clear. Artifacts are easy to spot at 48 kbps. The correct rank for Linchpin encoded by wider VBR is 2.8 (the path is "Opus wider VBR 48 kbps")
I would like to share my opus-tools build too: https://github.com/Chocobo1/opus-tools_win32-build (https://github.com/Chocobo1/opus-tools_win32-build)
Seems a bit faster, probably VS2015 has some better optimizations... not sure.
mine-x64
Encoder stream format: 44100Hz / 2ch / 16bps
Command line: "C:\Audio Encoder\opusenc.exe" --bitrate 128 --vbr --comp 10 --ignorelength --quiet - "mine-x64.opus"
Total encoding time: 0:06.532, 49.42x realtime
2012-x64
Encoder stream format: 44100Hz / 2ch / 16bps
Command line: "C:\Audio Encoder\opusenc.exe" --bitrate 128 --vbr --comp 10 --ignorelength --quiet - "2012-x64.opus"
Total encoding time: 0:07.094, 45.51x realtime
lvqcl-x64
Encoder stream format: 44100Hz / 2ch / 16bps
Command line: "C:\Audio Encoder\opusenc.exe" --bitrate 128 --vbr --comp 10 --ignorelength --quiet - "lvqcl-x64.opus"
Total encoding time: 0:07.140, 45.21x realtime
As of bit-compare, mine is identical with lvqcl build but found difference with 2012 build.
"C:\Users\USMC\Desktop\mine-x64.opus"
"C:\Users\USMC\Desktop\2012-x64.opus"
Compared 15497600 samples.
Differences found: 848271 values, starting at 0:03.792583, peak: 0.0308494 at 0:19.797688, 1ch
Detected offset as 0 samples.
In order to draw some picture of what Opus is capable at 48 kbps I’ve compared it to other codecs to figure out what quality have different formats, weak and strong parts at this bitrate.
Two most obvious and popular formats which bring acceptable quality at 48 kbps: HE-AAC and Vorbis. According to my tests Nero and Fraunhofer HE-AAC encoders has the best quality at 48 kbps. I finally choosed Fraunhofer because despite it has only CBR (AAC’s CBR is actually short window ABR) but quality is still the highest and bitrate is predictable (always 48 kbps).
Opus was better on transient samples, worse on tonal. On speech samples it was HE-AAC>Opus>Vorbis at that bitrate.
There were also two critical samples (“Bachpsichord” and “Spill the Blood”, both are highly tonal) for Opus where it performed even worse than Vorbis. All extra bitrate of a wider VBR helped somewhat but it wasn’t enough to do better than Vorbis on these two samples.
Tests (https://drive.google.com/file/d/0ByvUr-pp6BuUekkwdHpLZTN1cjQ/view?usp=sharing)
original .WAV files (https://drive.google.com/file/d/0ByvUr-pp6BuUODBvT1VQbVpfLWc/view?usp=sharing)
Opus was better on transient samples, worse on tonal. On speech samples it was HE-AAC>Opus>Vorbis at that bitrate.
There were also two critical samples (“Bachpsichord” and “Spill the Blood”, both are highly tonal) for Opus where it performed even worse than Vorbis. All extra bitrate of a wider VBR helped somewhat but it wasn’t enough to do better than Vorbis on these two samples.
Thanks for the feedback Igor. Keep in mind that Opus 1.1.1 is essentially the same as (two year old) Opus 1.1 when it comes to quality. I only just started looking at quality improvements again. I'm not yet sure what will be possible. Extreme tonal samples will likely remain an issue at rates like 48 kb/s simply because Vorbis and HE-AAC use windows of ~80 ms at that rate, whereas Opus is still using 22.5 ms windows.
That being said, here's some samples I just generated at 32 kb/s VBR nominal (actual rate 38 kb/s on this file): http://www.jmvalin.ca/misc_stuff/tune_32kbps1/ (http://www.jmvalin.ca/misc_stuff/tune_32kbps1/)
I'd be interested in comments on which of these sounds best (comp_stereo48.wav is the original). I expect the Dire Straights segment to be the one most affected.
I only just started looking at quality improvements again.
Speaking of quality improvements of Opus, in the 2014 public listening test (http://listening-test.coresv.net/results.htm) (beta (http://listening-test.coresv.net/enhanced/results2.htm)), the rate control of one tonal and silent sample 35_SQAM_glockenspiel_cut.wav (http://listening-test.coresv.net/tracks/35_SQAM_glockenspiel_cut.wav) was significantly different from other encoders.
I know Opus need to boost bitrates on tonal samples, but even after your commit "Makes tonality boost less aggressive" (Thu, 13 Dec 2012) (http://git.xiph.org/?p=opus.git;a=commit;h=b33db8f3182e847bfef28360962625a024875d5f), the tonality boost may have room for some extra improvements.
I'd be interested in comments on which of these sounds best (comp_stereo48.wav is the original). I expect the Dire Straights segment to be the one most affected.
For me comp_orig_t14.wav seems a little bit better than the others, but just a very little. Transients are still annoying with headphones on.
I have some questions on my mind, not completely related to the current improvements:
- Are you planning to resurrect the variable framesize encoding branch in the future or that was completely a dead end?
- How does band folding works in Opus? Can it only fold low frequency bands to higher ones only, or is it possible to encode higher frequency bands and fold them down to lower ones (i don't know if it would result in any gain actually, I'm just curious)?
- I know you don't want to implement anything similar to HE-AACv2's Parametric Stereo for legal reasons, but how different is Intensity Stereo from Parametric Stereo? I think at or below 48kbps it's acceptable to simulate the Stereo image and spend most bits to a single audio channel instead. Can the encoder use IS to emulate Stereo like PS do or it's too dumb for that?
For me comp_orig_t14.wav seems a little bit better than the others, but just a very little. Transients are still annoying with headphones on.
Thanks. So it looks like you like less intensity stereo...
I have some questions on my mind, not completely related to the current improvements:
- Are you planning to resurrect the variable framesize encoding branch in the future or that was completely a dead end?
I'm not ruling it out, but it would probably require a non-trivial amount of work to understand why the previous attempt (i.e. what's in git now) didn't work.
- How does band folding works in Opus? Can it only fold low frequency bands to higher ones only, or is it possible to encode higher frequency bands and fold them down to lower ones (i don't know if it would result in any gain actually, I'm just curious)?
Folding is only from low to high. It's pretty rudimentary, but effective. High to low wouldn't bring anything and add a lot of complexity.
- I know you don't want to implement anything similar to HE-AACv2's Parametric Stereo for legal reasons, but how different is Intensity Stereo from Parametric Stereo?
Intensity stereo is just having the same audio on both channels with different intensity. Combined with the CELT principles, it's a bit more powerful than what MP3 has. Parametric stereo includes intensity stereo, but also controlling inter-channel phase difference (time of arrival), and inter-channel coherence (diffuse vs directional sound). I think the phase difference part is a stupid idea, so the main thing Opus doesn't have is the coherence part. It's not only because of patents, but also because it typically requires an additional filter that adds delay.
I think at or below 48kbps it's acceptable to simulate the Stereo image and spend most bits to a single audio channel instead. Can the encoder use IS to emulate Stereo like PS do or it's too dumb for that?
Well, the t14 file you said you preferred is actually the one with the least amount of intensity stereo and other stereo tricks.
That being said, here's some samples I just generated at 32 kb/s VBR nominal (actual rate 38 kb/s on this file): http://www.jmvalin.ca/misc_stuff/tune_32kbps1/ (http://www.jmvalin.ca/misc_stuff/tune_32kbps1/)
I'd be interested in comments on which of these sounds best (comp_stereo48.wav is the original). I expect the Dire Straights segment to be the one most affected.
I couldn't hear any differences between the 32Kbps encoded files.
After carefully switching between the files at the Dire Straits part, I've noticed slightly less annoying artifacts in comp_is1. The stereo doesn't sound as wide as some of the other files, but I prefer comp_is1.
Hope this helps.
I couldn't spot differences between is1 and is2. Maybe somewhere better somewhere worse though all 6 concatenated samples sound practically the same for me.
Now will try t12 and t14.
I quickly ABXed comp_is1.wav and comp_is2.wav to make sure that I wasn't just imagining differences:
foo_abx 2.0.1 report
foobar2000 v1.3.9
2015-12-31 23:23:12
File A: comp_is1.wav
SHA1: 7309290e4bfb738eaa9c1cc92bc02e0978ad568e
File B: comp_is2.wav
SHA1: c4913af74913d7dacb4a8c719338da92441410ff
Output:
DS : Primary Sound Driver
Crossfading: NO
23:23:12 : Test started.
23:23:58 : 01/01
23:24:38 : 02/02
23:24:55 : 03/03
23:25:17 : 04/04
23:25:45 : 05/05
23:27:05 : 06/06
23:27:21 : 07/07
23:27:40 : 08/08
23:28:08 : 09/09
23:28:52 : 10/10
23:31:05 : 11/11
23:31:24 : 12/12
23:36:34 : 13/13
23:36:54 : 14/14
23:37:30 : 15/15
23:40:14 : 16/16
23:40:14 : Test finished.
----------
Total: 16/16
Probability that you were guessing: 0.0%
-- signature --
f3bbef890ada779ab9231f141e7eff2112517574
Happy New Year everyone! Jean-Marc, I finally got around listening to your 32/38-kbps tuning attempts.
Thanks. So it looks like you like less intensity stereo...
...
Well, the t14 file you said you preferred is actually the one with the least amount of intensity stereo and other stereo tricks.
I think I actually like the t14 version the least. Yes, the stereo image is wider, but I also hear more birdies on some transients (due to more spectral holes or folding, I guess, esp. Dave Matthews Band, woodblocks, a bit also on Dire Straits). No preference on the other versions. Is
comp_orig the Opus 1.1.1 coded one?
Parametric stereo includes intensity stereo, but also controlling inter-channel phase difference (time of arrival), and inter-channel coherence (diffuse vs directional sound). I think the phase difference part is a stupid idea...
What makes you say that? For items like CantWait (https://www.hydrogenaud.io/forums/index.php?s=&showtopic=19882&view=findpost&p=195478) with its near-90-degrees inter-channel phase difference I would guess a respective stereo parameter would be very useful to be able to lower the intensity/parametric stereo start frequency.
And regarding Igor's post here (https://www.hydrogenaud.io/forums/index.php?s=&showtopic=110656&view=findpost&p=913616): by "Fraunhofer HE-AAC" I guess you mean the encoder in Winamp (not fdk), right? (
Edit: note to myself and anyone interested: some news about current status of Winamp (http://forums.winamp.com/showpost.php?p=3045418&postcount=1313))
Chris
And regarding Igor's post here (https://www.hydrogenaud.io/forums/index.php?s=&showtopic=110656&view=findpost&p=913616): by "Fraunhofer HE-AAC" I guess you mean the encoder in Winamp (not fdk), right?
Yes, it was the latest version of FhG encoder from the latest Winamp.
Happy New Year, guys!
Parametric stereo includes intensity stereo, but also controlling inter-channel phase difference (time of arrival), and inter-channel coherence (diffuse vs directional sound). I think the phase difference part is a stupid idea...
What makes you say that? For items like CantWait (https://www.hydrogenaud.io/forums/index.php?s=&showtopic=19882&view=findpost&p=195478) with its near-90-degrees inter-channel phase difference I would guess a respective stereo parameter would be very useful to be able to lower the intensity/parametric stereo start frequency.
90-degree out of phase generally means an uncorrelated, diffuse field, which AFAIK is handled through inter-channel coherence (IC), rather than with inter-channel phase difference (IPD). IC is indeed useful. OTOH, IPD is related to time delay of arrival, which is a cue that we only perceive below about 1-2 kHz. The problem is that in that range the ear is very sensitive to phase, and messing it up causes really bad artefacts. I believe it's the reason why HE-AACv2 makes me motion sick when I listen to it with headphones.
90-degree out of phase generally means an uncorrelated, diffuse field, which AFAIK is handled through inter-channel coherence (IC), rather than with inter-channel phase difference (IPD).
I have to disagree with the first part of your sentence. Attached are three WAV files I created with the Octave/Matlab script below:
- [attachment=8480:noise90.wav]fully correlated (i.e. identical) noise sources in both channels, left channel created using forward MDCT + inverse MDCT, right channel created using forward MDCT + inverse MDST to achieve a 90-degree phase shift,
- [attachment=8481:noiseUC.wav]fully uncorrelated (i.e. independent) noise sources for the two channels, both left and right channel created using forward MDCT + inverse MDCT,
- [attachment=8482:noiseUC90.wav]same as noiseUC, but right channel created using forward MDCT + inverse MDST (which doesn't matter since the noise sources are uncorrelated).
I find the noise90 file to sound much more like a (somewhat distorted) point source than the (truly diffuse sounding) noiseUC* files. By the way, I could have used a FFT instead of the MDCT/MDST here as well, the results sound the same.
I haven't checked, but a parametric stereo codec without IPD support would probably turn noise90 either into true mono or into something which sounds like the noiseUC* versions, by handling the IPD by way of the IC parameter, as you say.
Of course, this is an extreme demonstration. I have only observed such stable long-term IPDs in some very few Dolby Surround encoded tracks. And the CantWait sample.
OTOH, IPD is related to time delay of arrival, which is a cue that we only perceive below about 1-2 kHz. The problem is that in that range the ear is very sensitive to phase, and messing it up causes really bad artefacts. I believe it's the reason why HE-AACv2 makes me motion sick when I listen to it with headphones.
Indeed. I don't like the sound of HE-AAC's Parametric Stereo either. In fact, its phase coding is so expensive and unintuitive that I'm not even sure it's actually used. Which might be the reason why HE-AAC v2 sounds quite bad on "phasy" items like the abovementioned CantWait. Extended HE-AAC (USAC) sounds much better in such cases.
N = 1024; % frame length
F = 94; % number of frames
% mdct4() and imdct4() are from www.ee.columbia.edu/~marios/mdct/mdct_giraffe.html
w_sin = sin(pi*(0.5:2*N)'/(2*N));
outUC = zeros(F*N, 2);
out90 = zeros(F*N, 2);
outUC90 = zeros(F*N, 2);
rand1 = rand(F*N, 1) - rand(F*N, 1) + rand(F*N, 1) - rand(F*N, 1);
rand2 = rand(F*N, 1) - rand(F*N, 1) + rand(F*N, 1) - rand(F*N, 1);
for i = 0 : F-2
spec = mdct4(w_sin .* rand1(i*N+1 : i*N+2*N));
out90(i*N+1 : i*N+2*N, 1) = out90(i*N+1 : i*N+2*N, 1) + w_sin .* imdct4(spec);
outUC(i*N+1 : i*N+2*N, 1) = outUC(i*N+1 : i*N+2*N, 1) + w_sin .* imdct4(spec);
outUC90(i*N+1 : i*N+2*N, 1) = outUC90(i*N+1 : i*N+2*N, 1) + w_sin .* imdct4(spec);
spec(1:2:end) = -spec(1:2:end);
temp = w_sin .* imdct4(spec); % IMDST via IMDCT
out90(i*N+1 : i*N+2*N, 2) = out90(i*N+1 : i*N+2*N, 2) + temp(end:-1:1);
spec = mdct4(w_sin .* rand2(i*N+1 : i*N+2*N)); % uncorrelated second channel
outUC(i*N+1 : i*N+2*N, 2) = outUC(i*N+1 : i*N+2*N, 2) + w_sin .* imdct4(spec);
spec(1:2:end) = -spec(1:2:end);
temp = w_sin .* imdct4(spec); % IMDST via IMDCT
outUC90(i*N+1 : i*N+2*N, 2) = outUC90(i*N+1 : i*N+2*N, 2) + temp(end:-1:1);
end
wavwrite(out90*0.25, 48000, 16, 'noise90.wav');
wavwrite(outUC*0.25, 48000, 16, 'noiseUC.wav');
wavwrite(outUC90*0.25, 48000, 16, 'noiseUC90.wav');
Chris
I find the noise90 file to sound much more like a (somewhat distorted) point source than the (truly diffuse sounding) noiseUC* files. By the way, I could have used a FFT instead of the MDCT/MDST here as well, the results sound the same.
I haven't checked, but a parametric stereo codec without IPD support would probably turn noise90 either into true mono or into something which sounds like the noiseUC* versions, by handling the IPD by way of the IC parameter, as you say.
Of course, this is an extreme demonstration. I have only observed such stable long-term IPDs in some very few Dolby Surround encoded tracks. And the CantWait sample.
My point is that actual recordings are highly unlikely to contain a constant 90-degree inter-channel difference. Either the phase is random (averages to 90, but not constant) as is the case in a diffuse noise field, or else it's a linear phase caused by a different delay of arrival between the channels. And as I stated earlier, the ear is only sensitive to such delay of arrival below 1-2 kHz, so it's useless to model it at high frequency. And for low frequencies, the ear is just *too* sensitive to phase, that trying parametric tricks is bound to cause motion sickness. That's why I say it's pointless to use parametric phase. For the record, here's some previous experimentation (http://jmvalin.ca/papers/valin_hscma2008.pdf) I did with phase.
And as I stated earlier, the ear is only sensitive to such delay of arrival below 1-2 kHz, so it's useless to model it at high frequency.
Yes, of course, I'm not questioning that. Or rather, above ~2 kHz delay of arrival should be modeled using inter-channel intensity differences with (if necessary) high temporal resolution.
And for low frequencies, the ear is just *too* sensitive to phase, that trying parametric tricks is bound to cause motion sickness. That's why I say it's pointless to use parametric phase.
Fair enough. But if the bit-rate is so low that you can't even afford coding a band-limited second (residual) channel, what would you do? Surely, using an intensity-stereo approach below 2 kHz would not be a good idea... regardless of whether or not you (can) model the IC.
Chris
And as I stated earlier, the ear is only sensitive to such delay of arrival below 1-2 kHz, so it's useless to model it at high frequency.
Yes, of course, I'm not questioning that. Or rather, above ~2 kHz delay of arrival should be modeled using inter-channel intensity differences with (if necessary) high temporal resolution.
No need for high temporal resolution. We're deaf to time delay of arrival above 2 kHz. It's only the intensity that matters.
And for low frequencies, the ear is just *too* sensitive to phase, that trying parametric tricks is bound to cause motion sickness. That's why I say it's pointless to use parametric phase.
Fair enough. But if the bit-rate is so low that you can't even afford coding a band-limited second (residual) channel, what would you do? Surely, using an intensity-stereo approach below 2 kHz would not be a good idea... regardless of whether or not you (can) model the IC.
I'm not sure what I would do, but I know what I *wouldn't* do... mess around with the phase (and that includes IC below 1 kHz). At least intensity stereo doesn't make you motion sick :-)
Does any one know if Opus has been selected for VoLTE yet? Or Will that be EVS?
How does EVS compared to Opus in VoLTE use case?
1.1.2 is released:
https://git.xiph.org/?p=opus.git
1.1.2 is released:
https://git.xiph.org/?p=opus.git
Binaries?
1.1.2 is released:
https://git.xiph.org/?p=opus.git
Binaries?
For Windows I found these:
https://github.com/Chocobo1/opus-tools_win32-build
1.1.2 is released:
https://git.xiph.org/?p=opus.git
Binaries?
For Windows I found these:
https://github.com/Chocobo1/opus-tools_win32-build
Thank You
Does any one know if Opus has been selected for VoLTE yet? Or Will that be EVS?
How does EVS compared to Opus in VoLTE use case?
It seems they have chosen EVS instead, anyone know why?
It seems they have chosen EVS instead, anyone know why?
Seems like its superior to Opus at the bitrates VoLTE is operating at + better at noice cancelling. And probably other reasons too.
(source: http://www.iwaenc2014.org/files/2014_IWAENC_EVS_Varga.pdf)
Looking at the EVS DMOS chart, at 16 and 24 kbps Opus is rated as being equivalent to whichever EVS codec is giving the same bandwidth, and I wonder to what extent the ratings it gets at lower rates are due to it going to mediumband and narrowband. Where would e.g. LP3.5, LP7 fit on this chart? And many of the recent Opus changes have been focused on increasing bandwidth at low bit rates.
Honestly, I find it odd how much emphasis increasing the audio bandwidth gets. Especially for speech. I wonder whether test conditions in most listening tests exaggerate the importance of high frequencies, especially for speech. Silent listening environment, and crystal-clear test samples usually recorded in studio conditions and given some processing. Rating via comparison to original - even with a hidden reference people are going to try to focus on figuring out which is the original and compare to that - rather than assessing intelligibility or pleasantness by other means.
I mean, the difference between narrowband and mediumband is huge- narrowband misses critical information that we always use to tell different consonants apart and it's painful to listen to. But I would think that the returns diminish steeply from there.
For speech samples I worked with (academic conference recordings done with TASCAM DR-05 built in mics rather than controlled environments and high-end equipment) I had people tell me in blind testing that they preferred wideband-lowpassed versions to fullband. (They found it more intelligible and less distracting without the high frequencies which even after intelligent postprocessing were still mostly noise.) And SWB was not readily ABXable from fullband.
Why no one is talking about 1.1.2 release?
I wanted to notify Peter as well for the next foobar2000 beta but he probably knows by now and I don't want to start a new thread just for this.
Just saw someone posted the release sorry guys I missed for few months and I'm slow to see things with the new forum as well.