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 23228 times) previous topic - next topic
0 Members and 1 Guest are viewing this topic.

Re: Opusenc's built-in resampler

Reply #50 –
Thank you Octocontrabass, that clears it up for me

Re: Opusenc's built-in resampler

Reply #51 –
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.

Re: Opusenc's built-in resampler

Reply #52 –
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.

Re: Opusenc's built-in resampler

Reply #53 –
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.