Re: [Rosegarden-user] Rosegarden's sample rate conversions aren't quite correct.

[Chris C. <chr...@fe...>]

On Tuesday 13 Dec 2005 22:50, Richard Cooper wrote:
> I think what's happening is that it's actually calculating the
> correct offset to begin playing at, but that the sample rate
> converter isn't converting to the correct rate, it's as if it's
> converting to 48230 instead of converting to 48000.

You're right -- looking at the code, it's a fairly obvious accumulation 
of rounding error when reading blocks of data from the audio file.  We 
need to get an integral number of frames at rate A, and to do that we 
read an integral number at rate B and convert them -- the difference 
between the correct (non-integral) number of source frames and the 
actual number read is disregarded, so the file always plays a little 
slow (by an unpredictable amount depending on the buffer fill rate, 
which depends on all sorts of other things but is likely to be more or 
less constant throughout a given session).  This also contributes to 
the lousy sound of the conversion of course.

We've always played extremely fast and loose with sample rate 
conversion, working on the principle that we don't want people relying 
on it anyway.  It's not even always been a certainty that we should be 
doing it at all (instead of playing at the wrong rate).  But, since we 
do, maybe we ought to take the time to switch over to libsamplerate and 
do it properly.

> I ran the WAV file through a program that I made that cuts the tempo
> in half while preserving the pitch, so it doesn't sound all that
> great to begin with anyway.  It does sound way better than sox
> attempting to do the same thing with it's 'stretch' command, but not
> nearly good enough for a bad sample rate conversion to be noticable.
>
> (And having mentioned that little thing, I suppose I should put it
> for download...  Ok, here it is:
> http://pj.nfshost.com/secret/nonsense/flimsy  It's just a linux elf
> executable, you give it raw signed 16-bit stereo @ 44100 on it's
> stdin, and it spits out the same on it's stdout.

Not bad -- better than sox, as you say.  I'd characterise that as quite 
a bit grainier but a bit less tin-canny than SoundTouch 
(http://sky.prohosting.com/oparviai/soundtouch/) and perhaps a bit 
better at preserving perceived pitch.

I actually have a requirement for something like this for use in another 
(hopefully) forthcoming free-software project.  I had hoped to use 
SoundTouch, but I need a library that has a known fixed latency -- so 
that I can know exactly which sample of the original file is being 
played at any given moment, in its time-stretched version, as far as 
that is meaningful.   SoundTouch doesn't seem to have that property, 
although I haven't looked very closely at it.

So, I'd certainly be interested in looking at code for anything similar.


Chris