Where is my math going wrong???

OK...I've read and read and READ about Time/Pitch Stretch 2 calculations and STILL cannot figure out the correct % to use in my particular project.  My co-writer upon hearing a rough mix of the first verse/chorus - "man...it feels slow...can you speed it up?"  Loop constructor and groove clips sound pretty crappy for my acoustic/electric parts and I've gotten good results from T/PS 2 before when "needing to know the %" was not an issue...i.e. final mix "speed ups".  I have about 40 tracks of MIDI (no prob!) and 15 or so audio tracks that need to be sped up.
 
I am "simply" (ha) trying to change the tempo of those already-recorded audio tracks from an original bpm of 85 to a new bpm of 90.
 
So...the question is....how many percent faster is a song @ 90bpm than in 85bpm???  I won't even tell you some of the % I've used, for fear of sounding even more DUMMMMMMMM than I currently do.  The only thing I know for sure at this point is it's less than 100%... 
 
Help a fellow musician who feels like he's cramming for the SATs????  Please?????  Do I need to use the Pythagorean Formula or something?  Calculus????????
Rizzo

Yep.  I got that a while ago, but that's not the % I would enter since a time value of over 100% is LONGER than the original time length.
 
I also tried putting in 94.12% by subtracting the 5.88% difference from 100%.  It was too quick.
 
But that was before my mind was a Bill Cosby favorite flavor of Jello Pudding...  :-/
 
 

I tried that too.  Negative.

If you want more clarification that this is correct, try this little tool to calculate loop lengths from bpm:
 
http://nickleus.com/calculate_loop_length.htm
 
Enter 85bpm and 1 measure. Write down the answer. 
Enter 90bpm and 1 measure. Write down the answer. 
 
Divide the second answer by the first. You'll also get 0.944. If 94.44% isn't working then there must be some other factor that's amiss. 

Think of it this way. At 85 BP the time per beat is 60/85 which is 0.705882 secs and the time for a bar of 4/4 time is 4 x that which is 2.823529 secs/bar. Say the music is 64 bars. 64 x 2.823529 = 180.705 secs. (close to 3 minutes) Just out of interest how many bars is your tune?
 
Now do the calcs with 90 BMP instead. Time per beat is now 0.6666 secs /beat or 2.6666 secs /bar. So the same 64 bars will now be 64 x 2.6666 and that is 170.666 secs.
 
Now if you divide 170.6666/180.705 you get 0.944448687.
So both Sharke and myself are correct. You are doing something else wrong.
 
All you have to do in Studio One is change the tempo from 85 to 90. Pretty easy! Everything will play out now at 90 instead of 85 and everything will remain on pitch too. Why can't every DAW in the world do that!
 
But I still think even that is not the way to go. You are time stretch or shrinking when you do this and some serious calculations are going on. You have to spend some quality time with the metronome before you even start. If you had you would have figured that 85 is too slow and 90 is just right. 90 is quite a bit faster too than 85 BPM. I assume you are now fiddling with your final mix. Good luck.
 
 
 

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.

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

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...  =)

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

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

I understand your point on the feature request form, as well.  
 
I guess it depends on the 'read' of the post.  I didn't take it as an insulting comment (and I've been married twice, so I think I have some credibility on being insulted - I am also a programmer).  I read that comment purely as a casual speculation on the possibility of what may have led to a coding issue, were there to in fact be one.  
 
There have been actual cases where multi-million dollar satellites have failed, because one set of the international team did things in American standards, and another set did things in metric.  They were quite bummed about it, since they discovered it when the satellite had already launched and become completely unusable.  And another satellite was lost when somebody forgot to tighten the bolts that secured the satellite to a mounting station, and the 3-foot drop destroyed it. There's even a bridge in Chicago where they started both sides to meet in the middle of the river, and they were a couple of FEET off, so the bridge didn't line up when the two sides met.  DOH!
 
I think a lot of folks in general are a bit bristly these days, as carryover from some pretty trashy/bashy posts of late, and I think anything we can collectively do to keep things supportive and positive is in our collective best interests.
 
I am not even sure Audio Snap will meet the original poster's needs - I just happened to have recently used it for a similar kind of thing, so I tossed it out there for something he could try.
 
We may be a mess, but we're family! :)
 
Bob Bone
 

Yupper Duppers.  LOTS of examples of 'C' students creating things in the world.  :)
 
Bob Bone
 

scook
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.

Are you sure you weren't the programmer in question scook? 
 
Programmers make careless mistakes quite frequently. It's hardly unreasonable to speculate that this may have been the case. Nor is it unreasonable, by extension, to speculate about what may or may not have been in the specifications. If the design included functionality to shorten or lengthen audio by a percentage amount, what would be a possible justification for restricting that calculation to an int? It wouldn't make any sense at all in the context of a program one of whose primary functions is stretching the time of audio. 

scook
No, that is more pointless speculation on your part.

No it's not. It's perfectly reasonable speculation. A person is perfectly entitled to speculate. It's just part of daily life. 

@WDI, Good plan - nice profile pic - who does your hair?  :)
 
To others: For the second time now, can we PLEASE stop the negative posts?  Maybe for the weekend?  
 
Bob Bone