Skip to main content

Notice

Please note that most of the software linked on this forum is likely to be safe to use. If you are unsure, feel free to ask in the relevant topics, or send a private message to an administrator or moderator. To help curb the problems of false positives, or in the event that you do find actual malware, you can contribute through the article linked here.
Topic: Opus 1.3-rc (Read 53961 times) previous topic - next topic
0 Members and 1 Guest are viewing this topic.

Re: Opus 1.3-rc

Reply #75
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.


Re: Opus 1.3-rc

Reply #77
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.

Re: Opus 1.3-rc

Reply #78
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.
For music I suggest (using Foobar2000)... MP3 (LAME) @ V5 (130kbps). NOTE: using on AGPTEK-U3 as of Mar 18th 2021. I use 'fatsort' (on Linux) so MP3's are listed in proper order on AGPTEK-U3.

Re: Opus 1.3-rc

Reply #79
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.

Re: Opus 1.3-rc

Reply #80
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". 


Re: Opus 1.3-rc

Reply #81
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.

 

Re: Opus 1.3-rc

Reply #82
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.

Re: Opus 1.3-rc

Reply #83
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.

Re: Opus 1.3-rc

Reply #84
@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.
For music I suggest (using Foobar2000)... MP3 (LAME) @ V5 (130kbps). NOTE: using on AGPTEK-U3 as of Mar 18th 2021. I use 'fatsort' (on Linux) so MP3's are listed in proper order on AGPTEK-U3.

Re: Opus 1.3-rc

Reply #85
@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).

Re: Opus 1.3-rc

Reply #86
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?
For music I suggest (using Foobar2000)... MP3 (LAME) @ V5 (130kbps). NOTE: using on AGPTEK-U3 as of Mar 18th 2021. I use 'fatsort' (on Linux) so MP3's are listed in proper order on AGPTEK-U3.



Re: Opus 1.3-rc

Reply #89
@2012

Excellent. Thank You.
Will try it later.

Re: Opus 1.3-rc

Reply #90
Captured this 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.

Re: Opus 1.3-rc

Reply #91
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.

Re: Opus 1.3-rc

Reply #92
@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.
For music I suggest (using Foobar2000)... MP3 (LAME) @ V5 (130kbps). NOTE: using on AGPTEK-U3 as of Mar 18th 2021. I use 'fatsort' (on Linux) so MP3's are listed in proper order on AGPTEK-U3.


Re: Opus 1.3-rc

Reply #94
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.

Re: Opus 1.3-rc

Reply #95

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

Re: Opus 1.3-rc

Reply #96
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?


Re: Opus 1.3-rc

Reply #97
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


Re: Opus 1.3-rc

Reply #99
What uses ambisonics in opus?