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

[Tale]

Quick question though! I assume it has not been tested in Xcode or it would have been mentioned? Any problems I should be aware of when using with Xcode ?

I use it with Xcode (I think I did mention it a long time ago), and it works just fine.

[Plisken]

Quick question though! I assume it has not been tested in Xcode or it would have been mentioned? Any problems I should be aware of when using with Xcode ?

I use it with Xcode (I think I did mention it a long time ago), and it works just fine.

oh cool! thanks !

[sagamusix]

OpenMPT's sample editor now uses r8brain-free for resampling to arbitrary sample rates. Feel free to add it to your list of programs that use r8brain.

[Kazrog]

Just wanted to chime in and say thank you for this wonderful library! Incredibly easy to use, and the results are amazing!

[Aleksey Vaneev]

Moved the repository to https://github.com/avaneev/r8brain-free-src due to future Google Code closure.

[Quba]

Thank you Aleksey for this nice library!

I try to use it for real-time resampling from 200Hz to 128Hz, with the smallest delay possible between input data and output resampled data. To reach real-time, I have to sacrifice the quality of processing. So, I can not use CDSPResampler24, CDSPResampler16 and CDSPResampler16IR classes which generate excellent results but a "long" delay.

In my code, I have implemented the following resampler:

Code: Select all

iInputSamplingRate = 200;
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);

But, there is still a delay. What supplementary changes can I do to shortcut this delay?

Thank you! Quba

[tico-tico]

Aleksey, do you have any processed samples for testing? I mean I just made simple command line proggie for my home needs, and I'm not sure if it works correctly. If you could share some of your processed samples to compare results it would be cool. If it matters, i'm using the default params for CDSPResampler24 and libsndfile for loading/saving files.

Thanks.

[Aleksey Vaneev]

I try to use it for real-time resampling from 200Hz to 128Hz, with the smallest delay possible between input data and output resampled data.

But, there is still a delay. What supplementary changes can I do to shortcut this delay?

Sorry to tell it, but you've already used the lowest possible quality setting, so reducing delay further is not possible. Library always provides the lowest delay possible for the given quality parameters. I suggest you to try some alternative libraries. If 49 dB stop-band attenuation is OK for your needs, I would simply use a 6th order spline resampling with some preliminary low-pass filtering.

I will consider implementing a "brute force" low-pass filtering in a future update. For short filters it may further reduce the processing latency.

[Aleksey Vaneev]

Aleksey, do you have any processed samples for testing? I mean I just made simple command line proggie for my home needs, and I'm not sure if it works correctly. If you could share some of your processed samples to compare results it would be cool.

Thanks for the idea, I'll include some 24-bit input and output files for benchmark purposes in a future update.

[dekadenz]

It will have an extra user as soon as I'll release next build (it have, just not public in fact).

Know it wasn't designed for realtime oversampling, but this "no compromise mathematical" approach fits my compressor fine. I'd rather have perfect oversampling with latency than CPU-friendly one without that adds artifacts on its own.

By the way, I considering making Reaper file format plugin with it in order to use it instead of built-in resampling that much slower and not clean at all.

[Tale]

By the way, I considering making Reaper file format plugin with it in order to use it instead of built-in resampling that much slower and not clean at all.

Actually REAPER's resampling is pretty good (IMHO), provided that you select a decent resample mode (192pt Sinc, maybe longer), but r8brain generally is faster (in my experience, YMMV).

[Xenakios]

not clean at all.

Clean for what? Looking at analysis pictures made at some unreasonable settings with unreasonable input signals? Have you done blind listening tests?

[dekadenz]

Are you always calling everyone who did not like something in Reaper on blind tests? For first, if artifacts are in theoretical hearing range and if it can be improved, it worth doing even if 90% (devs included) cannot tell the difference.

Answering you question, yes, in fact.
Resampling with integer ratios is acceptable. At least I haven't noticed anything and wasn't able to tell which is which on "best". Yet r8brain on integer ratios is times faster, which can be useful for the users working at high sample rates.

Non-integer ratios, like 48->44.1 aren't very good even on "best" settings and weren't transparent in ABX tests (with foobar2000 plugin) for me. HF tends to become messy and "digital".

To Aleksey:
By the way, released the build with oversampling in public: http://www.kvraudio.com/forum/viewtopic ... 6&t=438580
It would be great to be included in the official list. Is that enough or some sort of release version is needed?

[Quba]

Hello,

getInLenBeforeOutStart(0) gives the number of input samples that have to be passed in the resampler object before the first output sample starts. So, it gives the delay induces by the resampling process, a nice information!

However, I have made a basic program to test it, and I have found differences.
I feed the resampler with input samples one by one, and at each time, I look to the output: I note the real number of input samples required to obtain the first output sample.

With the following resampler:

Code: Select all

iInputSamplingRate = 512;
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);

getInLenBeforeOutStart(0) returns 143 input samples, but in fact, I have observed 173 input samples necessary to obtain the first output.

Moreover, getInLenBeforeOutStart(1) returns 145 (so, 143+2), whereas I have observed 177 (so, 173+4) input samples necessary to obtain the second output.

Consequently, it seems that the initial point (143 vs 173) and the slope (+2 vs +4) of this delay estimation function do not correspond to the real outputs.

I have changed parameters of the resampler, there are differences too.

Can you help me to understand this point?

Thanks, Quba

[Aleksey Vaneev]

getInLenBeforeOutStart(0) returns 143 input samples, but in fact, I have observed 173 input samples necessary to obtain the first output.

Moreover, getInLenBeforeOutStart(1) returns 145 (so, 143+2), whereas I have observed 177 (so, 173+4) input samples necessary to obtain the second output.

Consequently, it seems that the initial point (143 vs 173) and the slope (+2 vs +4) of this delay estimation function do not correspond to the real outputs.

I have changed parameters of the resampler, there are differences too.

Can you help me to understand this point?

Thanks, Quba

Thanks for reporting this issue. But I will have to study it, I can't tell right now what is wrong.