[SideQuark]

It’s not that cynical. The author didn’t test on the most common rate in use, so it would be ludicrous for any serious project to wholesale replace a decades old working pipeline with it. It makes perfect sense to wait till due diligence is done.

[ant6n]

It's not cynical. It's dismissive. Especially given that these codecs work in the frequency domain anyway.

>>...use 48Khz if you want the best quality.

>Yet most of the worlds audio is 44KHz...

[SideQuark]

I take it you don't know much about frequency time tradeoffs.

It is not possible to convert 48 khz to 44 khz without approximation. And there is incredible room to design filters that have great response at frequency X but terrible at a nearby frequency, since most of filter design is about where to stash the noise. That noise can add perceptible beats to audio.

And don't try some silly Nyquist limit stuff - none of that is actually correct in actual filtering. The initial simple reasons are that that stuff assumes infinitely precise, mathematically perfect sample values - impossible since these are PCM. They assume infinitely periodic inputs, also false (and there's an entire industry of trying to find window functions to smooth lack of periodicity, also with flaws and tradeoffs). For perfect reconstruction, they use sinc, which has infinite support, which is not computable. So people think they'll use some windowed sinc, which again then fails to do reconstruction fully.

After these ancient, and in practice lacking, ideas, modern filter theory and practice has invented generalized sampling, which has provably (from math and in practice) better signal reconstruction. And even that is only the tip of an iceberg of knowledge.

These codes don't simply "work in the frequency" domain as if this is old school DFT stuff. Even in that domain, your claims don't work. These codecs also do psycho-acoustic modeling, to be able to decide which data to drop, alter, increase, or decrease, to get following bitratres to encode at target. Again, these type of filters and models can be terrible at 44, but awesome at 48.

So yes, they do need to test before putting this into the world's most used by far audio/video transcoder.

So yes, is is cynical, apparently driven by ignorance.

[orev]

If the original source is 44.1KHz, and this codec prefers 48KHz, is there an issue up-sampling to 48KHz before doing the AAC encode?

I think that's really the question with this work: up-sampling to 48k, not down-sampling to 44.1k.

[SideQuark]

Yes, there is always an issue upsampling since you have to make up new values. For downsampling by an integral factor, you have honest samples at those times, but any other rate will also need new samples to be constructed. So for these, in either direction, there will be the need to make things up.

No matter the process, whether naive fourier transform based, or any possible algorithm that is smarter and tries more things, it cannot make up the true values in all cases, since that data is simply not in the signal.

Ancient methods treated sound as a sum of band limited pure sinewaves, which it is not, and you can claim you reconstructed up to that model, but it's pretty bad, and fails even theoretically for the reasons I posted elsewhere.

So you then start doing all sorts of signal processing, but none can actually reproduce all sounds, and most (all?) methods make tradeoffs - what error do you accept for what gains?

And if you optimize a system for one rate, and don't do it to cover all other sample rates you want to handle well, then you will make some rates worse and some better.

Well designed signal processing has to be careful to handle all the ranges it cares about.

And no one who knows or has worked in these areas would simply drop in a new system that is untested for major uses for such a widespread tool as ffmpeg. Precisely because they understand the nuances in these things.

[ant6n]

Opus also does everything in “48KHz”. But apparently doing some upsampling will implode the whole signal… more so than the compression itself… which indeed is actually processing and storing data in the frequency domain (MDCT).