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

[Aleksey Vaneev]

Well, I need some input from the users of this library, or I'll assume the library is more-or-less complete, I will be moving my focus to other things I do.

[Tale]

Well, I use r8brain to resample IRs on the fly, which it seems to do perfectly, so I guess in that respect it is complete (complete enough to include it in a production release).

I have some experimental code using r8brain as an anti-alias filter for a 2x oversampled waveshaper (because others asked me if it could be used for that). It works well (it is both fast and of good quality), but of course it adds latency (704 samples I believe). Then again, it might be overkill to use r8brain for something like that, I dunno.
EDIT: See http://forum.cockos.com/showthread.php?t=127860.

[Aleksey Vaneev]

No, that's not overkill, I myself use linear-phase oversampling in Voxengo plug-ins that is close to that latency number and quality. You can reduce latency by using a lower ReqAtten and higher ReqTransBand values, it's flexible.

[very angry mobster]

I've added DLL support, can be downloaded at project's home page.

I was away camping over the weekend so I've only just seen this. Thanks for adding DLL support, you work quickly!! Downloading now...

Thanks,
Shannon

[reakinator]

AUTO-ADMIN: Non-MP3, WAV, OGG, SoundCloud, YouTube, Vimeo, Twitter and Facebook links in this post have been protected automatically. Once the member reaches 5 posts the links will function as normal.

Hello Aleksey,

I recently came across r8brain-free-src and I have to say, it was direly needed in the open source world. Thank you! I work on the cinder (http://www.libcinder.org) creative coding framework and we're whole heartedly considering using r8brain (with attribution, of course) in the next release of our audio api, as we try to stay away from gpl/lgpl licenced code and also r8brain looks to be of very good quality.

Some feedback:

The detailed comments are very much appreciated, even down to choices in private variables. This made getting up and running much easier.

I do most of my dev'ing using clang on OS X, and I think I hit a compile error that isn't an issue in your dev environment. I had to change the template arguments to FilterBank on CDSPFractInterpolator.h, line 503 from:

Code: Select all (#)

CDSPFracDelayFilterBank< FilterLen, FilterFracs, FilterElementSize, 8 > FilterBank;

to:

Code: Select all (#)

CDSPFracDelayFilterBank< FilterLen, FilterFracs, 3, 8 > FilterBank;

as clang was complaining that there was a redefinition of a different type on line 513. Full error diagnostic is:

Code: Select all (#)

/Users/r/code/cinder/audio-rewrite/audio2/src/r8brain/CDSPFracInterpolator.h:513:64: error: redefinition of 'FilterBank' with a different type: 'const CDSPFracDelayFilterBank<FilterLen, FilterFracs, 3, [...]>' vs 'const CDSPFracDelayFilterBank<FilterLen, FilterFracs, FilterElementSize, [...]>'
        CDSPFracInterpolator< FilterLen, FilterFracs, BufLenBits > :: FilterBank;
                                                                      ^
/Users/r/code/cinder/audio-rewrite/audio2/src/r8brain/CDSPFracInterpolator.h:504:26: note: previous definition is here
                FilterElementSize, 8 > FilterBank; ///< Filter bank object.

I also saw that many of the assertions are out of date and are producing false positives (enabling assert() causes a compile error in CDSPFractInterpolator::process()). It would be nice to take advantage of the assurance that all params are being passed as expected / required, since if one gets them wrong without assertions, it can lead to bad memory access (I did!).


Side note: would you consider enabling the issue tracker on google code? It would be a convenient place to check progress and also inform you of issues if I/others come across any others. I completely understand if this is against your wishes or not within your time constraints - still very much appreciated to use your work.


As the above stumbles were very minor, I'm currently happily converting away without issue, and I look forward to more use across our other platforms. Thank you again Aleksey!

cheers,
Richard Eakin

[Aleksey Vaneev]

Thanks, I'll fix the asserts - they are indeed out of date.

That "error: redefinition" is clang's bug for sure as there is no redefinition happens, FilterElementSize=3. But I'll add a workaround.

I do not want to add an issue tracker since this is not a feature-expansive project, this forum is enough.

[reakinator]

Great, much appreciated. I've already updated and can confirm that clang is happy with your workaround. I'm using v1.4 without modification.

cheers,
Rich

[very angry mobster]

I'm testing the DLL in a delphi application.

Code: Select all

var
  rsHandle : CR8BResampler;
  Latency : LongInt;
begin
  rsHandle := r8b_create(44100, 88200, 1024, 4, r8brr16);
  Latency := r8b_get_latency(rsHandle);
  r8b_delete(rsHandle);
end.

With the above code r8brain is reporting 269141892 samples latency. Is that an expected value?



Shannon

[Aleksey Vaneev]

Thanks for catching that issue! I've reuploaded the fixed DLL v1.4.

[very angry mobster]

Thanks Aleksey. Giving it a go now.

Is it ok to call r8b_create() with samplerate ratios instead of the actual source and destination samplerate? ie:

Code: Select all

  SourceSampleRate := 1;
  DestSampleRate   := 2;
  r8b_create(SourceSampleRate, DestSampleRate, MaxInLen, TransBand, r8brr16); 

[very angry mobster]

I'm testing the 1.4 DLL. r8b_process() returns silence. It could be my fault but I can't see any problems when reading over my code and everything looks ok when stepping through in the debugger.

Here is the test program I'm using.
- My sample data is an array of single. The program copies the data into a temporary array of double for processing.
- The program calculates the samplerate conversion ratios based on the length of the input buffer and the output buffer.
- The program disregards the resampler latency.

https://gist.github.com/anonymous/6911293

The reported latency is 748 samples.

The rb8 resampler processes 552 samples on the first loop and 2048 samples on subsequent loops. 2048 seems correct so I can only assume 552 is also.

[Aleksey Vaneev]

very angry mobster, you are probaby doing something wrong. I've checked the DLL, it works correctly with the code like that in "example.cpp".

You do not need the "TempDestBuffer" buffer as destination buffers are handled by the resampler. This is the source of error. You should copy data from PDestBuffer returned by r8b_process().

Probably I've misdescribed something. Let me know how I can reformulate the r8b_process() function's description so nobody does a similar mistake.

I've added the following clarification: "You do not need to allocate an intermediate output buffer for use with this function. If required, the resampler will allocate a suitable intermediate output buffer itself."

[Aleksey Vaneev]

I also suggest you to check the DestBuffer position for possible overflow. This is done in the "example.cpp".

If the data from the output buffer "op0" is going to be written to a bigger output buffer, it is suggested to check the returned number of samples so that no overflow of the bigger output buffer happens.

[Aleksey Vaneev]

Is it ok to call r8b_create() with samplerate ratios instead of the actual source and destination samplerate? ie:

Code: Select all

  SourceSampleRate := 1;
  DestSampleRate   := 2;
  r8b_create(SourceSampleRate, DestSampleRate, MaxInLen, TransBand, r8brr16); 

Yes, this is OK.

[very angry mobster]

You do not need the "TempDestBuffer" buffer as destination buffers are handled by the resampler. This is the source of error. You should copy data from PDestBuffer returned by r8b_process().

That's the mistake. I didn't read the documentation closely enough. Thanks Aleksey. It's working perfectly now.


Shannon