Open source high-quality pro audio sample rate converter library released from Voxengo

DSP, Plugin and Host development discussion.
Post Reply New Topic
RELATED
PRODUCTS

Post

Ok, thank you for your help! I look forward to knowing the solution.

Quba

Post

Does this library also perform pitch shifting (playback rate style)?

I.e. lowering the sample rate does also lower the pitch, increasing the sample rate does also increase the pitch?

Or is this an option?

Post

Fluky wrote:Does this library also perform pitch shifting (playback rate style)?

I.e. lowering the sample rate does also lower the pitch, increasing the sample rate does also increase the pitch?

Or is this an option?
Like any sample rate converter, r8brain-free-src can be used for pitch-shifting. But this is not the kind of pitch-shifting that retains timing nor formants.
Image

Post

Hello and marry christmas,

I'm trying to compile this code on OSX but I get some compiler errors.
r8brain-free-src-master 4/DLL/r8bsrc.h:64: error: expected initializer before 'r8b_create'
r8brain-free-src-master 4/DLL/r8bsrc.cpp:72: error: expected `}' at end of input

Can someone help me?

Thanks

Post

Ram242 wrote:Hello and marry christmas,

I'm trying to compile this code on OSX but I get some compiler errors.
r8brain-free-src-master 4/DLL/r8bsrc.h:64: error: expected initializer before 'r8b_create'
r8brain-free-src-master 4/DLL/r8bsrc.cpp:72: error: expected `}' at end of input

Can someone help me?

Thanks
You should not compile that code, it is an internal code for building DLLs. Please use classes of CDSPResampler.h exclusively, especially on OS X.
Image

Post

Dear Aleksey,

for a sampling rate conversion from 250Hz to 128Hz, I have observed an artefactual wave in the resampled data. Spectrum of the data shows a peak around 7Hz.

Interestingly, if I apply a 1st order high-pass filter (cut-off frequency defined as 0.5Hz) before the resampling, very low-frequencies are suppressed and there is no more artifact in the resampled data.

Other conversions are concerned by this problem. For a conversion from 250Hz to:
- 129Hz, peak is around 8.5Hz,
- 130Hz, peak is around 10Hz,
- 125Hz, there is no peak.
Obviously, only the the ratio 250/125 is well-conditioned.

1. Do you know the origin of these artifacts? It seems related to very low-frequencies, and badly-conditioned ratio.
2. Do you know how fix it?

My resampler is:

Code: Select all

iInputSamplingRate = 250;
iOutputSamplingRate = 128;
iMaxInputSampleCount = 1024;
dTransitionBandInPercent = 45;
dStopBandAttenuation = 49;

r8b::CDSPProcessor* MyResampler = new r8b::CDSPResampler< r8b::CDSPFracInterpolator< 6, 11 > >(iInputSamplingRate, iOutputSamplingRate, iMaxInputSampleCount, dTransitionBandInPercent, dStopBandAttenuation, r8b::EDSPFilterPhaseResponse(0), false);
Thanks, Quba

Post

r8b::CDSPFracInterpolator< 6, 11 > is definitely too "short". This may be the source of artifact.
Image

Post

Hello Aleksey and thanks for your fantastic sampling rate converter!

I'm starting to write an open source software audio DSP to run on a Raspberry Pi with multiple i/o like SPDIF & multi-channel analog input (ALSA), HDMI (OpenMax) & SPDIF & analog output (ALSA).
An asynchronous sampling rate converter is at the center of everything in order to keep inputs and outputs in sync.

The quality and speed (especially on Pi 3) of r8brain-free-src are very impressive.

CDSPFracInterpolator has setDstSampleRate(double NewDstSampleRate), but is it still possible to use it now that getInterpolator() was removed from CDSPResampler?

Would you have some instructions on how to vary the output sample rate?
Also, when making the change dynamically, is it expected to get some clicks? In a previous message, it was suggested to use a fading approach.

Post

An update on variable resampling.

By re-adding setDstSampleRate and after running some tests: altering the sampling rate by small amounts introduces no click at all, it'll be perfect as-is for my use case.
Awesome!

Post

supercurio, r8brain-free-src wasn't really designed for real-time sample rate adjustments in plans. The problem with real-time adjustments is that resampling filters have to be redesigned, simply changing the destination sample rate won't work acceptably - setDstSampleRate() only changes interpolator rate, it does not change the filters. So, clicks are inevitable if you do it the "right" way.
Image

Post

Thanks Aleksey for your reply!

Here's what I'd like to do:
  • Detect input sample rate (on SPDIF input) and re-create a CDSPResampler each time a change occurs. The sample rate on analog input will be fixed.
  • Supported sample rates: input 44.1 and 48 kHz, output 96 kHz
  • Every 10 second or so, measure the input sample rate against the output sample rate and adjust the output sample rate slightly to keep both in sync.
I don't know yet by how much the sample rate would need to be adjusted in real world scenario with the diversity of audio devices out here.
But let's say the sample rate ends up being adjusted dynamically with setDstSampleRate() from 95950 to 96050, is compatible with r8brain-free-src's design?

Likewise, with a transition band of 5%, would it be okay to resample a 48000 Hz input from 47970 to 48030 with setDstSampleRate() in case 96 kHz is not available as output sample rate?

Post

supercurio wrote:Likewise, with a transition band of 5%, would it be okay to resample a 48000 Hz input from 47970 to 48030 with setDstSampleRate() in case 96 kHz is not available as output sample rate?
Technically speaking, it won't be OK anyway. If setDstSampleRate() differs even a little from the constructed destination sample rate, there still will be small unoptimality.
Image

Post

Ah shoot, understood.

I'll try to measure it then, and compare with libsoxr variable rate converter performance in the same scenario.

In order to still use r8brain-free-src optimally, a brand new instance of CDSPResampler would be required?

I wonder how the transition from the previous one to another could be done best, since depending on the filter parameters a variable amount of input samples must be fed into the filter to start getting an output.
Then at which point exactly it is best to transition from one CDSPResampler to another to avoid clicks or echos.

Would you think of a way to rework setDstSampleRate() to provide optimal output without a brand new CDSPResampler?

Post

Another question: would the small unoptimality last only getInLenBeforeOutStart() duration or forever?

I thought about a way to transition to a new instance of CDSPResampler otherwise:
  • setDstSampleRate(newSampleRate) on CDSPResampler #1
  • instantiate a CDSPResampler(newSampleRate) #2
  • feed input to both CDSPResampler #1 and #2
  • once CDSPResampler #2 starts outputting, set the output to CDSPResampler #2 and destroy CDSPResampler #1
Would that be the best way to operate (only negative, a temporary CPU usage spike each time)

Post

I just completed measurements, with a 32-bit floating point Test Sample from RMAA 6.4.1 at 44100 resampled to 96000, then back to 44100 with r8brain-free-src at highest settings.

The range of final output rate was from 95900 to 96100 (a step every 10 Hz) set by setDstSampleRate() after CDSPResampler's was initialized at 96000 kHz output.
Despite the small unoptimality as you mentioned Aleksey, RMAA was unable to calculate or display a difference on each metric - beside the 2% transition frequency band :)

In order to get a valid output at 96100 Hz and a few others, I doubled CDSPResampler's MaxOutLen value as a quick hack.
The advice provided here https://github.com/avaneev/r8brain-free ... tor.h#L275 is great, to initialize the object with its maximum expected destination sample rate and adjust lower when needed.

I understand why you removed getInterpolator() since it's possible to break things at runtime by changing the destination sample rate, but wow if used carefully and despite the unoptimality, the result is so good!

Also I noticed that when trimming down to up to 32-bit PCM test files going through 44100->96000 (CDSPResampler initialized at variable rates)->44100, the end output for all are binary identical.
32-bit floating point output has the required precision to represent a differences; the unoptimality for this use case is so small that the 24-bit PCM data sent to the sound card will be the same by a large margin :) - at least with high quality src settings

Congrats for what you archived with r8brain-free-src Aleksey, the result is incredible.

Post Reply

Return to “DSP and Plugin Development”