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: Opusenc's built-in resampler (Read 27379 times) previous topic - next topic
0 Members and 1 Guest are viewing this topic.

Re: Opusenc's built-in resampler

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



Re: Opusenc's built-in resampler

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

Re: Opusenc's built-in resampler

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

Re: Opusenc's built-in resampler

Reply #28
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!

Re: Opusenc's built-in resampler

Reply #29
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:


PS: I hope everbody laughed as much as I did! XD

Re: Opusenc's built-in resampler

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

Re: Opusenc's built-in resampler

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

Re: Opusenc's built-in resampler

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

Re: Opusenc's built-in resampler

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

Re: Opusenc's built-in resampler

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

Re: Opusenc's built-in resampler

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

Re: Opusenc's built-in resampler

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

Re: Opusenc's built-in resampler

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

Re: Opusenc's built-in resampler

Reply #38
I think if your definition of audio quality does not relate to audibility then it is not a useful thing to quantize. 

Re: Opusenc's built-in resampler

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

Re: Opusenc's built-in resampler

Reply #40
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. :)

Re: Opusenc's built-in resampler

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

 

Re: Opusenc's built-in resampler

Reply #42
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.
sox -e float -b 32 -V4 -D gain -3 rate -v 48000 norm -1
opusenc --bitrate 128

Re: Opusenc's built-in resampler

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

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.  ;)

Re: Opusenc's built-in resampler

Reply #44
Ok, I just realized I bumped an old thread.

Re: Opusenc's built-in resampler

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

Re: Opusenc's built-in resampler

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

Re: Opusenc's built-in resampler

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

Re: Opusenc's built-in resampler

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

Re: Opusenc's built-in resampler

Reply #49
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 show downsampling because you can get more information about the resampler's performance that way.