HydrogenAudio

Lossy Audio Compression => Opus => Topic started by: jmvalin on 2018-06-01 21:15:57

Title: Opus 1.3-rc
Post by: jmvalin on 2018-06-01 21:15:57
I just released Opus 1.3-rc. This is a release candidate for the upcoming Opus 1.3. Changes include:
Again, we’re providing experimental Windows binaries built with 1.3-rc and the upcoming opus-tools and libopusenc.

Source code: opus-1.3-rc.tar.gz (https://archive.mozilla.org/pub/opus/opus-1.3-rc.tar.gz)
Win32 binaries: opus-tools-test-1.3-rc.zip (https://archive.mozilla.org/pub/opus/win32/opus-tools-test-1.3-rc.zip)
Title: Re: Opus 1.3-rc
Post by: soundping on 2018-06-02 15:07:16
Header gain +5.00 dB?
Title: Re: Opus 1.3-rc
Post by: fabiorug on 2018-06-02 15:15:10
Good.
Anyway I don't recommend using less than 64 kbps VBR I for encoding music even if the tonality analysis has improved. I prefer 64 kbps bitrate (Stereo).
Title: Re: Opus 1.3-rc
Post by: Kamedo2 on 2018-06-03 08:42:20
I tested it from windows and there were no apparent bugs.

Encoding on 9kbps-13kbps range was a bit slower than the other rates.
I don't believe this is a serious issue, but anyway.
(https://listening-test.coresv.net/img2/opus1.3rc-encoding-speed.png)
Other than the bitrate, the default settings were used.
Code: [Select]
opus-tools-test-1.3-rc\opusenc --bitrate %v %i %o
Title: Re: Opus 1.3-rc
Post by: Klimis on 2018-06-03 11:45:49
It might not be the right place to report this bug but creating files with the parameter --framesize 60, creates files that are not playable in Android 6.0+ where there is native Opus support. It simply outputs silence. The same files work on everything else I tried so it's only on Android. Google claims that their encoder is based on libopus 1.2.1 so whatever is going on it may have to do with that.

Thread with further discussion on the issue: https://hydrogenaud.io/index.php/topic,116065.msg957834/topicseen.html#new
Title: Re: Opus 1.3-rc
Post by: iwod on 2018-06-03 12:14:32
I just released Opus 1.3-rc. This is a release candidate for the upcoming Opus 1.3. Changes include:
  • Making it possible to use SILK down to bitrates around 5 kb/s
  • Using wideband encoding down to 9 kb/s
  • Improving security (including a new --enable-hardening option)
  • Minor quality improvement on tones
  • Improving Ambisonics support (still experimental)
  • Minor bug fixes
Again, we’re providing experimental Windows binaries built with 1.3-rc and the upcoming opus-tools and libopusenc.

Source code: opus-1.3-rc.tar.gz (https://archive.mozilla.org/pub/opus/opus-1.3-rc.tar.gz)
Win32 binaries: opus-tools-test-1.3-rc.zip (https://archive.mozilla.org/pub/opus/win32/opus-tools-test-1.3-rc.zip)

I wonder how 1.3 compare now against EVS at low bitrate.
Title: Re: Opus 1.3-rc
Post by: IgorC on 2018-06-04 04:14:33
1.3 is an important update.  I've no time to post all results but here is a preview  ( Korean speech sample). General findings are in line with this sample.
https://listening-test.coresv.net/tracks/24-Greensleeves-Korean-male-speech.441.wav

1.3RC1 is pretty in line  with 1.3 post-beta 1 (opus-tools-9cfdcba), if not even better!
(http://i63.tinypic.com/2nqcg42.jpg)

To Opus developers, great work and thank you for 1.3.
Title: Re: Opus 1.3-rc
Post by: magicgoose on 2018-06-04 07:12:09
Would it still hold true that setting --framesize to anything bigger than 20 is either pointless or harmful? In case the delay doesn't matter (it's for offline playback from some kind of disk), and if small differences in decoder CPU or memory usage also do not matter.
Title: Re: Opus 1.3-rc
Post by: jmvalin on 2018-06-04 17:03:02
Encoding on 9kbps-13kbps range was a bit slower than the other rates.
I don't believe this is a serious issue, but anyway.

As far as I can tell, this is due to three different modes being used: SILK narrowband up to 9 kb/s, SILK wideband (the slowest) between 9 and 13 kb/s, then CELT from there on. SILK typically decodes faster than CELT, but it's slower to encode, especially if you want to do a good job (i.e. high complexity setting).
Title: Re: Opus 1.3-rc
Post by: Nikaki on 2018-06-06 10:36:59
(Somewhat off-topic.)

Is the opus-tools GitHub repo being looked at? None of the 1.3 stuff seems to be there. Also, I submitted a (trivial) patch to make the opusdec resampler quality configurable, but the place seems very inactive.
Title: Re: Opus 1.3-rc
Post by: soundping on 2018-06-06 15:16:22
Foobar 1.4 beta 16 is now showing Header gain 0.00 dB.
Title: Re: Opus 1.3-rc
Post by: Case on 2018-06-06 15:59:24
Header gain +5.00 dB?
Foobar 1.4 beta 16 is now showing Header gain 0.00 dB.
foobar2000 prior to 1.4 showed the gain after it was internally adjusted for ReplayGain reference levels. New version shows what's in the files and does the reference level adjustment behind the scenes.
Title: Re: Opus 1.3-rc
Post by: domegeme on 2018-06-06 17:55:47
what do new parameter do? --no-phase-inv
Title: Re: Opus 1.3-rc
Post by: maikmerten on 2018-06-06 18:52:54
what do new parameter do? --no-phase-inv

I'm pretty sure this enables a feature that avoids problems when downmixing stereo streams to mono: https://tools.ietf.org/html/rfc8251#section-10

Title: Re: Opus 1.3-rc
Post by: OrthographicCube on 2018-06-07 07:15:34
This is phenomenal! You guys are really challenging the limits of audio codec efficiency! I mean, I'd listen to a 9kbps Opus audio without complaining, this is so exciting!

Really, really thankful for this. Not just from me, but from everyone who uses lossy audio encoding technology. This is history. So happy to be living in this generation!
Title: Re: Opus 1.3-rc
Post by: fabiorug on 2018-06-07 11:36:33
I hope there'll be improvements at 32 kbps and less artifacts at low bitrates.
Title: Re: Opus 1.3-rc
Post by: soundping on 2018-06-07 12:22:51
Opus is the future.  ;D
Title: Re: Opus 1.3-rc
Post by: domegeme on 2018-06-07 13:02:51
Opus is the future.  ;D


it is possible for him and the future but not now, this is clearly audible on the samples this https://drive.google.com/file/d/1qsRU3LhzKXZzngVWXaOW7yEKfATTOnVg/view?usp=sharing
Title: Re: Opus 1.3-rc
Post by: magicgoose on 2018-06-07 17:04:40
Opus is the future.  ;D
For those who aren't locked to some software/hardware which doesn't support Opus, it also could very well be the present.
(and also for a lot of present VoIP implementations and whatnot.)
it is possible for him and the future but not now, this is clearly audible on the samples this https://drive.google.com/file/d/1qsRU3LhzKXZzngVWXaOW7yEKfATTOnVg/view?usp=sharing
Hmm so an other currently available encoder works better than Opus on this sample? Or what do you mean by this?
Title: Re: Opus 1.3-rc
Post by: domegeme on 2018-06-07 17:41:01
what do you mean by this?
I am not a professional in these matters, but this sample displays contemporary art, and since the opus has become a global standard, it must be transparent not only in classical music
Title: Re: Opus 1.3-rc
Post by: Nikaki on 2018-06-07 21:08:09
it is possible for him and the future but not now, this is clearly audible on the samples this https://drive.google.com/file/d/1qsRU3LhzKXZzngVWXaOW7yEKfATTOnVg/view?usp=sharing
What's that from?
Title: Re: Opus 1.3-rc
Post by: domegeme on 2018-06-07 21:23:11
What's that from?
I hope I don't break rules of this forum =) but in the tag is the answer
Title: Re: Opus 1.3-rc
Post by: ThaCrip on 2018-06-07 22:39:48
I'd listen to a 9kbps Opus audio without complaining

as far as speech goes... 14kbps is about the lowest I would suggest as while you can go lower and have it still passable (i.e. still understand what's said etc) I feel sound quality starts to really drop off going below the 14kbps setting, at least based on my Klipsch Pro-Media speakers for the PC. because while I can notice the 14kbps being a hit to the overall sound compared to the 128kbps original MP3 speech file I got, it's not that much worse for a tiny fraction the original files bit rate.

basically I sort of feel 14kbps, for speech, is that sweet spot where one wants smallest possible file size but without sacrificing sound quality too much. I know the 'sweet spot' might vary from person-to-person though as some might favor sound quality over bit rate a bit and some might be more of the other end where they favor super small file size at the expense of sound quality but I suspect many would find my suggested 14kbps as solid enough as while you can definitely notice the difference in sound drop off, it's not that much considering the really low bit rate.

NOTE: I have not messed with Opus v1.3RC much yet but I suspect things will remain the same on what I said above.

I hope there'll be improvements at 32 kbps and less artifacts at low bitrates.

If I recall correctly, from what I have read around here not long ago, it seems like there will be mainly adjustments in the 48kbps and lower ranges as I would not expect much, if anything, on about 64kbps and probably next to nothing, if not nothing, in the 96kbps+ ranges since 96kbps is already pretty darn good given the listening tests around here.

but even assuming what I said above is correct... I would imagine we are talking very small differences in sound quality to where when casually listening I would not expect to hear any obvious differences between v1.2.1 and v1.3RC at bit rates of 32-48kbps (give or take). so basically what I am saying is, don't expect much as I doubt there will be any obvious differences from v1.2.1 to v1.3 as we are probably talking faint differences I would imagine for the most part.

while adjustments at the really low bit rates are nice, personally, I would like to see how far they can lower the bit rate while still 'approaching transparency' (or close enough to that standard) when it comes to music.  so in this regard, while 96kbps is pretty much that 'approaching transparency' level already with Opus v1.2.1 it would be nice if that could be lowered a bit to say improve 64kbps (and the like) as I imagine much under 64kbps is just going to be difficult to get near that standard and even 64kbps is probably asking a lot already given it's a 1/3rd less bit rate than the already strong 96kbps, which is already a pretty low bit rate.

but with that said... it seems Opus is already a pretty strong performer at those low bit rates (say under 96kbps) as say something like 10-15 years ago the sound quality Opus has at 64kbps was overall better than bit rates quite a bit higher than that. so it's obvious they (general audio encoders) made fairly major progress since then. but it's nice in that, at least with AAC/MP3, any files encoded in this decade (assuming the person used the newest encoders at the time) you don't have to worry about sound quality since it's pretty much the same. but in the previous decade as the years passed they made solid progress as the years passed. but this might not entirely apply to Opus given that seems to have made decent progress in this current decade where as AAC/MP3 peaked something like 8-ish years ago(?).
Title: Re: Opus 1.3-rc
Post by: magicgoose on 2018-06-08 06:27:22
what do you mean by this?
I am not a professional in these matters, but this sample displays contemporary art, and since the opus has become a global standard, it must be transparent not only in classical music
I tried to find any art in that file and did not succeed.
The sample is also longer than 30 seconds which are allowed here for copyrighted samples.
Anyway Opus seems to do fine with this (with --bitrate 140, at least), do you have different test results? If you claim to be able to hear the difference, you need to prove it, that's in the rules of HA.
Title: Re: Opus 1.3-rc
Post by: domegeme on 2018-06-08 11:59:09
I tried to find any art in that file and did not succeed.
Probably you have a musical education?
The sample is also longer than 30 seconds which are allowed here for copyrighted samples.
I reduced to 10 seconds in accordance with the requirements and copyright
Anyway Opus seems to do fine with this (with --bitrate 140, at least), do you have different test results?
--vbr --bitrate 180

foo_abx 2.0.4 report
foobar2000 v1.4 beta 17
2018-06-08 13:41:39

File A: precision010.flac
SHA1: a1b28d8473317a6ee814598e9542d3aa63e0472f
File B: precision010.opus
SHA1: 8ae8807b027516fb9748b710f7451c4cce005535

Output:
DS : Первичный звуковой драйвер
Crossfading: NO

13:41:39 : Test started.
13:42:49 : 01/01
13:43:30 : 02/02
13:43:50 : 03/03
13:44:24 : 04/04
13:45:05 : 05/05
13:45:21 : 06/06
13:45:39 : 07/07
13:45:57 : 08/08
13:46:22 : 09/09
13:46:32 : 10/10
13:46:55 : 11/11
13:47:15 : 12/12
13:47:34 : 13/13
13:47:59 : 14/14
13:48:18 : 15/15
13:48:53 : 16/16
13:48:53 : Test finished.

 ----------
Total: 16/16
Probability that you were guessing: 0.0%

 -- signature --
bdb235586eed63116588b7b4dd615c7ddfb6a855


my audio hardware: DAC ES9018K2M + TPA6133A2
Title: Re: Opus 1.3-rc
Post by: magicgoose on 2018-06-08 13:38:16
Now this is interesting. Could you describe the kind of distortion which is happening here? Maybe it's an encoder bug that can be fixed.
And did you use ReplayGain to avoid clipping while testing? The Opus file has peak level ≈1.166; even though clipping is less likely to be noticeable behind this wall of noise, there's a chance someone can notice it.
Title: Re: Opus 1.3-rc
Post by: IgorC on 2018-06-08 13:43:05
I would imagine we are talking very small differences in sound quality to where when casually listening I would not expect to hear any obvious differences between v1.2.1 and v1.3RC at bit rates of 32-48kbps (give or take).
Here we don't imagine things but actually  test it.

1.3RC is significantly better than 1.2.1 at least for speech  at low bitrates. Not only 1.3RC is much better than 1.2.1 but also bitrates are less bloated on speech samples.

P.S. 1.3RC has new advanced speech detector based on algorithms of artificial intelligence, RNN.
Title: Re: Opus 1.3-rc
Post by: kolt54321 on 2018-06-08 17:53:05
--vbr --bitrate 180

foo_abx 2.0.4 report
foobar2000 v1.4 beta 17
2018-06-08 13:41:39

File A: precision010.flac
SHA1: a1b28d8473317a6ee814598e9542d3aa63e0472f
File B: precision010.opus
SHA1: 8ae8807b027516fb9748b710f7451c4cce005535

Output:
DS : Первичный звуковой драйвер
Crossfading: NO

13:41:39 : Test started.
13:42:49 : 01/01
13:43:30 : 02/02
13:43:50 : 03/03
13:44:24 : 04/04
13:45:05 : 05/05
13:45:21 : 06/06
13:45:39 : 07/07
13:45:57 : 08/08
13:46:22 : 09/09
13:46:32 : 10/10
13:46:55 : 11/11
13:47:15 : 12/12
13:47:34 : 13/13
13:47:59 : 14/14
13:48:18 : 15/15
13:48:53 : 16/16
13:48:53 : Test finished.

 ----------
Total: 16/16
Probability that you were guessing: 0.0%

 -- signature --
bdb235586eed63116588b7b4dd615c7ddfb6a855


my audio hardware: DAC ES9018K2M + TPA6133A2

Interesting. What headphone do you have for the test?

Most of my library is converted using Opus 1.2.1 at 176kbps, I should hope that 1.3 didn't improve too much on the higher birates :)
Title: Re: Opus 1.3-rc
Post by: ThaCrip on 2018-06-08 23:03:11
I would imagine we are talking very small differences in sound quality to where when casually listening I would not expect to hear any obvious differences between v1.2.1 and v1.3RC at bit rates of 32-48kbps (give or take).
Here we don't imagine things but actually  test it.

1.3RC is significantly better than 1.2.1 at least for speech  at low bitrates. Not only 1.3RC is much better than 1.2.1 but also bitrates are less bloated on speech samples.

P.S. 1.3RC has new advanced speech detector based on algorithms of artificial intelligence, RNN.

I did notice a tiny difference in file size between v1.3RC and v1.2.1 on the sample (i.e. 24-Greensleeves-Korean-male-speech.441) you linked to...

v1.2.1 (@ 16kbps) =19.5 KB (19,974 bytes)
v1.3RC (@ 16kbps) = 19.2 KB (19,682 bytes)

but other than that, I can't say I notice any obvious difference between the two when listening to those two Opus speech files, at least based on my Klipsch Pro-Media speakers for the PC. if there is a difference it's got to be minimal especially given that low of a bit rate as I set it to 16kbps and v1.3RC shows 17kbps and v1.2.1 shows 18kbps in Foobar2000.

so your saying Opus v1.3's greatest advantage over v1.2.1 is definitely speech? ; if that's true, I would not expect to hear any obvious difference between v1.3 and v1.2.1 if that speech file you linked to is a good test for the encoders. but who knows, maybe there could be differences in other random speech files(?).

but I just noticed that there is some volume change between the WAV file and the Opus files and I know what the WAV sounds like so it's easy for me to detect the WAV vs Opus files on that alone when ABXing. like in the WAV file, the left speaker is louder where as with the Opus v1.2.1 and v1.3RC those sound the same in that regard in that the left speaker has less volume and is quieter. like I can adjust volume (on the speaker itself) so it's nice and even on both speakers with the Opus files but when I play back the WAV file the left speaker is noticeably louder. but just strictly playing the v1.2.1 and v1.3RC and listening, back and fourth, I can't say I feel confident enough to say one sounds noticeably better than the other as they seem pretty much the same to me. but trying to overlook the volume change, I am pretty sure I could ABX those 16kbps Opus speech files from the WAV. but in terms of just doing a straight compare of v1.2.1 and v1.3RC, I don't feel confident enough to say I hear any clear difference between the two files.
Title: Re: Opus 1.3-rc
Post by: IgorC on 2018-06-08 23:46:52
but other than that, I can't say I notice any obvious difference between the two when listening to those two Opus speech files, at least based on my Klipsch Pro-Media speakers for the PC.
ah, You listen through speakers which are less sensitive to artifacts. That explains the most part of your results.

Headphones are much more revealing when it comes to ABX&ABCHR tests

For example,
http://listening-tests.hydrogenaud.io/sebastian/mp3-128-1/index.htm
Quote
... Headphones are a must-have
Title: Re: Opus 1.3-rc
Post by: ThaCrip on 2018-06-09 09:04:01
ah, You listen through speakers which are less sensitive to artifacts. That explains the most part of your results.

Headphones are much more revealing when it comes to ABX&ABCHR tests

I see. but I think I can safely say my speakers are above average computer speakers, if that matters at all. because I could easily see how if I had lower quality speakers (say pretty basic/average range) it would be more difficult to spot artifacts etc. basically all comments I have made around here are generally based around those Klipsch Pro-Media speakers which I have had since about the early 2000's. I got a couple of old ABX logs from the year 2013 testing MP3 @ v5(130kbps) and v6(115kbps) on a random song and I pretty much successfully ABX'ed em on my speakers, if that matters at all. basically I got... 11/12 (0.3%) for the v5 (130kbps) and 10/10 (0.1%) for the v6 (115kbps) if that helps give you any rough indication of their ability for artifact spotting etc.

but with that said... when it comes to headphones, do I need anything fancy? ; because all I have is Sony MDR-NC7 headphones which are probably not crap(as I would assume it could be worse), but definitely nothing special.

either way, with speakers or headphones... that would not explain the left and right speaker volume issue I had when testing that sample you linked to in here, correct? ; that's the only thing I noticed that issue on as with other random speech files I got and general music it does not have that volume issue from what I noticed.

but would it be possible for me to detect artifacts on those speakers but not be able to on the headphones? ; although I realize as a general guideline, based on what your saying, headphones are preferred in general.

just some thoughts ; but I guess in the meantime we will just have to assume your tests are good with v1.2.1 vs 1.3RC ;)
Title: Re: Opus 1.3-rc
Post by: domegeme on 2018-06-09 15:16:13
Interesting. What headphone do you have for the test?
Uiisii hm7 + rubber ear Pads
Could you describe the kind of distortion which is happening here?
Good to hear the hiss in intense fields, (if apply by sinc interpolation (foo_dsp_multiresampler) resampling of 44.1k - 48k hiss becomes audible). Heard aggressive removal of side (L-R / 2). At the moment I am very pleased with the work of only FAAC 1.28 (-q160) it is great.
And did you use ReplayGain to avoid clipping while testing?
Nothing was used
Title: Re: Opus 1.3-rc
Post by: magicgoose on 2018-06-09 16:13:08
Could you describe the kind of distortion which is happening here?
Good to hear the hiss in intense fields, (if apply by sinc interpolation (foo_dsp_multiresampler) resampling of 44.1k - 48k hiss becomes audible). Heard aggressive removal of side (L-R / 2). At the moment I am very pleased with the work of only FAAC 1.28 (-q160) it is great.
And did you use ReplayGain to avoid clipping while testing?
Nothing was used
If you add some effects (a resampler which audibly changes sound?!) then the ABX test is not correct.
re. Aggressive removal of side (L-R / 2): if you listen to the channel difference in isolation (by shorting 2 of 3 wires in  headphones, or otherwise) this is also not a fair test. (Or can you isolate (L-R) by ear so much better than other people?)
Lossy encoders are normally optimized for listening without any drastic effects like these.

ReplayGain, OTOH, should be used for comparison to prevent clipping and/or loudness difference. (Unless you're testing a codec which has an additional goal of not increasing peak values; Opus has no such design goal, neither does AAC or other typical lossy codecs)
Title: Re: Opus 1.3-rc
Post by: domegeme on 2018-06-09 17:19:14
magicgoose, This ABX test was done by ear, and I already wrote that I'm not a professional and can be wrong. The reasons that I described are subjective but indicate a problem at high bitrates.
Title: Re: Opus 1.3-rc
Post by: magicgoose on 2018-06-09 17:28:34
If it was done by ear entirely, then why do you mention some postprocessing which, allegedly, alters sound in interesting ways?
I don't really understand why it's relevant in this case.
Quote
if apply by sinc interpolation (foo_dsp_multiresampler) resampling of 44.1k - 48k hiss becomes audible
Was this resampler used during the test?
Title: Re: Opus 1.3-rc
Post by: IgorC on 2018-06-09 18:04:56
but with that said... when it comes to headphones, do I need anything fancy?
If you're comfortable with your hardware and sound then  there is no need to bother.

I see. but I think I can safely say my speakers are above average computer speakers...
It's not about speaker's price (well, at least it's not only about it) but a general trend that  good pair of headphone reveals artifacts of lossy compression better.
Title: Re: Opus 1.3-rc
Post by: bennetng on 2018-06-09 18:07:05
Resampling is unavoidable due to the fact that opus is fixed at 48kHz and the original file is 44.1kHz. I looked into the log and it was done by using DS. Skipping the resampler plugin and Windows built-in resampler will still resample.

kode54 mentioned that foo_dsp_multiresampler's quality is not state of the art, but with the sinc option it is still transparent to me.
https://hydrogenaud.io/index.php/topic,112883.msg929567.html#msg929567

The potential clipping/DS limiting issue on the other hand should be addressed.
Title: Re: Opus 1.3-rc
Post by: domegeme on 2018-06-09 18:31:00
If it was done by ear entirely, then why do you mention some postprocessing which, allegedly, alters sound in interesting ways?
I don't really understand why it's relevant in this case.

I didn't use anything to prove inside the encoder tags the original sample rate was listed. no interpolation was used in the test and replaygain was also not used. you're using my words against me...

Was this resampler used during the test?
I didn't use anything!
you can encode the attached flac file in opus and make a bitwise comparison with what I provided.

Quote
if apply by sinc interpolation (foo_dsp_multiresampler) resampling of 44.1k - 48k hiss becomes audible

(if apply) does not mean applied.
I wrote it thinking it could theoretically help.

The potential clipping/DS limiting issue on the other hand should be addressed.
I agree with you
Title: Re: Opus 1.3-rc
Post by: bennetng on 2018-06-09 18:50:33
https://hydrogenaud.io/index.php/topic,114871.msg946989.html#msg946989

According to Arnold's comment ES9018K2M is potentially problematic with filtering, sadly he didn't provide the recorded files. The aliasing of HF content could potentially affect ABX results as well.
Title: Re: Opus 1.3-rc
Post by: domegeme on 2018-06-09 19:00:18
https://hydrogenaud.io/index.php/topic,114871.msg946989.html#msg946989

According to Arnold's comment ES9018K2M is potentially problematic with filtering, sadly he didn't provide the recorded files. The aliasing of HF content could potentially affect ABX results as well.
You not have evidence to support the presence of distortion in ES9018K2M, you can ask a question in the support service: http://www.esstech.com/index.php/en/support/support-contact/
Title: Re: Opus 1.3-rc
Post by: bennetng on 2018-06-09 19:04:53
You not have evidence to support the presence of distortion in ES9018K2M
Yeah, and while you are reading the post, be careful with the attached test signals. When used improperly they can harm your equipment and hearing.
Quote
you can ask a question in the support service
In case you don't know, those ESS chips have configurable digital filters, a DAC chip is different from the whole product with all other circuitry and the manufacturer can also reprogram the chip to change its behavior. Without the actual audio file to examine with asking ESS themselves is useless. ESS even don't allow everyone to download their datasheet publicly, you can definitely find some with the help of Google and the pdf files are watermarked with "confidential" on every page. They will not disclose everything to the public openly.
Title: Re: Opus 1.3-rc
Post by: MetaPixel on 2018-06-10 08:50:28
I tested it from windows and there were no apparent bugs.

Encoding on 9kbps-13kbps range was a bit slower than the other rates.
I don't believe this is a serious issue, but anyway.
(https://listening-test.coresv.net/img2/opus1.3rc-encoding-speed.png)
Other than the bitrate, the default settings were used.
Code: [Select]
opus-tools-test-1.3-rc\opusenc --bitrate %v %i %o
What does %v %i %o mean/do? I'm really curious about that.
Title: Re: Opus 1.3-rc
Post by: Makaki on 2018-06-10 12:16:05
...What does %v %i %o mean/do? I'm really curious about that.

Those are variables to his program or batch file. In this case meaning BitrateValue InFile OutFile respectively.
Title: Re: Opus 1.3-rc
Post by: IgorC on 2018-06-13 02:08:52
Here are few outdated results from 1.3 post-beta testing.

https://drive.google.com/file/d/1eusrdEWxtg8ya8RkMl8v_17FbHMfkWBv/view
50% of samples speech, 50% music

MOS (32 kbps VBR, stereo):
version 1.2.1 - 3.35
version 1.3 post-beta1  B (2c0d9ee) - 3.98

The most important part of improvements of 1.3 goes for speech and mixed material.


Korean speech 16-40 kbps
https://drive.google.com/file/d/0ByvUr-pp6BuUOHBIU2dXaVNZU0tMblRyU3hnU3llSHRaVDMw/view?usp=sharing

A opus-tools-cdcb2f7
B opus-tools-2c0d9ee
C opus-tools-b44f56e
D opus-tools-9cfdcba

These A, B, C, D are builds  in-between 1.3b1 and 1.3RC1

German speech sample https://drive.google.com/file/d/1SnAd_vEpfT_ndF0cmqlQ2LpwchNMNTbS/view?usp=sharing
1.2.1 - 3.0
1.3RC1 - 3.5

P.S. I would love to test something more complete and solid but it's not right time for me. Hopefully later.
Title: Re: Opus 1.3-rc
Post by: eahm on 2018-06-14 18:41:53
Nice improvements!
Title: Re: Opus 1.3-rc
Post by: Trace on 2018-06-14 21:24:17
Sorry if this is a noob question, but would this update be worth replacing my current library of opus 1.3 beta encoded at 160kbps? Thanks in advance.
Title: Re: Opus 1.3-rc
Post by: Deathcrow on 2018-06-15 00:28:50
Sorry if this is a noob question, but would this update be worth replacing my current library of opus 1.3 beta encoded at 160kbps? Thanks in advance.

I'm sure someone will correct me if i'm totally wrong here, but, to answer your question: Almost certainly not. I'd just start using 1.3 when it is released for your new encodes from that point onward... at those bitrates the improvements (if any) will be very hard to notice.
Title: Re: Opus 1.3-rc
Post by: Deathcrow on 2018-06-15 00:43:22
if apply by sinc interpolation (foo_dsp_multiresampler) resampling of 44.1k - 48k hiss becomes audible

I do not understand this part. The opus file is already 48khz. Resampling to 48khz shouldn't do anything.

Are you sure you are not artificially introducing artifacts in your listening setup somehow? I love Perturbator and tried to ABX your files but couldn't spot a difference (it's quite difficult anyway because it's already so heavily distorted).
Title: Re: Opus 1.3-rc
Post by: Trace on 2018-06-15 00:56:26
Sorry if this is a noob question, but would this update be worth replacing my current library of opus 1.3 beta encoded at 160kbps? Thanks in advance.

I'm sure someone will correct me if i'm totally wrong here, but, to answer your question: Almost certainly not. I'd just start using 1.3 when it is released for your new encodes from that point onward... at those bitrates the improvements (if any) will be very hard to notice.
Much appreciated, thank you.
Title: Re: Opus 1.3-rc
Post by: ThaCrip on 2018-06-15 08:12:51
Sorry if this is a noob question, but would this update be worth replacing my current library of opus 1.3 beta encoded at 160kbps? Thanks in advance.

Like Deathcrow already said, it would be almost certainly a waste of time simply because @ 160kbps the wiki page says, 160-192kbps = "Transparent with very low chance of artifacts (a few killer samples still detectable)." ; so when your already borderline perfection, it's not really possible for v1.3 to improve on that to any real degree even though I guess technically if it fixed those rare killer samples, that would be a improvement but at this point you would be nitpicking for sure.

basically with v1.3 it seems the sound quality improvements are mainly at bit rates of around 48kbps and lower from what I have read around here. but on the higher bit rates (say about 96kbps+) I would expect to see very little if anything since they are already high quality on the current release of v1.2.1 as 96kbps shows 'approaching transparency' on the wiki page for Opus which means even that bit rate already offers quality sound. you can't really go wrong with 96kbps/128kbps/160kbps.

or let me bottom line Opus... I think I can say that the vast majority of people who have a concern for sound quality will use a bit rate of between 96-160kbps (maybe 192kbps for the somewhat paranoid types) as while you can go lower than 96kbps you start to gamble a bit on sound quality even though at the lower rates the sound quality is quite respectable given the bit rates, like... 32kbps/48kbps/64kbps etc. but any higher than 160-192kbps is pretty much a waste of storage space given the info in the Opus wiki page.
Title: Re: Opus 1.3-rc
Post by: OrthographicCube on 2018-06-16 11:33:01
as far as speech goes... 14kbps is about the lowest I would suggest as while you can go lower and have it still passable (i.e. still understand what's said etc) I feel sound quality starts to really drop off going below the 14kbps setting, at least based on my Klipsch Pro-Media speakers for the PC. because while I can notice the 14kbps being a hit to the overall sound compared to the 128kbps original MP3 speech file I got, it's not that much worse for a tiny fraction the original files bit rate.
Well, it is possible that I may be exaggerating things, but I was in no way saying that I'd listen to a 9kbps Opus song for daily purposes--I just meant that for 9kbps, the result is (at least for me) exceptional compared to what other codecs can offer at the same bitrate. But no, I'd never listen to a 9kbps Opus song for daily listening stuff--for that, I'd happily use (at least) 48kbps (but I'd rather use 64kbps) (I'm not that picky with quality, and a bit of artifact adds a nice touch to the audio, I dunno why I think that way) But 9kbps... never XD
Title: Re: Opus 1.3-rc
Post by: ThaCrip on 2018-06-16 12:09:32
Well, it is possible that I may be exaggerating things, but I was in no way saying that I'd listen to a 9kbps Opus song for daily purposes--I just meant that for 9kbps, the result is (at least for me) exceptional compared to what other codecs can offer at the same bitrate. But no, I'd never listen to a 9kbps Opus song for daily listening stuff--for that, I'd happily use (at least) 48kbps (but I'd rather use 64kbps) (I'm not that picky with quality, and a bit of artifact adds a nice touch to the audio, I dunno why I think that way) But 9kbps... never XD

I was just strictly saying 14kbps is THE minimum I would suggest for 'speech' (not music) as if you got lengthy speech files it's a nice way to keep the storage space very minimal for hours and hours of speech while maintaining a decent level of speech quality. I suspect that minimum suggested kbps setting will vary a bit from person-to-person but just testing on my Klipsch Pro-Media speakers that's the conclusion I came to as the sound clarity starts to take a solid hit below 14kbps which is why I drew the line at 14kbps as my minimum suggested setting for speech.

but yeah, considering speech quality of Opus at 9kbps etc, while there is clearly a hit to the sound quality, it's respectable given the VERY low/next to nothing bit rate. but as you said, I am more concerned with sound quality at that point to where I would rather lose a bit of disk space to clean up the sound a bit. hence, my 14kbps+ suggestion.

but for music it's a whole different ball game to where I am pretty much inline with you with the 48-64kbps thing being about the minimum I would possibly use. like for bit rates lower than 96kbps (I use 96kbps as the minimum for someone who's concerned with quality), 64kbps is a solid choice. for those who prefer to use minimal storage space for music, 48kbps is a possible option. hell, even 32kbps is solid considering the very low bit rate but unless someone is trying to cram a bunch of music into the least amount of storage space possible I would generally stick to at least 48kbps+ minimum. but for the most part I stick with 96kbps on more important music for on-the-go listening and for less important music I use 64kbps (using this combo I managed to fit pretty much my entire music collection onto a 8GB MicroSD card). it's possible I would consider 48kbps but it would have to more-or-less be one of those situations where your really hard up for space and I don't want to cut out songs. but come to think of it... I really need to do a little testing to see how music with Opus @ 32kbps/48kbps sounds in comparison to 64kbps on my headphones to see if I can detect any more obvious differences or not as if not, then 48kbps could be a realistic choice for me for further efficiency if I need to squeeze more songs on that 8GB MicroSD card in the future.
Title: Re: Opus 1.3-rc
Post by: IgorC on 2018-06-18 06:41:29
I was just strictly saying 14kbps is THE minimum I would suggest for 'speech' (not music) ...
Now You can go even lower with 1.3 on speech. As low as 13.2 kbps with even better quality (see below).



  • Using wideband encoding down to 9 kb/s

As far as I can tell, this is due to three different modes being used: SILK narrowband up to 9 kb/s, SILK wideband (the slowest) between 9 and 13 kb/s, then CELT from there on. ...
Now 1.3RC1 encodes to SWB/FB at 13.2 kbps as well ( while 1.2.1 codes to WB at this bitrate).
I've noticed it uses SWB or FB on a different samples. I guess it's expected and desired behavior (?)

Overal quality is better actually for 1.3RC.  Though German speech sample was hard to encode. I wonder if it's matter of training and/or tuning.

Samples: https://drive.google.com/file/d/1BMrQlEz01gJVP43PAtYBYiLQUMHlhsLq/view?usp=sharing

(http://i63.tinypic.com/idennq.png)

Conclusion:
1.3RC1@13.2kbps is on par with 1.2.1@16kbps on speech.
That's 20% of bitrate reduction.  Similar bitrate reduction is observed on higher bitrates (16-40+ kbps)


Title: Re: Opus 1.3-rc
Post by: jensend on 2018-06-20 03:16:58
I find the aggressive push for higher bandwidths at lower bitrates slightly surprising, especially for speech.

I mean, obviously one wants to quit doing narrowband as soon as possible; it misses almost all the energy in many consonants, harming intelligibility, and everything including vowels sounds flat. Mediumband is much better but still an obvious degradation. But wideband is quite good and I'm happier with an 8KHz lowpass than I am with most kinds of distortions. SWB speech is frequently non-ABXable from fullband, since above 12K there's so often little other than noise of dubious audibility.

So it's surprising to find that the encoder will now be spending bits at rather low bitrates on coding 12-20KHz rather than spending more bits on accuracy in the frequency range where the formants and most of the consonant energy are. I wonder what kind of listening tests etc suggested making such a move.

Down the road I wonder whether something like the WaveNet codec2 decoding demo (http://www.rowetel.com/?p=5966) will end up making SBR, hybrid mode, etc mostly obsolete for speech.
Title: Re: Opus 1.3-rc
Post by: IgorC on 2018-06-20 21:26:25
12-20 kHz frequency range is important for noisy speech and music (stereo material, etc..) http://oh3tr.fi/~oh3gdd/Publications/%5B12%5D_Dallas_ICASSP2010_Ramo_Voice%20Quality%20Evaluation%20of%20Various%20Codecs.pdf

Also Opus codes 12-20 kHz range  in just 2 freq. bands of total 20  (10% of total bands). Add to that band folding and 12-20 kHz range is coded just at few-to-several hundreds of  bits ( less than 1 kbps). 

So it's very cheap for Opus to code this range starting from somewhere ~13.2 -14 kbps.

P.S. Also I suspect that SWB can be pushed down to ~11-12 kbps (at least for speech) because 1.3RC SWB@13.2kbps is on par with an older 1.2.1 FB@16kbps   :o
Title: Re: Opus 1.3-rc
Post by: soundping on 2018-06-21 00:51:42
480K  18-Jun-2018 20:20
https://archive.mozilla.org/pub/opus/win32/opus-tools-test-1.3-rc-fix.zip

 :D
Title: Re: Opus 1.3-rc
Post by: fabiorug on 2018-06-21 13:19:42
I tried this - opus-tools-test-1.3-rc-fix.zip -
It's almost twice as efficient as aac Itunes . Obviously it has different types of artifacts compared to aac Itunes.
It's not bad I think. When the full 1.3 Opus will come out? Probably in July this year?
Title: Re: Opus 1.3-rc
Post by: NetRanger on 2018-06-21 19:12:31
Opus-tools v0.1.10-71-g32d4b47 (using libopus 1.3-rc-2-gc1c247d7)
Built on June 21, 2018, GCC 7.3.0

https://git.xiph.org/?p=opus.git;a=summary
https://git.xiph.org/?p=opus-tools.git;a=summary
https://git.xiph.org/?p=libopusenc.git;a=summary
Title: Re: Opus 1.3-rc
Post by: Wally Walters on 2018-06-22 23:10:07
How does the audio quality of Opus 1.3 at 32 kbps stereo compare to 48 kbps FDK these days?  Testers of earlier versions claimed they were equivalent, but I found that not yet to be the case,
Title: Re: Opus 1.3-rc
Post by: ThaCrip on 2018-06-25 08:48:36
Conclusion:
1.3RC1@13.2kbps is on par with 1.2.1@16kbps on speech.
That's 20% of bitrate reduction.  Similar bitrate reduction is observed on higher bitrates (16-40+ kbps)

I was briefly playing around with a speech file I got online (my original copy is a 87kbps VBR MP3(tool in Foobar2000 says 'Lavc56.28')) with v1.3RC vs v1.2.1 I noticed I could lower from 14kbps to 13kbps with v1.3RC and things seemed pretty much the same but going to 12kbps and there was a noticeable hit. although bit rates did not exactly scale down the same from 14kbps to 13kbps to 12kbps...

selected bit rate = actual bit rate...
12kbps = 12kbps (noticeable hit to sound quality vs the two below)
13kbps = 14kbps (seemed to be similar to the setting below)
14kbps = 15kbps (seemed to be similar to the setting above)

basically v1.2.1 @ 14kbps (15kbps real bit rate) is better than v1.3RC @ 12kbps (12kbps real bit rate) on the speech file I tested as the main thing is the v1.3RC @ 12kbps is more muffled where as the v1.2.1 @ 14kbps is not (like the v1.2.1 file @ 14kbps sounds closer to the 87kbps MP3 source file than the v1.3RC @ 12kbps does). is this to be expected?

p.s. this was all done on my Klipsch Pro-Media speakers on the PC with Foobar2000 v.1.3.19.
Title: Re: Opus 1.3-rc
Post by: IgorC on 2018-06-25 14:03:23
It's expected. Everything lower than 13 kbps is coded to WB(8kHz). Higher than 13 kbps is coded to SWB/FB (12 kHz/20kHz).

That's why earlier I've posted
P.S. Also I suspect that SWB can be pushed down to ~11-12 kbps (at least for speech) because 1.3RC SWB@13.2kbps is on par with an older 1.2.1 FB@16kbps   :o
Title: Re: Opus 1.3-rc
Post by: Hanseat on 2018-06-26 12:10:07
OPUS files encoded by the precompiled windows-binaries from this forum/thread, version 1.3 (Beta and Release Candidate) seem to be incompatible with Foobar2000 1.3 und 1.4 Beta. I always get the message "Unable to open item for playback (Unsupported format or corrupted file)". Chrome and Android can playback the same files withot errors.

Foobar2000 can playback OPUS-files from YouTube and created by the binaries of OPUS 1.2, downloaded from the OPUS homepage.

Now I wonder if it is a Foobar-, binaries- or OPUS 1.3 problem.
Title: Re: Opus 1.3-rc
Post by: Deathcrow on 2018-06-26 19:09:15
OPUS files encoded by the precompiled windows-binaries from this forum/thread, version 1.3 (Beta and Release Candidate) seem to be incompatible with Foobar2000 1.3 und 1.4 Beta. I always get the message "Unable to open item for playback (Unsupported format or corrupted file)". Chrome and Android can playback the same files withot errors.

I don't see this problem. How are you encoding the files? Maybe you can upload a short sample that supposedly doesn't play in fb2k?

Have you tried a clean install of foobar2000 (for example portable mode in a new folder)?
Title: Re: Opus 1.3-rc
Post by: NetRanger on 2018-06-26 20:39:56
@Hanseat - No issues here either with playing tracks encoded with the latest RC of Opus in foobar. As Deathcrow said, try with a clean install of foobar2000 and take it from there.
Title: Re: Opus 1.3-rc
Post by: Deathcrow on 2018-06-26 22:04:14
I've been playing around with the --music and --speech switches for music encoding at 24 kbit/s. I have to say, --music (which seems to result in the same file as not specifying anything at that bitrate) sounds terrible. The stereo imaging and spectrum may be better than in SILK mode, but the artifacts are incredibly annoying and totally not worth it (snare drum hits are nothing but artifacts). Encoding with --speech sounds loads better to my tin ears, almost (but not quite) better in every way. Certainly so much better that I'd want it to be the default at that bitrate.

Am I wrong? Maybe my hearing is completely broken/abnormal?

I've attached two short samples for demonstration purposes.
Title: Re: Opus 1.3-rc
Post by: punkrockdude on 2018-06-27 00:05:22
Maybe --speech sounds better because the stereo image is narrower and more bits can be used on the stuff in the middle?
Title: Re: Opus 1.3-rc
Post by: 2012 on 2018-06-27 00:32:06
Am I wrong? Maybe my hearing is completely broken/abnormal?

Maybe  ;)

Try --set-ctl-int 4004=1104. Do you like the output?
Title: Re: Opus 1.3-rc
Post by: Deathcrow on 2018-06-27 00:53:11
Maybe --speech sounds better because the stereo image is narrower and more bits can be used on the stuff in the middle?

That may well be true. I realize that we are losing some fidelity, but the clashing and clanging artifacts with the --music setting make it borderline unbearable to listen to (for me). The sample with the --speech setting doesn't make me want to rip off my headphones in agony.

Maybe  ;)

Try --set-ctl-int 4004=1104. Do you like the output?

What is that supposed to do? Sounds just as bad as the --music setting at 24 kbps and I can't honestly tell the difference... but I'm not sure what I'm listening for. If it has to do with the frequency range / bandwidth: My hearing tops out around 15-16khz.
Title: Re: Opus 1.3-rc
Post by: 2012 on 2018-06-27 03:19:20
I can't honestly tell the difference...

Then something is really wrong at your end.
Title: Re: Opus 1.3-rc
Post by: jensend on 2018-06-27 06:34:58
12-20 kHz frequency range is important for noisy speech and music (stereo material, etc..) http://oh3tr.fi/~oh3gdd/Publications/%5B12%5D_Dallas_ICASSP2010_Ramo_Voice%20Quality%20Evaluation%20of%20Various%20Codecs.pdf
The study you cited doesn't provide support for your claim, it contradicts it. For mono speech, even though half their samples were noisy, their graph says that the difference between 10kHz bandwidth and fullband failed in their tests to be statistically significant, as did the difference between 12kHz and fullband for stereo speech. They state the same conclusion in their text: "Widening the audio bandwidth further from superwideband to fullband has less impact and the perceived quality does not improve significantly." Note also that the paper's "wideband" means 7kHz cutoff, so the difference between Opus WB and SWB/FB is less than what they indicate.

Even if FB costs less than 1kbps more than SWB, one might imagine that for speech at low bit rates the lower frequencies can use every single bit they can get while the >12kHz frequencies are essentially inaudible.

I was under the impression that the 1.0.x mode change thresholds etc had been based on plenty of listening data e.g. the 2011 nokia test. I can appreciate that those tests are out of date given the bugfixes and improvements since then, and I don't claim to be the superior expert here. But to an outsider glancing at commit logs and patches it seems like the relentless dropping of the bandwidth and stereo threshholds with each release doesn't entirely correlate to "hey we made the encoder so much better that we need dramatically fewer bits for the lower frequencies and now have bits to spare for more bandwidth." It seems to reflect shifting priorities, and it's natural to wonder why the priorities have shifted. Most charitably one could figure "they must have lots and lots of secret double blind listening test data." Least charitably one could figure "they saw that video that compared opus and xhe-aac via spectrographs (https://www.youtube.com/watch?v=sEUwScTX-R4) and wanted to cater to the 'I want my prettier spectrographs' crowd." I'm fairly certain neither is correct.
Title: Re: Opus 1.3-rc
Post by: Deathcrow on 2018-06-27 11:32:32

Then something is really wrong at your end.

Okay since you're not elaborating I'm just going to assume it's a lowpass: Not sure why you'd expect me to immediately pick up on that considering all the loud and annoying noises/distortions going on.

Could you be a little less cryptic and a little more helpful? Did you listen to the two samples I provided? Do you think the "--music" sample sounds better than the "--speech" sample, even though the former is laden with loud artifacts and distortions? I'd probably prefer a narrowband transmission of that track over the reproduction offered by the music setting. I'm totally going to shut up if someone told me they'd want to listen to the --music sample over the --speech one
Title: Re: Opus 1.3-rc
Post by: j7n on 2018-06-27 12:54:40
The Music sample at 24 kbit/s unsurprisingly sounds bad for a spacious, dynamic sound. The Speech sample is essentially slightly panned mono, and sounds very similar to a mono downmix encode (avg 26 kbit), without any special switches, except for few notes that are panned left at the beginning. The decay of the snare is slightly better, fuzzier with Speech, but not by much. My simple conclusion would be that the bitrate is not high enough for stereo sound, and I would prefer and use mono. Stereo becomes passable at 40 kbit/s or greater, and I'd only choose it at 48.

FhG AAC SBR/PS at 24 kbit sounds better on this sample, and maintains believable, smooth stereo. I'd choose it over 40 kbit Opus.
Title: Re: Opus 1.3-rc
Post by: 2012 on 2018-06-27 13:51:12
Okay since you're not elaborating I'm just going to assume it's a lowpass: Not sure why you'd expect me to immediately pick up on that considering all the loud and annoying noises/distortions going on.

It limits max bandwidth to SWB (12KHz). The lack of high frequencies alone should have made it easy for you to spot the difference.

Did you listen to the two samples I provided? Do you think the "--music" sample sounds better than the "--speech" sample, even though the former is laden with loud artifacts and distortions?

Defining better is hard with such low bitrates. Both are not good by any measure. But to my ears, music sounds better than speech, yes.

I'd probably prefer a narrowband transmission of that track over the reproduction offered by the music setting.

NB is excessive. But try with 1103 instead for 1104 for WB. It sounds terrible here. But maybe for you it sounds better!
Title: Re: Opus 1.3-rc
Post by: Hanseat on 2018-06-27 14:22:50
Foobar2000 works fine. I just messed up the extensions.
Now I see that YouTube creates webm-files and opusenc does not.
FB2K does not like it when I call the files created by opusenc *.webm.
Chrome and Android do not seem to care.
Title: Re: Opus 1.3-rc
Post by: j7n on 2018-06-27 14:30:24
Change the file name extension to out.opus and it plays. If you need webm, mux the opus file with MkvToolNix.
Title: Re: Opus 1.3-rc
Post by: IgorC on 2018-06-29 03:07:43
The study you cited doesn't provide support for your claim, it contradicts it.
Just to be sure we're talking about Figure 1, right?  MOS clearly increases from 12kHz to 16 kHz for stereo.

They state the same conclusion in their text: "Widening the audio bandwidth further from superwideband to fullband has less impact and the perceived quality does not improve significantly."
It's different.
SWB is 16kHz in the paper. While Opus'es SWB is 12 kHz.

Even if FB costs less than 1kbps more than SWB, one might imagine that for speech at low bit rates the lower frequencies can use every single bit they can get while the >12kHz frequencies are essentially inaudible.
I won't argue. It would be logically correct.
But lossy codecs are complex sets of compromises. Highest quality encoders HE-AAC and Opus code all audible frequency range at 64 kbps. Wouldn't be more logical to use lowpass  at 16 kHz at such low bitrate? Yes, it would. But Opus uses as small as 0.1-0.2 kbps for the range 15.6kHz-20kHz (the last and highest freq. band) . Will this lowpass result in better audible quality? Definitely it won't. 

[Speculation]
So,yes, we're talking about barely audible range but also barely noticeably bitrate waste.  ::)  Young people (20-24 y.o.) are actually pretty sensible to HF range (would it be 12 kHz or even 15-16 kHz). And I don't speak without actually making some tests on them :)
Or maybe it's something to do with perception of  HF range as an energy. Yes, it possible to change gain lately but it won't be the same I guess. Not sure.

Also though speech/music was improved significantly  I guess there is no perfect speech/music separation as there are mixed content and noisy speech. It would be good to code HF range as well in case of speech/music "misdetection".
[Speculation mode off]

After reading your first post I've done some tests (not actually apples to apples) and 1.3RC@16kbps-FB was on par with 1.1@~22-SWB kbps (speech,1.1@24kbps-SWB >1.3RC16kbps-FB > 1.1@20kbps-SWB).  Duh, while there is no direct correlation between BW and audible quality but I will prefer 13.2 kbps [at least->] SWB over lossless WB all the time on speech samples.

P.S. All in all, only devs know all peculiarities of their codecs. I don't discard a possibility of marketing of fullband voice at very low bitrate.
Title: Re: Opus 1.3-rc
Post by: alter4 on 2018-06-30 14:58:59
The Music sample at 24 kbit/s unsurprisingly sounds bad for a spacious, dynamic sound.

Where I can download this sample?
Title: Re: Opus 1.3-rc
Post by: quadH on 2018-07-01 15:56:39
Highest quality encoders HE-AAC and Opus code all audible frequency range at 64 kbps. Wouldn't be more logical to use lowpass  at 16 kHz at such low bitrate? Yes, it would. But Opus uses as small as 0.1-0.2 kbps for the range 15.6kHz-20kHz (the last and highest freq. band) . Will this lowpass result in better audible quality? Definitely it won't.

Not 64kbps but: I encoded a few albums at 48kbps with Opus 1.2.1, and there was a song that hurt to listen to because the high frequencies were too loud. In that (rare) case, discarding the highest frequency band would improve the sound quality. I don't remember which one it was, so I can't provide a sample.
Title: Re: Opus 1.3-rc
Post by: ThaCrip on 2018-07-02 07:10:18
What's the difference between the "opus-tools-test-1.3-rc-fix.zip" and the one NetRanger posted?

because I was using the one the OP posted (which is older than those two listed above) until the last day or so. I gave the NetRanger one a shot as you can see the 64bit opusenc.exe improves encoding speed as Opus @ 13kbps for a speech file I got (converting from AAC to Opus) the Opus 32bit does about 30-31x and the Opus 64bit does about 42x. the 64bit encoded file is a sliver larger than the 32bit one although the 64bit opusenc is clearly superior because the file sizes of the encoded files are nearly identical but the 64bit one is clearly faster to encode which makes it superior.

is there any reason why they don't give people a option to use the 64bit encoder on the official releases? ; because I don't see any real downsides given the clear encoding speed improvement and just about everyone has a 64bit CPU if their computer is from around 2007 to date.
Title: Re: Opus 1.3-rc
Post by: jensend on 2018-07-02 07:14:25
Just to be sure we're talking about Figure 1, right?  MOS clearly increases from 12kHz to 16 kHz for stereo.
The figure also shows dotted/dashed lines for their confidence intervals. Their confidence interval for fullband mono contains the center of their confidence interval for 10kHz bandwidth mono, so the difference between the two is not statistically significant, and so forth.

(The lines themselves are just a misleading spline interpolation between their actual estimates and intervals at each data point; it's reasonable to assume the real MOS varies smoothly with bandwidth between those 6 points, but one shouldn't pay close attention to the plotted shapes between the points. For instance, the appearance on the graph that mono quality is higher at 15kHz than at fullband is just an artifact of their misleading spline.)
Quote
SWB is 16kHz in the paper.
14kHz, actually, which is closer to the Opus SWB.
Quote
So,yes, we're talking about barely audible range but also barely noticeably bitrate waste.
Ofc the cost for Opus of coding fullband is relatively tiny when you're encoding at 64kbps. But as you reduce bitrates, at some point ofc there's a crossover below which any benefits of coding those frequencies are outweighed by the missed improvements to more audible frequencies. Where is that cutoff in normal conditions? 1.0.x said 29kbps for mono speech and 1.1 said 21. Now it's 14kbps. Similar stories are told of the other bandwidth thresholds and the stereo thresholds. Is the point of diminishing returns really under half what it was for 1.0.x? Doubtful. The improvements in the last couple versions to SILK and very low bitrate CELT don't seem *that* dramatic. Were the initial thresholds overly conservative? Probably. But I still wonder about this sharp a decrease.
Re your tests -perhaps you might be more sensitive to / preferential towards HF than the average listener? Ideally one would get a diverse group of listeners who aren't told the samples they are listening to have different bandwidths, and a diversity of noisy and clean speech.
Quote
It would be good to code HF range as well in case of speech/music "misdetection".
Well, that'll depend on the amount of HF energy and how much it's masked.
Title: Re: Opus 1.3-rc
Post by: IgorC on 2018-07-02 14:50:15
The figure also shows dotted/dashed lines for their confidence intervals...
Those intervals are way beyond of all limits of sane conservatism.

If You follow these lines then even 7kHz  is on par with 12 kHz "statistically". 

Title: Re: Opus 1.3-rc
Post by: jmvalin on 2018-07-03 13:57:28
Ofc the cost for Opus of coding fullband is relatively tiny when you're encoding at 64kbps. But as you reduce bitrates, at some point ofc there's a crossover below which any benefits of coding those frequencies are outweighed by the missed improvements to more audible frequencies. Where is that cutoff in normal conditions? 1.0.x said 29kbps for mono speech and 1.1 said 21. Now it's 14kbps. Similar stories are told of the other bandwidth thresholds and the stereo thresholds. Is the point of diminishing returns really under half what it was for 1.0.x? Doubtful. The improvements in the last couple versions to SILK and very low bitrate CELT don't seem *that* dramatic. Were the initial thresholds overly conservative? Probably. But I still wonder about this sharp a decrease.
Re your tests -perhaps you might be more sensitive to / preferential towards HF than the average listener? Ideally one would get a diverse group of listeners who aren't told the samples they are listening to have different bandwidths, and a diversity of noisy and clean speech.
There's a bunch of reasons the thresholds went down dramatically compared to 1.0. First, the original thresholds were overly conservative. They were based on my preference (and it appears I tend to like the thresholds higher than most people), plus a "conservative margin". On top of that, some were set based on code that had a few bugs that got fixed later. On top of all that, there's actually been significant improvements to the hybrid code compared to 1.0. Back in 1.0, the two core codecs were well optimized by themselves, but hybrid mode was relatively new. It was already amazing what it could do at 32 kb/s. Since then, it's been tuned a lot more and scales to much lower bitrates than we originally even tested. One bug difference is that the minimum overhead of coding FB compared to WB has gone down by more than half (CELT was initially given too many bits and didn't use them well).

In terms of actual testing, we've recently shown that people seem to prefer WB over NB at 9 kb/s, so that threshold it going to be used in 1.3. As for WB to FB, we don't have test data for that and it's a bit tricky because it's going to depend a lot on the exact listening device and the content.
Title: Re: Opus 1.3-rc
Post by: dwalkerdon on 2018-07-14 17:08:05
Sorry if this is a noob question, but would this update be worth replacing my current library of opus 1.3 beta encoded at 160kbps? Thanks in advance.

Like Deathcrow already said, it would be almost certainly a waste of time simply because @ 160kbps the wiki page says, 160-192kbps = "Transparent with very low chance of artifacts (a few killer samples still detectable)." ; so when your already borderline perfection, it's not really possible for v1.3 to improve on that to any real degree even though I guess technically if it fixed those rare killer samples, that would be a improvement but at this point you would be nitpicking for sure.

basically with v1.3 it seems the sound quality improvements are mainly at bit rates of around 48kbps and lower from what I have read around here. but on the higher bit rates (say about 96kbps+) I would expect to see very little if anything since they are already high quality on the current release of v1.2.1 as 96kbps shows 'approaching transparency' on the wiki page for Opus which means even that bit rate already offers quality sound. you can't really go wrong with 96kbps/128kbps/160kbps.

or let me bottom line Opus... I think I can say that the vast majority of people who have a concern for sound quality will use a bit rate of between 96-160kbps (maybe 192kbps for the somewhat paranoid types) as while you can go lower than 96kbps you start to gamble a bit on sound quality even though at the lower rates the sound quality is quite respectable given the bit rates, like... 32kbps/48kbps/64kbps etc. but any higher than 160-192kbps is pretty much a waste of storage space given the info in the Opus wiki page.

I find that Opus 1.2.1  at 128 kbps for 5.1 audio tracks, and 64 kbps for stereo tracks sound pretty transparent to the source. The main problem with 48 kbps is that it suffers from artifacts in violins and string based music.
Title: Re: Opus 1.3-rc
Post by: IgorC on 2018-07-15 20:56:23
Yes, there is an important difference on music material between 48 and 64 kbps.

Main goal of 1.3 is speech and mixed material.
If 1.1/1.2.1 would need 48-64 kbps for an excelent quality (score area of 4.5+) of  stereo speech samples now 1.3RC does it just at 40 kbps.
Title: Re: Opus 1.3-rc
Post by: ThaCrip on 2018-07-16 02:22:32
@dwalkerdon

Quote
64 kbps for stereo tracks sound pretty transparent to the source. The main problem with 48 kbps is that it suffers from artifacts in violins and string based music.

Yeah, I just mentioned the whole 96kbps/128kbps/160kbps thing as that's a pretty safe bet for sound quality standards in combination with encoder efficiency to. basically one of those three settings is the sweet spot for most people and are safe to suggest to people. like if someone wanted a quick answer for me I would just tell them to use 96kbps if they favor storage space or 128kbps if they favor sound quality and be done with it.

but with that said, I guess I could say something like this... if you have some concern with sound quality but still are trying to drive the bit rate to a bare minimum then 64kbps is likely your sweet spot, especially given the info you mentioned.

also, like someone around here mentioned not all that long ago.... I would think it's plausible that many would not notice the difference between say a 64kbps Opus file vs a MP3 v5 (130kbps) (which seems to be about the minimum bit rate for MP3 since that's about the equivalent to 96kbps with Opus/AAC) on your typical headphones/speakers mostly because there are no obvious differences in the overall sound on a typical song as when you just listen to the music without comparing it to the lossless source it's easily good enough overall.
Title: Re: Opus 1.3-rc
Post by: IgorC on 2018-07-18 04:32:36
@jensend

I’ve tested a sample of German speech “FB vs SWB” at ~16.4kbps.  One sample just for now, as always no time.
The difference is audible. I could ABX and I prefer FB.  SWB was somewhat more muffled. I've repeated the test on two different open over-ear headphones. The results were same.

You can try it too by forcing --set-ctl-int 4004=1104 for SWB.
Also I had to increase bitrate for SWB just for 0.2 kbps because I guess this is exactly an amount of rate which is saved by coding SWB instead of FB. This way the bitrate was exactly same for both SWB and FB.

P.S. I couldn't find the way to try SWB at 12 kbps as I suspect it can perform better than WB (for speech).
Title: Re: Opus 1.3-rc
Post by: ThaCrip on 2018-07-18 06:39:00
Does anyone know about when the official v1.3 release is due? ; a couple of weeks, a month?

I am not trying to rush anyone, as I would rather have them get it right then rush it, but I just wonder if there is any ball park figure of when v1.3 will be officially released considering it's over a month and a half since the original v1.3 RC release. is there any typical/ball park time frame from when a release goes RC to the official release? ; or are they still squashing some minor bugs and going to do a RC2 (or RC3?) etc?
Title: Re: Opus 1.3-rc
Post by: NetRanger on 2018-07-18 13:54:47
Opus-tools v0.1.10-79-g9288f94 (using libopus 1.3-rc-2-gc1c247d7)
Built on July 18, 2018, GCC 7.3.0

https://git.xiph.org/?p=opus.git;a=summary
https://git.xiph.org/?p=opus-tools.git;a=summary
https://git.xiph.org/?p=libopusenc.git;a=summary
Title: Re: Opus 1.3-rc
Post by: 2012 on 2018-07-18 16:10:09

P.S. I couldn't find the way to try SWB at 12 kbps as I suspect it can perform better than WB (for speech).


Use 4008 instead of 4004.
Title: Re: Opus 1.3-rc
Post by: IgorC on 2018-07-18 16:33:00
@2012

Excellent. Thank You.
Will try it later.
Title: Re: Opus 1.3-rc
Post by: 2012 on 2018-07-18 16:45:38
Captured this (https://archive.org/download/unsorted_files/BBC_World_Service_Voice_Sample.mka) live from the BBC World Service. It's a good test sample with background human noise.

I think --bitrate 12 --set-ctl-int 4008=1104 sounds slightly better than --bitrate 12.1. But the differences are subtle.
Title: Re: Opus 1.3-rc
Post by: fabiorug on 2018-07-19 11:29:40
At 48 kbps with this new build (Opus-tools v0.1.10-79-g9288f94 (using libopus 1.3-rc-2-gc1c247d7) there aren't any audible improvements yet.
64 kbps has a bit more definition.
Title: Re: Opus 1.3-rc
Post by: ThaCrip on 2018-07-20 02:36:14
@fabiorug

Quote
At 48 kbps with this new build (Opus-tools v0.1.10-79-g9288f94 (using libopus 1.3-rc-2-gc1c247d7) there aren't any audible improvements yet.

I would not expect any changes from what the OP posted to that recent one NetRanger posted in terms of sound quality because what the OP posted was a 'release candidate' which means it's nearly released. so I think that's only posted in case some minor bugs turn up at the last second they can get them corrected before the official v1.3 comes out.

so basically v1.3 is v1.3 as your not going to see sound quality jumps like you did from v1.2.1 to v1.3. so from v1.3RC to a slightly newer v1.3, say v1.3RC2, things are pretty much going to be the same with maybe minor tweaks to very small things.
Title: Re: Opus 1.3-rc
Post by: 2012 on 2018-07-20 14:06:09
original (https://archive.org/download/unsorted_files/s.wav) | opusenc-20 (https://archive.org/download/unsorted_file
s/s20.opus) | ffmpeg-20.35k (https://archive.org/download/unsorted_files/s20_ff.opus)

There seems to be an issue (maybe old) with encoding via ffmpeg. There is a clear artifact you can hear in the sample above that does not exist when encoding via opusenc.
Title: Re: Opus 1.3-rc
Post by: Leer10 on 2018-07-21 05:58:32
I really appreciate the addition of stereo speech in 1.3 below 32 kbps. At 1.2.1,  stereo coding appears to be practically nonexistent at 24 kbps. From what I've encoded, it seems that with 1.3's "stereo speech coding" does have a hard limit at around 18 kbps. Given the name, I assume that it's not intended for music, but since my ears are really prematurely aged I am a lot more sensitive to stereo content. Audio bandwidth and many artifacts only really get noticeable to me below 24 kbps. I can still hear when the voice gets grainy at lower bitrates, but improving low-bitrate stereo definitely improves my subjective quality.
Title: Re: Opus 1.3-rc
Post by: quadH on 2018-07-21 23:06:49

P.S. I couldn't find the way to try SWB at 12 kbps as I suspect it can perform better than WB (for speech).


Use 4008 instead of 4004.

Code: [Select]
#define OPUS_SET_MAX_BANDWIDTH_REQUEST       4004
#define OPUS_SET_BANDWIDTH_REQUEST           4008

Available:

Code: [Select]
#define OPUS_BANDWIDTH_NARROWBAND            1101 /**< 4 kHz bandpass @hideinitializer*/
#define OPUS_BANDWIDTH_MEDIUMBAND            1102 /**< 6 kHz bandpass @hideinitializer*/
#define OPUS_BANDWIDTH_WIDEBAND              1103 /**< 8 kHz bandpass @hideinitializer*/
#define OPUS_BANDWIDTH_SUPERWIDEBAND         1104 /**<12 kHz bandpass @hideinitializer*/
#define OPUS_BANDWIDTH_FULLBAND              1105 /**<20 kHz bandpass @hideinitializer*/

1102 applies an 8 kHz bandpass like 1103, not sure if it's a bug.

Source: https://github.com/gcp/opus/blob/master/include/opus_defines.h#L130
Title: Re: Opus 1.3-rc
Post by: fabiorug on 2018-07-22 09:02:37
I have two question:

1) At 24 kbps, does Opus 1.3 encode stereo audio as:
12 kbps mono + 12 kbps or it uses hybrid mode or other tricks?
How does Opus encode stereo audio?

2) Why especially  at 48 kbps there is this artifact (similar to the sound of a leaf)?
It uses hybrid mode? Or it changes from speech mode to music mode?

Title: Re: Opus 1.3-rc
Post by: IgorC on 2018-07-24 01:09:45
1102 applies an 8 kHz bandpass like 1103, not sure if it's a bug.
https://git.xiph.org/?p=opus.git;a=commit;h=287cb030ab8a59dcecbb7ab8ea689f6dd5eb38b8
"Switch from narrowband to wideband at 9 kb/s, don't use mediumband"

How does Opus encode stereo audio?

Both M/S and Intensity Stereo https://en.wikipedia.org/wiki/Joint_(audio_engineering)#Joint_stereo
https://tools.ietf.org/html/rfc6716
Title: Re: Opus 1.3-rc
Post by: NetRanger on 2018-07-28 12:05:08
Opus-tools v0.1.10-80-g1a646c4 (using libopus 1.3-rc-12-gbc4ecf19)
Built on July 28, 2018, GCC 7.3.0

https://git.xiph.org/?p=opus.git;a=summary
https://git.xiph.org/?p=opus-tools.git;a=summary
https://git.xiph.org/?p=libopusenc.git;a=summary
Title: Re: Opus 1.3-rc
Post by: soundping on 2018-08-01 01:34:05
What uses ambisonics in opus?
Title: Re: Opus 1.3-rc
Post by: GeSomeone on 2018-08-08 12:43:45
What uses ambisonics in opus?
It appears to have something to do with multi-channel (surround) encoding. No idea what it brings.
Title: Re: Opus 1.3-rc
Post by: LithosZA on 2018-08-08 14:32:38
What uses ambisonics in opus?
It appears to have something to do with multi-channel (surround) encoding. No idea what it brings.
It is a surround format that doesn't rely on fixed speaker positions or the number of speakers. The closest thing I can think of is something like Dolby Atmos.
For example with a normal 5.1 surround audio track you need 5.1 speakers to hear the how it is intended. Then when you use headphones there is not information in the 5.1 audio track to determine how to correctly represent the sound field around the listener in stereo.
With Ambisonics you would get the correct surround sound no matter the amount of speakers. The Ambisonics B-format gets rendered to headphones or to the amount of speakers you have.
It is very useful for Virtual Reality.
Title: Re: Opus 1.3-rc
Post by: 2012 on 2018-08-08 20:12:37
A VDD introductory presentation about ambisonics:
https://vimeo.com/268916254
Title: Re: Opus 1.3-rc
Post by: NetRanger on 2018-08-27 10:35:57
Opus-tools v0.1.10-80-g1a646c4 (using libopus 1.3-rc-15-g38fca4a2)
Built on August 27, 2018, GCC 7.3.0(32bit)/8.2.0(64bit)

https://git.xiph.org/?p=opus-tools.git;a=summary
https://git.xiph.org/?p=libopusenc.git;a=summary
https://git.xiph.org/?p=opus.git;a=summary
https://git.xiph.org/?p=opusfile.git;a=summary
Title: Re: Opus 1.3-rc
Post by: moisesmcardona on 2018-09-14 22:20:36
I've been compiling the latest opus commits from GitHub and wow! 64kbit audio sounds better  :)) (Or maybe it is just me XD)

Latest as of this post is 1.3 rc 22

Code: [Select]
opus-tools 0.1.10-80-g1a646c4-dirty (using libopus 1.3-rc-22-g4a643d98-dirty)

Title: Re: Opus 1.3-rc
Post by: moisesmcardona on 2018-09-15 23:46:50
Submitted a Pull Request today that adds the --tracknumber argument to add track number to opus files. It was approved and is now part of opusenc  :D
Title: Re: Opus 1.3-rc
Post by: madmax on 2018-09-17 20:40:02
Quote
Opus release 1.3-rc2

This is a second release candidate for the upcoming 1.3 release and includes:
- Fixing an issue with bandwidth detection
- Ambisonics support now exabled by default
- Ambisonics now uses families 2 and 3 (instead of experimental 253 and 254)
- Hardening is now enabled by default
Title: Re: Opus 1.3-rc
Post by: jmvalin on 2018-09-18 06:00:43
Quote
Opus release 1.3-rc2
...
Please don't do that. I realize how tempting it is to scoop everyone in announcing a release before the maintainers do, but it's not helping. These are "tentative" tags and tarballs. They may be released as is or they may not if we find build issues while finishing the release. We uploaded them in advance to minimize the risk of screwing up during the release, but if it's no longer possible to do that, then we'll have to upload everything at once, increasing the odds of messing up. Yes, Opus 1.2-rc2 is coming, but it's not all wrapped up and announced for a reason. Please respect that.
Title: Re: Opus 1.3-rc
Post by: moisesmcardona on 2018-09-18 22:38:57
Hope my PR is included into opus-tools. Been fixing a few bugs in the latest commits but it should all been fixed by now.
Title: Re: Opus 1.3-rc
Post by: soundping on 2018-09-18 22:45:44
1018K 18-Sep-2018 18:27

https://archive.mozilla.org/pub/opus/win32/opus-tools-0.2-win32.zip
Title: Re: Opus 1.3-rc
Post by: ThaCrip on 2018-09-18 23:11:30
@soundping

Any chance there is a 64bit one? ; I ask because those encode files quicker than the 32bit.

but speaking of 64bit.... is there even a official Opus 64bit? ; because I noticed in the Foobar2000 Encoders Pack it only offers the 32bit one.
Title: Re: Opus 1.3-rc
Post by: jmvalin on 2018-09-18 23:33:14
https://archive.mozilla.org/pub/opus/win32/opus-tools-0.2-win32.zip

Please! These are all temporary uploads while we're preparing for a real release. You're really not helping.
Title: Re: Opus 1.3-rc
Post by: moisesmcardona on 2018-09-19 00:32:28
@soundping

Any chance there is a 64bit one? ; I ask because those encode files quicker than the 32bit.

but speaking of 64bit.... is there even a official Opus 64bit? ; because I noticed in the Foobar2000 Encoders Pack it only offers the 32bit one.

I compile the Opus GitHub repos using Visual Studio 2017 using the Release x64 configuration  :))

In Foobar2000, you should be able to locate the opusenc.exe file. I didn't installed the encoder pack but I have it running the local executable. The same applied for EAC to rip Audio CD to Opus directly.
Title: Re: Opus 1.3-rc
Post by: madmax on 2018-09-19 19:26:27
Quote
Opus release 1.3-rc2
...
Please don't do that
....

well, i didn't point to any source code.