Skip to main content

Topic: Opusenc's built-in resampler (Read 5824 times) previous topic - next topic

0 Members and 1 Guest are viewing this topic.
  • ziemek.z
  • [*]
Opusenc's built-in resampler
Why is opusenc using Speex resampler? Why not SoX? I don't want to resample in SoX on my own every time I encode something because Xiph's devs decided to use not fully accurate resampler >:( Is it possible to exchange Speex SRC with SoX SRC in Opus 1.2? I know that SoX is quite fast, but Speex should be even faster, so is it possible to keep both SRCs and include a knob? And if won't be possible,  would be possible to make build with changed SRC?
sox -e float -b 32 -V4 -D gain -1 rate -v 48000 norm -1
opusenc --bitrate 96

  • jmvalin
  • [*][*][*][*][*]
  • Developer
Re: Opusenc's built-in resampler
Reply #1
What exactly is your issue with the Speex resampler?

  • IgorC
  • [*][*][*][*][*]
Re: Opusenc's built-in resampler
Reply #2
Is it possible to exchange Speex SRC with SoX SRC in Opus 1.2?
If You will use an external resampler  then Speex SRC won't be used.

... because Xiph's devs decided to use not fully accurate resampler
Speex resampler is transparent.  https://translate.google.com/translate?sl=auto&tl=en&js=y&prev=_t&hl=en&ie=UTF-8&u=http%3A%2F%2Faudiophilesoft.ru%2Fpubl%2Fmy%2Ffoo_resamplers%2F11-1-0-34&edit-text=

If You think you hear difference then try both ways ( native Speex resampler vs pre-resampled  SoX/SSRC) and post somoe results of blind tests. 

We've tested Opus at 96 kbps (48 kHz, stereo) with native Speex resampler in public test http://listening-test.coresv.net/ and haven't noticed any audible issues.

Some comparisons of resamplers http://src.infinitewave.ca/
  • Last Edit: 15 February, 2017, 03:13:40 PM by IgorC

  • lvqcl
  • [*][*][*][*][*]
  • Developer
Re: Opusenc's built-in resampler
Reply #3
Why is opusenc using Speex resampler? Why not SoX?
IMHO that's because speex resampler is simple and well-tested.

because Xiph's devs decided to use not fully accurate resampler
It's accurate enough. Or do you have some audible problems because of it?

I know that SoX is quite fast, but Speex should be even faster
Actually no, speex resampler is slower.

  • mpuzirew
  • [*]
Re: Opusenc's built-in resampler
Reply #4
Speex resampler is transparent. https://translate.google.com/translate?sl=auto&tl=en&js=y&prev=_t&hl=en&ie=UTF-8&u=http%3A%2F%2Faudiophilesoft.ru%2Fpubl%2Fmy%2Ffoo_resamplers%2F11-1-0-34&edit-text=
But Google Translate isn't :)) Speex: "This recently appeared plug-resempler clearly lags behind its rivals.", completely opposite of the original Russian phrase. In Russian, "clearly NOT behind" :)
  • Last Edit: 15 February, 2017, 04:39:27 PM by mpuzirew

  • jmvalin
  • [*][*][*][*][*]
  • Developer
Re: Opusenc's built-in resampler
Reply #5
I know that SoX is quite fast, but Speex should be even faster
Actually no, speex resampler is slower.

Well, the Speex resampler is whatever speed you want it to run. There's a quality knob that goes from 0 to 10 and makes a huge difference in the running time. The higher settings are mostly for audiophiles, spectrograms and bragging rights. In practice, I cannot hear the difference between settings 5 and 10, despite the large difference in complexity (and overly sensitive spectrograms).

  • ziemek.z
  • [*]
Re: Opusenc's built-in resampler
Reply #6
Some comparisons of resamplers http://src.infinitewave.ca/
I've seen that page before and I found out RIGHT THERE that Speex resampled isn't as perfect as SoX. Attached screenshot as proof.

I know that SoX is quite fast, but Speex should be even faster
Actually no, speex resampler is slower.
So why not include resampler which is both accurate and fast? Why include something slower and not perfect?

Question for Opus devs: is it possible to exchange Speex Resampler's sources with SoX Resampler's ones before compiling the code?
sox -e float -b 32 -V4 -D gain -1 rate -v 48000 norm -1
opusenc --bitrate 96

  • jmvalin
  • [*][*][*][*][*]
  • Developer
Re: Opusenc's built-in resampler
Reply #7
Some comparisons of resamplers http://src.infinitewave.ca/
I've seen that page before and I found out RIGHT THERE that Speex resampled isn't as perfect as SoX. Attached screenshot as proof.
If you look at the legend, you'll see that the absolutely horrible artefacts caused by the Speex resampler have an amplitude of around -140 dB. Rather than involve TOS 8, I will just make the following recommendation: If you can hear the artefacts caused by the Speex resampler, then you really should not be using a lossy codec. I will actually add that you *also* shouldn't be using 16-bit audio (hence CDs) because the -96 dB noise floor it causes is about 40 dB worse than the awful resampling artefacts you're pointing out.

Quote
So why not include resampler which is both accurate and fast? Why include something slower and not perfect?
The Speex resampler is fast enough for the job -- we don't run it at the highest quality because that's overkill (see above). The main reason we use it is not because it's better than all the others (it's likely not), but because it's good enough and it's self-contained so it doesn't add an external dependency. OTOH, using Sox would require making opusenc GPL-licensed, which some people would not like.

Quote
Question for Opus devs: is it possible to exchange Speex Resampler's sources with SoX Resampler's ones before compiling the code?
Well, the Opus tools source is freely available, so you're free to modify it to use whatever resampler you like.

  • ziemek.z
  • [*]
Re: Opusenc's built-in resampler
Reply #8
If you look at the legend, you'll see that the absolutely horrible artefacts caused by the Speex resampler have an amplitude of around -140 dB.
Oh my God... I forgot to look at the dB scale... :(
I did it and found out that you're right. They're quiet! And thanks for explaining other reasons for using Speex Resampler in Opus tools :)
  • Last Edit: 15 February, 2017, 06:03:44 PM by ziemek.z
sox -e float -b 32 -V4 -D gain -1 rate -v 48000 norm -1
opusenc --bitrate 96

  • bennetng
  • [*][*][*][*][*]
Re: Opusenc's built-in resampler
Reply #9
If you look at the legend, you'll see that the absolutely horrible artefacts caused by the Speex resampler have an amplitude of around -140 dB. Rather than involve TOS 8, I will just make the following recommendation: If you can hear the artefacts caused by the Speex resampler, then you really should not be using a lossy codec. I will actually add that you *also* shouldn't be using 16-bit audio (hence CDs) because the -96 dB noise floor it causes is about 40 dB worse than the awful resampling artefacts you're pointing out.

This.
Here are some screenshots based on 24-bit flac input, and the audio files.

  • ziemek.z
  • [*]
Re: Opusenc's built-in resampler
Reply #10
This.
Here are some screenshots based on 24-bit flac input, and the audio files.
And don't forget to look at the scale, Fast. dB range shown is very wide so some bright colors are used to show quiet sounds.
  • Last Edit: 21 May, 2017, 07:25:13 AM by ziemek.z
sox -e float -b 32 -V4 -D gain -1 rate -v 48000 norm -1
opusenc --bitrate 96

  • bennetng
  • [*][*][*][*][*]
Re: Opusenc's built-in resampler
Reply #11
In fact the spectrograms are so sensitive they can even show the 24-bit dither noise in the flac screenshots. Graphs like these can make everything worse than SoX look like crap.

  • [JAZ]
  • [*][*][*][*][*]
Re: Opusenc's built-in resampler
Reply #12
Mmm... there's something from the  Sweep2448Opus.png  that is making me wonder if there isn't an error somehow in the codec. Not on the resampler part, but on the filter part. (or maybe in the reconstruction part, don't know...)

As one can see, the output is 48Khz, but it has a filter at 20Khz. In both, the 44Khz resampled and the 48Khz, there's some problem when the audio is above 20Khz, affecting the whole spectrum range (seconds 9 to 9.5 in 44Khz, and seconds 9 to 10 in 48Khz).
I'm not sure why it affects less to the 44Khz one.  Maybe the filter is on decoding? or in some place after some analyses?

  • bennetng
  • [*][*][*][*][*]
Re: Opusenc's built-in resampler
Reply #13
I encoded/decoded the file with foobar2000 using the free encoder pack, using maximum VBR bitrate in order to minimize encoding artifacts and show the effect of the resampler. The flac and opus files are also attached for further inspection.

I didn't expect comment about the prettiness of the spectrograms because it is a psychoacoustic codec.

  • jmvalin
  • [*][*][*][*][*]
  • Developer
Re: Opusenc's built-in resampler
Reply #14
As one can see, the output is 48Khz, but it has a filter at 20Khz. In both, the 44Khz resampled and the 48Khz, there's some problem when the audio is above 20Khz, affecting the whole spectrum range (seconds 9 to 9.5 in 44Khz, and seconds 9 to 10 in 48Khz).
I'm not sure why it affects less to the 44Khz one.  Maybe the filter is on decoding? or in some place after some analyses?
Opus does not code any frequencies above 20 kHz because that's how far the human hearing goes (and even then very few people hear up to 20 kHz). As for all the ugly stuff you see at lower frequencies when the signal goes above 20 kHz... keep in mind that it corresponds to an amplitude of -120 dB to -140 dB, i.e. totally inaudible. That's the problem when you show a spectrogram with 180 dB of dynamic range -- most of what you see cannot possibly be audible (and most of the rest also isn't but because of masking). Just like you aren't listening to images, you shouldn't be looking at audio clips (spectrograms) to determine quality. At best a spectrogram can be useful as a way to identify an artefact you've already heard, but that's about it.

  • saratoga
  • [*][*][*][*][*]
Re: Opusenc's built-in resampler
Reply #15
Mmm... there's something from the  Sweep2448Opus.png  that is making me wonder if there isn't an error somehow in the codec. Not on the resampler part, but on the filter part. (or maybe in the reconstruction part, don't know...)

I think it's a great example of why you shouldn't use spectrograms to compare lossy codecs.

I'm not sure why it affects less to the 44Khz one.  Maybe the filter is on decoding? or in some place after some analyses?

Probably what you are seeing is the resampling from 44.1k->48k attenuating additional high frequency energy, less of which is then left over to alias into lower frequencies during coding.  Basically the resampler is a type of lowpass filter. 

  • ziemek.z
  • [*]
Re: Opusenc's built-in resampler
Reply #16
Opus does not code any frequencies above 20 kHz because that's how far the human hearing goes (and even then very few people hear up to 20 kHz). As for all the ugly stuff you see at lower frequencies when the signal goes above 20 kHz... keep in mind that it corresponds to an amplitude of -120 dB to -140 dB, i.e. totally inaudible. That's the problem when you show a spectrogram with 180 dB of dynamic range -- most of what you see cannot possibly be audible (and most of the rest also isn't but because of masking). Just like you aren't listening to images, you shouldn't be looking at audio clips (spectrograms) to determine quality. At best a spectrogram can be useful as a way to identify an artefact you've already heard, but that's about it.
This thread is another pretty example of "Don't listen with your eyes". Even if you try, at least look at the legend. I don't think there should be something more to add in this thread.
sox -e float -b 32 -V4 -D gain -1 rate -v 48000 norm -1
opusenc --bitrate 96

  • bennetng
  • [*][*][*][*][*]
Re: Opusenc's built-in resampler
Reply #17
Graphs of 16-bit flac input using the same misleading 180dB range.

  • [JAZ]
  • [*][*][*][*][*]
Re: Opusenc's built-in resampler
Reply #18
Just like you aren't listening to images, you shouldn't be looking at audio clips (spectrograms) to determine quality.
I think it's a great example of why you shouldn't use spectrograms to compare lossy codecs.
I did not say that quality was detrimental due to what I saw. I said that it seemed that the implementation could have errors or limitations.  If we take the range into account, then we can only say that it's good enough for the intended purpose, but only if the cost doesn't justify the improvement.
It would seem illogical to have a bad implementation of something, to know it, to know an easy fix, and not fix it just because it's "good enough".
I am not saying that it is the case here. I just pointed that the filter that i see there is of less quality than the resampler itself.

Probably what you are seeing is the resampling from 44.1k->48k attenuating additional high frequency energy, less of which is then left over to alias into lower frequencies during coding.  Basically the resampler is a type of lowpass filter. 

I didn't think about that, but it makes sense, a soft rollout filter that partially filters the 21 to 22Khz range, indeed. But then, this is a proof of what I've just said above, the 20Khz filter is of less quality than the 22Khz filter at the resampler.

  • saratoga
  • [*][*][*][*][*]
Re: Opusenc's built-in resampler
Reply #19
It would seem illogical to have a bad implementation of something, to know it, to know an easy fix, and not fix it just because it's "good enough".

I think trying to find problems in lossy codecs by looking at a power spectrum is a lot less logical. 

I didn't think about that, but it makes sense, a soft rollout filter that partially filters the 21 to 22Khz range, indeed. But then, this is a proof of what I've just said above, the 20Khz filter is of less quality than the 22Khz filter at the resampler.

Again, look at the scale bar before you decide a difference in quality exists. 

  • jmvalin
  • [*][*][*][*][*]
  • Developer
Re: Opusenc's built-in resampler
Reply #20
I didn't think about that, but it makes sense, a soft rollout filter that partially filters the 21 to 22Khz range, indeed. But then, this is a proof of what I've just said above, the 20Khz filter is of less quality than the 22Khz filter at the resampler.
The 20 kHz "filter" isn't a filter. It's the effect of the MDCT when you don't code the highest frequencies. It's all on purpose. What you see is MDCT leakage and it's part of every codec, though there's a bit more of it in Opus due to some (quite voluntary) trade offs we made. Of course, we could have changed that MDCT to make the spectrogram nicer and the sound worse...

  • Klimis
  • [*]
Re: Opusenc's built-in resampler
Reply #21
What I see is that this whole topic would have been avoided if OPUS simply supported 44.100Hz audio without the need of resampling.
I feel like it's a matter of time until it eventually gets supported (officially or not). It's possibly the last thing that holds me back making the switch from AAC to OPUS. The less layers of change applied to the source the better outcome to the final product (audible or not), with less doubts and need for research.

  • saratoga
  • [*][*][*][*][*]
Re: Opusenc's built-in resampler
Reply #22
What I see is that this whole topic would have been avoided if OPUS simply supported 44.100Hz audio without the need of resampling.

Why stop there?  If Opus was a lossless codec then people couldn't complain about quantization error at all!

I feel like it's a matter of time until it eventually gets supported (officially or not).

Opus uses fixed power of 2 sampling rates.  That is not possible to change without making a new codec, officially or otherwise.  So no, it is not going to change. 

The less layers of change applied to the source the better outcome to the final product (audible or not), with less doubts and need for research.

This is foolish.  The point of a codec is produce high quality audio, not avoid the need for you to worry about imaginary problems. 

  • Klimis
  • [*]
Re: Opusenc's built-in resampler
Reply #23
Opus uses fixed power of 2 sampling rates.  That is not possible to change without making a new codec, officially or otherwise.  So no, it is not going to change.

Yeah right, I have seen similar stuff being said about countless situations of "this is not going to happen because..." and sooner or later, most often after some backlash, it did happen. Just, never say never. You have no idea when a person will pop up with a crazy idea.

This is foolish.  The point of a codec is produce high quality audio, not avoid the need for you to worry about imaginary problems. 

Foolish is to be passive agressive when you can't do constructive criticism. This is not going to be the last time you see a comment like mine or a topic like this for very good reasons. Even more, there is no forum TOS that will restrict people posting similar stuff because it goes against the whole nature of forums. You just cannot call somebody/everybody's claims and opinion foolish. Also, imaginary is the elitisism that alot of members around the forum feel that they are entitled to, yet it's unflattering for the image of the forum at best (to be worded in a way that is respectfull to all members of the forum).
  • Last Edit: 23 May, 2017, 02:01:30 PM by Klimis

  • saratoga
  • [*][*][*][*][*]
Re: Opusenc's built-in resampler
Reply #24
Opus uses fixed power of 2 sampling rates.  That is not possible to change without making a new codec, officially or otherwise.  So no, it is not going to change.

Yeah right,

You're not understanding me.  The Celt layer in Opus only operates at 48 KHz.  24 KHz can be implemented by decimation.  This is not a matter of my opinion.  It is a simple fact that you can verify by checking the spec. 

I have seen similar stuff being said about countless situations of "this is not going to happen because..." and sooner or later, most often after some backlash, it did happen.

This is wrong thinking.  People say they want things all the time.  To win the lottery, to be young again, etc.  I can assure you that this just isn't going to happen.

This is foolish.  The point of a codec is produce high quality audio, not avoid the need for you to worry about imaginary problems. 

Foolish is to be passive agressive when you can't do constructive criticism.

Nothing I have said is passive aggressive, and you have not presented any constructive criticism.  I am addressing the underlying point clearly and directly.  Fixed sampling rates have a very minor performance hit, but greatly simplies transform coding and reduce latency.  This is a lot to give up just because you don't want to have to do "research" or because you have unfounded "doubts".

Even more, there is no forum TOS that will restrict people posting similar stuff because it goes against the whole nature of forums.

FWIW, you are violating TOS#8 and should probably stop, but I don't see the need to bring that up because I believe you probably didn't mean to.
  • Last Edit: 23 May, 2017, 02:31:04 PM by saratoga