SoundTouch doesn't do framerate conversion correctly

[Boulder]

I discovered today that SoundTouch doesn't do proper framerate conversion. I did a little test with a 2-hour silent WAV file, doing a conversion from 23.976fps to 25fps. Here are the results:

Original 2:00:00.000
SoundTouch 1:55:04.112 [-soundtouch( -r 23976 25000 )]
BeSweet internal 1:55:05.070 [-ota( -r 23976 25000 )]
Adobe Audition 1:55:05.080 (resampling option, 95.904 as the ratio)

The one converted with SoundTouch is almost a second off which means that the a/v off-sync will be noticable quite early in the clip.

Does anyone else have any similar results?

[Bogalvator]

Did you make the smae mistake as Bond did in this thread?:
http://forum.doom9.org/showthread.php?s=&threadid=76376
(about 2/3 of the way down the page)

I think SoundTouch is usually quite accurate, so it would surprise me if this was true.

[Boulder]

Hmm, that's very much possible. However, the docs state that the -r switch can be used to do a framerate conversion.

From http://dspguru.doom9.org/cli.html :

example : "-r 25000 29970" will convert a 25.000fps stream (PAL) to a 29.970fps stream (NTSC)

I played with ST some and found out that -rate works, using -soundtouch( -rate 4.2709376 ) produces a correct length. Using -tempo doesn't work although it should work just as -rate.

[Bogalvator]

Have you tried the commandline app?
http://sky.prohosting.com/oparviai/soundtouch/#download

[Boulder]

I tried the CLI app (SoundStretch), and -tempo produces similar results to the one in the DLL, incorrect length when sped up by 4.27094%. Using the -rate switch gives a correct length. Shouldn't these two modes give exactly the same length?

It looks like BeSweet calculates the percentage incorrectly as there is no -r switch in the commandline app.