Re: [Audacity-devel] SoX resampling
A free multi-track audio editor and recorder
Brought to you by:
aosiniao
From: Rob S. <aq...@ya...> - 2012-12-11 22:42:27
|
----- Original Message ----- > From: Martyn Shaw <mar...@gm...> > To: aud...@li... > FWIW I still had to remove the USED bit in line 34 of internal.h; it > appears to be undefined in my environment (only for __GNUC__?). Hmm, this is a bug that I had thought only affected debug builds on windows, but anyway a fix is now available in git: git clone git://git.code.sf.net/p/soxr/code libsoxr (hope folks are familiar with git; I expect some of the other libraries probably use it too). > Rob, you seem to imply that libsoxr > could do a better job if it were called better from Audacity. Yes (libsamplerate too, but from what I've seen, to a lesser extent). > Would that be a lot of work? I guess it would mean a change in > MixVariableRates to pass an array of 'factor' to > VarRateResample::Process, instead of a single value? A very simple way to do it is for the client (audacity) to use a block-size of 1, this allows the most smoothly changing rate with minimum artefacts. The only problem is that this becomes inefficient, so the next best thing is to have a block size of > 1 (and possibly inversely proportional to the rate of change of sample-rate) and have the resampler interpolate between the rates at points between each block (as it is better placed to do this speedily). This is complicated by the fact that resamplers have delay (what you get out is not related to what you put in now, but what you put in some time previously) and that the delay can vary with sample-rate and also because of block-convolution. Keeping track of all this can be tricky and I'm not sure at this point if it's worth the effort. However the work Maarten is doing might have some effect on all this, so my feeling at the moment is to let that progress a little further before deciding where to go next. Cheers, Rob |