Have you tried using AudioSnap's clips follow project feature?

http://youtu.be/weIZy_ibH5c

You will need to bounce the clips to sound good.

+1 on Audio Snap.  I used the Clips Follow Project recently to stretch as needed to smooth out an imported guitar track.  It had slight variations - very slight, but I wanted them gone, so I set it to follow the tempo and it did what it had to do, and sounded fine at the end of it.
 
AND, there was NO MATH involved - yay! :)
 
Bob Bone
 

Thank you all for the responses.  I will try them out now and report back with the findings.
 
I SWEAR I tried 94.44% since I thought it was AS EASY as dividing the old tempo by the new, but my guitars starting drifting away from the beat (getting a little ahead of it the further along they got...).
 
I am going to investigate now with a fresh pot of coffee and your aforementioned pearls of wisdom.
 
And I can still make it on time to my SAT later today!!!  Ha
Thanks again!
Rizzo

Hmmm if I got that on a maths paper with your exact phrase - how many percent faster, I would calculate as 100x(90-85)/85... Which I guess from your calc above is 5.88% (too lazy to do the calc!)  That is, in percentage times, how much faster it is relative to the original speed, but it's going at 105.88% of the original speed.

OK gang.....here are my findings based on absolutely NO scientific research.
 
What I BELIEVE is happening with T/PS 2 is that the % value is being rounded to the NEAREST %. 
 
The reason I believe this is:
1) Despite the assurances and sound mathematical algorithms from previous posters, when I enter in a % of 94.444444444444, the guitars still drift ahead of the beat the further the song plays.
2) When I called up my saved preset so I wouldn't have to type in that crazy decimal over and over, it simply showed 94% in the window (no decimal).
 
So...again...this seems to jive both with what I'm hearing...and seeing...in the % window.  Anyone concur that this may be the case?


Time for me to learn a little more about Audio Snap, I guess...  =)

If it is rounding then that's inexcusable! You need accuracy of at least 2 or 3 places to lengthen of shorten audio, and probably more if it's a very long piece. Sounds like some careless programmer used an int instead of a float and the thing was never tested properly.

I'm a programmer - I didn't mean to do it - honest!  :)
 
That would be bad news indeed, if it is actually careless coding.
 
As I mentioned above, I just use Audio Snap, and it seems like all is well when I stretch/shrink using that approach, as far as I know.  Perhaps you could give that a try and see if it accomplishes what you need for that piece of things.
 
Bob Bone

sharke
 Sounds like some careless programmer used an int instead of a float and the thing was never tested properly.

Really? Do you know how the feature was specified, what the test plan was and the test results? I know you are aware of the feature request form..

Let's not go there.  There is a possibility that an anomaly exists in the code, and the poster offered it as speculation, not an assertion.
 
I happen to agree that it is possible that there is a math issue with it - although I do not have any confirmation on that, hence my agreeing on a possibility.
 
Bob Bone

Sure it is possible but it does not rise to the level of insulting the programing/testing staff. It may be how the feature was originally specified and the tool was not intended for the application being discussed. That is why I mentioned the feature request form. Audiosnap may be the more appropriate tool in this case.