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?
What exactly is your issue with the Speex resampler?
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/
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.
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" :)
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).
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?
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.
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.
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.
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 :)
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.
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.
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.
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?
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.
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.
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.
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.
Graphs of 16-bit flac input using the same misleading 180dB range.
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.
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.
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...
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.
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.
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).
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.
What I see is that this whole topic would have been avoided if OPUS simply supported 44.100Hz audio without the need of resampling.
What I see is that this whole your post would have been avoided if You just take 5 minutes to read the topic and understand that an error introduced by modern resamplers is much less than quantization error of lossless material (for both 16 and 24 bits .wav)
It's 100% inaudible.
It's possibly the last thing that holds me back making the switch from AAC to OPUS.
Again. Modern resamplers are transparent today. It's 2017. Not 1987.
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.
Yes, I do know that. What I meant with my original post was that there may be a day that OPUS inherits a newer generation layer that may allow for such change. It's not a very accurate example but it's the best one I can think of right now is xHE-AAC (that's an extension I know). I hope you get what I mean and where I'm going.
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.
The lottery is a real far fetch from what I meant. For example, I am working in a community of emulation. There were so many stuff being said for even a decade and eventually someone stepped in and proved everyone wrong. Even I was defending that some stuff are not possible and when I got proven wrong, I was rubbing my eyes. The world of technology is full of constant surprises, you are constantly being proven wrong.
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.
No, I don't have the intention to break any TOS as I hope it's obvious, but when you try to make sense in a way that what you say it is based partly in common sense or past tests or an abstract idea and there is no other way to enforce your statement there is no way to avoid being borderline breaking the TOS. My intention is not the typical "This sounds better than that /endofpost" but more like "It can't be just me that thinks that ..." way. I'd hope there was a way that the TOS was a bit more "loose" in a way that I don't have to struggle in order to not offend any person or violate the TOS when it's not my intention and even worse my whole point gets lost in the filtering eyes of a mod. It's a pitty.
Yes, I do know that. What I meant with my original post was that there may be a day that OPUS inherits a newer generation layer that may allow for such change. It's not a very accurate example but it's the best one I can think of right now is xHE-AAC (that's an extension I know). I hope you get what I mean and where I'm going.
No no no.
We understood perfectly what You wanted to say.
xHE-AAC isn't a simply nice and shiny "extension". It's a new format which is
only backward compatible with AAC and HE-AAC.
It means if You want to add 44.1 kHz sample rate your new "extension" won't be compatible with original Opus format. The only backward compatible sampling rate will be still 48 kHz. And I'm sure developers don't want to f*** up Opus this way.
The bitstream of Opus is frozen. https://tools.ietf.org/html/rfc6716
You can't add sampling rate without breaking compatibility.
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 do you care about the codec having an internal resampler? It's not like Opus is the only one doing that. HE-AAC does it for SBR, MP3 does it at low bitrate to avoid encoding the high frequencies. Opus handles 44.1 kHz just fine and if you didn't "look under the hood", you wouldn't be able to tell how it does it.
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.
How is it preventing you from using Opus. What *observable* difference does it make? And BTW, there *are* ways to use 44.1 kHz directly with Opus (no, I'm not going to tell you how). They have been shown (through listening test) to produce worse results than resampling. Is the worse quality worth getting rid of the resampler?
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.
If something like a resampler scares you, I hope you've never looked at what a lossy audio codec does! Also, I hate to break it to you, but when you play your favorite 44.1 kHz music, it very often gets resampled to 48 kHz by your audio driver before being fed to your soundcard. At that point, the soundcard resamples it again to a few MHz because it's DAC is a 1-bit sigma-delta conversion. I would suggest you go back to good old vinyl, but even those include RIAA compensation filters. Oh and tapes have these low-pass filters to remove the ultrasonic bias. Watch out, there's filters everywhere, and they're out to get you!
I'm not such an amateur, I know how lossy codecs work, even worse, we had to study a couple of them back in college (I thought I'd like this course when I was giving my application but I ended up hating it). My biggest issue with resampling is that every now and then (very rarely though) something might go horribly wrong, like there was that one time I was listening to some chiptune/PSG generated music that failed horribly (loud harmonic aliasing ). There were 3 available streams: AAC-HE, MP3 and OPUS. The OPUS one was the only one with the issue. And it was a pitty because it was the only high bitrate stream available.
Also btw, I just wanted to get it out of me:
I absolutely, LOATHE vinyl. There I said it.
I do not miss it and I find this retro fashion thing that goes on with vinyl at best cringeworthy.
I do get that people may have a nostalgic attachment to their vinyls and the experiences they had with them back in the day but as a format to be used today instead of any kind of proper digital format gives me this face:
(http://gifrific.com/wp-content/uploads/2015/02/Britney-Spears-Cringe-Face.gif)
PS: I hope everbody laughed as much as I did! XD
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.
Yes, I do know that. What I meant with my original post was that there may be a day that OPUS inherits a newer generation layer that may allow for such change. It's not a very accurate example but it's the best one I can think of right now is xHE-AAC (that's an extension I know). I hope you get what I mean and where I'm going.
xHE-AAC is not an extension to AAC. It is the branding for USAC, which is a new audio format.
If you are saying that you hope Xiph will one day create a different audio format than Opus that supports 44.1k, then you are in luck. They have one. It is called Vorbis and you can use it right now if you like.
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.
The lottery is a real far fetch from what I meant. For example, I am working in a community of emulation. There were so many stuff being said for even a decade and eventually someone stepped in and proved everyone wrong.
So have I. I remember one person asking me why if he had a fast enough processor, why our gameboy emulator would not handle his N64 ROMs. I told him that he was wrong, that different devices required different emulators, not just faster processors. Do you think he was right and that I will be proved wrong in my belief that the N64 and Gameboy are different hardware devices?
My intention is not the typical "This sounds better than that /endofpost" but more like "It can't be just me that thinks that ..." way. I'd hope there was a way that the TOS was a bit more "loose" in a way that I don't have to struggle in order to not offend any person or violate the TOS when it's not my intention and even worse my whole point gets lost in the filtering eyes of a mod.
The intention is to prevent people from wasting everyone's time making uninformed claims about audio, and instead encourage them to go out and test their assumptions. You aren't offending people, but you are doing the exact thing everyone wants you not to do.
My biggest issue with resampling is that every now and then (very rarely though) something might go horribly wrong,
Resampling is a deterministic process. There is no now and then. It either works or it does not. We know how to make resamplers that work. Simple as that.
like there was that one time I was listening to some chiptune/PSG generated music that failed horribly (loud harmonic aliasing ).
Is the implication that you believe this has something to do with resampling? If so, you should explain carefully how you came to that conclusion.
Is the implication that you believe this has something to do with resampling? If so, you should explain carefully how you came to that conclusion.
Yep. It sounded exactly like when you apply nearest neighbor algo on samples. Harmonics everywhere! No filtering, nothing! I don't know why the resampler failed though. I'm not sure but I have a feeling it -might- have to do with the encoder being picky when fed non-standard sampling rate files, I bet the ones that were fed to it were either slightly above or slightly below 32KHz or 44,1KHz. I repeat again this is a wild guess, I can't know what the streamer did behind his desk.
And BTW, there *are* ways to use 44.1 kHz directly with Opus (no, I'm not going to tell you how).
You actually gave me an idea, I doubt it's the same thing but let me try it.
EDIT:
Heh, It worked!
If you edit the sample rate of a WAV file with a hex editor and change 44 AC with 80 BB, encode the file to opus and the force opus to spit the samples out at 44100Hz you essentially did it. I don't hear anything wrong with the output file. Is there a sample file that might introduce audible issues because in theory it shouldn't.
Is the implication that you believe this has something to do with resampling? If so, you should explain carefully how you came to that conclusion.
Yep. It sounded exactly like when you apply nearest neighbor algo on samples. Harmonics everywhere! No filtering, nothing!
If you really did base that determination on nothing, then this thread will have been a great example of why we have TOS#8.
I bet the ones that were fed to it were either slightly above or slightly below 32KHz or 44,1KHz. I repeat again this is a wild guess, I can't know what the streamer did behind his desk.
I would have blamed clipping, but no, its not due to the sampling rate being off. All that does is introduce a pitch error.
Is there a sample file that might introduce audible issues because in theory it shouldn't.
Depends on the bitrate. You're basically making all the encoders assumptions about frequency be off, so nothing will be encoded quite right. I bet it sounds ok though if you throw enough bitrate at it. The difference is frequency is close enough that it'll just make everything a little less accurate, but I doubt it breaks anything completely.
Heh, It worked!
If you edit the sample rate of a WAV file with a hex editor and change 44 AC with 80 BB, encode the file to opus and the force opus to spit the samples out at 44100Hz you essentially did it. I don't hear anything wrong with the output file. Is there a sample file that might introduce audible issues because in theory it shouldn't.
You realize that in doing so, you're not only causing the max coded frequency to be around 18 kHz rather than 20 kHz, but you're making all the psychoacoustics wrong by moving all the critical bands? You could also just flip the stereo bit while you're at it, no? Despite any class you might have had in college, I don't think you actually understand much of lossy codecs. If you *actually* want to learn something about psychoacoustics, I would suggest starting here (http://www.brill.com/introduction-psychology-hearing-0).
What really matters are not the resampling and spectrogram. It's the sound. For example the file here when encoded with 35kbps, opus has more audible distortion than fhgaac.
https://hydrogenaud.io/index.php?action=dlattach;topic=113187.0;attach=10692
Again the encoded files are attached for further inspection. I only used foobar's encoder pack and front end to encode the files, without any custom tweaking. Pre-SoX resampled opus file also attached to show the distortion is not caused by bad resampling.
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...
Ok thanks. That clears out my doubts and shows that it's intended behaviour given that it's precise enough for the intended usage.
I think trying to find problems in lossy codecs by looking at a power spectrum is a lot less logical.
Sure... It is easier with JUnit (http://junit.org/junit4).
But while you're Junit-ing it, looking at the data (be it represented in numbers or in pixels) can give you a zoom-out to see if everything is in place.
Again, look at the scale bar before you decide a difference in quality exists.
Quality is a quantizable thing. If you have the adequate tools, you are capable of classifying and ordering the tested subjects based on the obtained value.
You actually wanted to say that I am talking about an INAUDIBLE quality difference, and I agree, and that's why I've been asking if it was intentional or it was an error. jmvalin answered that.
I think if your definition of audio quality does not relate to audibility then it is not a useful thing to quantize.
I am not as technical as most people here in the forum, but here's how I consider the 48kHz fixed sampling rate or Opus.
I sometimes find it bad since sometimes, I want to ABX Opus with another codec, but just because Opus outputs 48kHz audio, I have to go for extra measures just to resample the output of the other codec to 48kHz also.
However, honestly, I don't mind Opus' 48kHz output. True, CDs are at 44.1kHz, but besides CDs, many things are operating at 48kHz, like DVDs and Bluray audio. Also, as resampling to a higher sample rate is (at least audibly) lossless (https://www.youtube.com/watch?v=cIQ9IXSUzuM), then I see no problem encoding CD audio in Opus.
I'm the kind of guy who keeps a large number of songs in his phone, so I use low bitrates of 64kbps. Compared to encoding 44.1kHz CD audio using 44.1kHz AAC-HE where I can notice bad low bitrate artifacts, I would rather use 48kHz Opus and appreciate the fact that this is the best 64kbps audio can get.
I'm all for supporting Opus, no matter if it suddenly decides to output 24-bit 48kHz audio, as long as it improves the audible sound quality.
Not looking for an argument here--just stating my own side.
Yep. It sounded exactly like when you apply nearest neighbor algo on samples. Harmonics everywhere! No filtering, nothing!
Not trying to be a smart aleck or something (please--the least thing I want is an enemy) but I am also a real fan of chiptune music. (The fact that Opus does best when it comes to chiptune music as per my ABX tests is another topic but https://hydrogenaud.io/index.php/topic,105808.new.html )
Some computers do apply nearest neighbor resampling on samples, most noticeably the Amiga's sound chip nicknamed "Paula" does this on the hardware level. The Gameboy has a single sound channel that can playback samples resampled using--yep, nearest neighbor. The C64 and Atari XL/XE can also play samples through software mixing, and when it comes to their slow CPUs burdened with realtime audio mixing, we have no choice but to go with nearest neighbor resampling. We can't afford even linear resampling with these computers. A notable exception however, is with the Super NES / SNES / Super Famicom, which uses gaussian resampling on the hardware level (not quite sure if it is indeed called gaussian but I'm certain it doesn't use nearest neighbor or linear resampling--it uses something more advanced than linear but less advanced than cubic.)
Since you mentioned PSG, then that points us to (mostly) non-sample based chips, like the Nintendo's 2A03 or the 3-channel AY chips, or even FM synth ones like the OPL series, maybe even the Gameboy's sound chip. These chips make variable pulse width square waves, and it won't even matter if we resample them using nearest neighbor or cubic--those are square waves :) The NES (not Super NES) also creates triangle waveforms by playing back an internally stored sample of a (weirdly distorted) triangle wave at various frequencies resampled--yep, nearest neighbor :) The VRC6 sound chip made by Konami uses an internal counter that increments in fixed time intervals before looping back to zero and incrementing again to create a sawtooth waveform. Analyzing the waveform, it exibits a "staircase"-like wave, produced because of the integer counter which jumps incrementally, the jump size depending on the requested frequency. Since it isn't a perfect sawtooth wave, nearest neighbor resampling wouldn't hurt too much :) Yet another NES sound expansion chip, the Namco N106 (not sure about the name) is a sample-based audio chip that resamples in nearest neighbor.
My point is that chiptune already uses lots and lots of linear neighbor interpolation / resampling. In my opinion, THAT gives them that unique chiptune feel. Because of that, they already contain large amounts of harmonics (can't blame square waves--that's normal and expected from them) and if a lossy audio codec can't retain those harmonics, then that's not a good codec.
Just my two cents. Please feel free to ignore this or what. :)
I sometimes find it bad since sometimes, I want to ABX Opus with another codec, but just because Opus outputs 48kHz audio, I have to go for extra measures just to resample the output of the other codec to 48kHz also.
You shouldn't resample other audio to 48k, you should resample the opus output to match the input. I am not certain, but I believe opusdec can do this automatically.
I am not certain, but I believe opusdec can do this automatically.
Yep, opusdec can do this. Original samplerate is saved in Opus file and opusdec automatically resamples to original rate while decoding.
I am not certain, but I believe opusdec can do this automatically.
Yep, opusdec can do this. Original samplerate is saved in Opus file and opusdec **automatically resamples to original rate** while decoding.
Why would such a thing be required?
Now your signature:
sox -e float -b 32 -V4 -D gain -3 rate -v 48000 norm -1
opusenc --bitrate 128
Interesting!
So why are you converting the source audio file to 32-bit floating point? Won't opus convert the audio file to 16-bit? I just made a post wondering the same (http://hydrogenaud.io/index.php?topic=118253.0).
Why not just use the "guard" instead of an arbitrary gain value?:
sox -G -e float -b 32 -V4 -D rate -v 48000 norm -1
Maybe I should have just asked you to explain each and everything about your signature. ;)
Ok, I just realized I bumped an old thread.
Bumping an old topic. The resampler used by Opus works well for typical sample formats. I will describe a corner case.
I just found some old 8-bit 22050 Hz recordings that sound a little distorted when encoded with Opus. When upsampled with SoX to 48 kHz 16-bit or 24-bit, the resulting files encoded with Opus sound much better and there is much less audible distortion (just hiss as expected from the low bit depth). Playing the source FLAC files produces audible distortion depending on the resamplers at various points in the audio stack, so careful conversion through SoX produces a more pleasant and consistent reproduction across multiple playback systems. Interestingly, Opus files encoded directly from these FLAC files are slightly smaller than the source FLAC file, while Opus files encoded after upsampling with SoX are slightly larger.
I also tried upsampling with ffmpeg (lbswr) and Audacity, same results. There is audible distortion with opusenc whenever the source has 8-bit depth. If I convert my 8-bit 22050 Hz recordings to 16-bit 22050 Hz recordings using SoX, ffmpeg or Audacity, there is no audible distortion when I encode to Opus using opusenc.
Nevermind. I forgot to set the bitrate with opusenc, so it was using 32kbps for the 22050 Hz sources and 64kbps for the upsampled 48 kHz sources, which is a huge difference. Setting it at 48kbps or gives no artifacts for me. On the bright side, encoding with SoX does seem to reduce switching artifacts for the very low bitrate (32kbps) encode (my source was a recording with tonal and breathing content - a fiddle and a flute with long, sustained notes).
I've thought about this topic a lot actually. I fully understand the argument of artefacts being inaudible and most modern resampling techniques being transparent - although I don't know if I've seen ABX results either way.
I guess what I don't understand is that if there is a faster, measurably better (if not audibly better) resampler out there, why not use it?
Another question I have is this - those FFT graphs everyone uses to show resampling quality, aren't they only applicable to down sampling? Where as 99% of the time, OPUS will upsample form 44.1 to 48kHz?
I guess what I don't understand is that if there is a faster, measurably better (if not audibly better) resampler out there, why not use it?
SoX has a more restrictive license than libopus. If libopus had used the SoX resampler instead of the Speex resampler, some current users of libopus would have had to use a different codec implementation (and it's very likely that they would choose a different codec instead of implementing their own Opus encoder or decoder).
Another question I have is this - those FFT graphs everyone uses to show resampling quality, aren't they only applicable to down sampling? Where as 99% of the time, OPUS will upsample form 44.1 to 48kHz?
From what I understand, most resamplers work basically the same whether upsampling or downsampling. Graphs like these (https://src.infinitewave.ca/) show downsampling because you can get more information about the resampler's performance that way.
Thank you Octocontrabass, that clears it up for me
Also, technically, it's not libopus that does the resampling, but the encoder frontend that utilizes libopus. Technically, one could make a more restrictively licensed equivalent of opusenc that uses a different resampler. But again, more restrictive license.
The speex resampler, which is used by opus tools, is technically sufficient for the job anyway, and as you found, quality loss is more likely to be caused by reducing the bitrate than from using a particular resampler.
I should also note, all encoders which mostly fixed the gapless encoding issue, also make use of appropriate padding mechanisms, and work together with the built-in resampler, to minimize effects on the start and end samples of the input data.
The opusenc official encoder includes the encoding resampler's delay in its delay calculations, and pads the input data with a linear predictor, designed to guess what the sample data would be beyond the ends of the input, rather than padding with just silence, so that the ends will hopefully match up when decoded.
This mechanism is different from MP3 and AAC encoders which usually just pad with silence, because those also usually just pad the beginning by a whole "frame", which is usually sufficient to prime the encoder. I do not know if this would have been sufficient for Opus, but for Vorbis, the padding is possibly not to an even packet of input data, and it was probably found that padding with silence didn't yield sufficient results.
Thanks for the explanation Kode.
Interestingly (for some) I did a quick trial to see what the tangible difference were between using an external resampler (SSRC) and allow OPUS to do it's thing. I didn't listen to the files, because I think that would be futile however...
Both had the same bitrate, 130kpbs (I'd selected 128kbps), however the version resampled with SSRC was about 1kB smaller, and a single sample smaller. There was no difference in encode time on my 12 year old rig.
Even some of the "bad" resamplers seen on that one site (src.infinitewave.ca), you may note from the colors used for the graphs, that at least in a lot of them, the visible aliasing is well below -96 dBA. Accurate is quite important for editing and mastering, but it's probably acceptable to have inaudible aliasing when only applying the result for listening purposes, or encoding into a lossy format which is sure to have way more destruction on the audio quality than the resampler ever will.
Today I was preparing a lossless audiobook for lossy conversion and out of curiosity I tried something I don't usually do:
opusenc in.wav out.opus. You can clearly hear that the sound became sharper. But why, is it the internal resampler?
$ mediainfo penguin.flac
General
Complete name : penguin.flac
Format : FLAC
Format/Info : Free Lossless Audio Codec
File size : 55.5 KiB
Duration : 2 s 0 ms
Overall bit rate mode : Variable
Overall bit rate : 227 kb/s
Comment : Processed by SoX
Audio
Format : FLAC
Format/Info : Free Lossless Audio Codec
Duration : 2 s 0 ms
Bit rate mode : Variable
Bit rate : 227 kb/s
Channel(s) : 1 channel
Channel layout : M
Sampling rate : 32.0 kHz
Bit depth : 16 bits
Compression mode : Lossless
Stream size : 55.3 KiB (100%)
Writing library : libFLAC 1.4.3 (2023-06-23)
MD5 of the unencoded content : 8EF803F2F8C39B34A69197E56DA68EC3
$ mediainfo penguin.opus
General
Complete name : pengiun.opus
Format : Ogg
File size : 12.4 KiB
Duration : 2 s 7 ms
Overall bit rate : 50.8 kb/s
Writing application : opusenc from opus-tools 0.2-34-g98f3ddc
Audio
ID : 3623 (0xE27)
Format : Opus
Duration : 2 s 7 ms
Channel(s) : 1 channel
Channel layout : M
Sampling rate : 32.0 kHz
Compression mode : Lossy
Writing library : libopus 1.5.1, libopusenc 0.2.1-16-ge4285b5
$ opusenc in.wav out.opus
Encoding using libopus 1.5.1 (audio)
-----------------------------------------------------
Input: WAV, 32 kHz, 1 channel, mono
Output: Opus, 1 channel (1 uncoupled), mono
20ms packets, 49 kbit/s VBR
Preskip: 312
Encoding complete
-----------------------------------------------------
Encoded: 2.02 seconds
Runtime: 0 seconds
Wrote: 12734 bytes, 101 packets, 5 pages
Bitrate: 46.3802 kbit/s (without overhead)
Instant rates: 30 to 59.2 kbit/s
(75 to 148 bytes per packet)
Overhead: 8.03% (container+metadata)
I don't have the best hearing anymore but I don't notice any sharpness increase. Though the original has very sharp attacks at the beginning of the words. If there was something going on in the background the sudden impulse would effectively mask that for me.
Anyway, Speex resampler is transparent so it's very unlikely that it has caused any issues you may detect.
But if you wanted to prove everyone wrong, you could use for example SoX at best quality to resample the file to 48 kHz before encoding. If you can ABX the difference then it would prove the resampler isn't transparent.
What do you use to play the opus? Officially it is 48 kHz after encoding but some frontends will resample it back to original 32 kHz.
To have a fair comparison you should play them both at the same samplerate. I'd use 48 kHz, but you can also resample the opus output back to 32 kHz with known good resampler.
Today content is recorded at 48kHz, this way you get the best performance on the worst hardware. One reason is that the oscillator is an exact multiple of 48kHz, but that's not the only reason.
I'm going to sleep now, you'll ruin my sleep in the future :)
My tests with the latest version:
http://81.56.4.34:7438/share/Wl2GfBRRPQbFe8sp/