Thunk.... Crack... MPH

Billiard Architect

AzB Silver Member
Silver Member
Revisiting the idea of testing the speed of your break without the expensive equipment. What if you were to record the sound of you breaking the balls then load it into a sound application (like cakewalk) and find the peaks of the recorded sound file between the time that the cue contacts the cueball and the cueball contacting the rack. Cakewalk would give you the timing of the sounds and you already have the distance (i think it is 47 3/4 inches if you break from the spot). So if you have time and distance you can calculate mph.

1 inch = 0.0000158 mile

So to travel 1 mph you would cover (1/0.0000158=63,291) 63,291 inches or 1,054 inches per minute or 17.58 inches a second. So if you were to hit the ball and it took 2.4886 seconds to travel 47.75 inches between the time that you saw the spike in the sound file till it hit the rack you would be hitting the ball 1 mph. Knowing this if you were to hit the ball and the time was .10342 seconds then(2.4886/.10342=24.0630) you would be hitting the ball @ 24.0630 mph

Whadya think?

JV<--- Please send all royalty checks via paypal...
 
Johnny "V" said:
Revisiting the idea of testing the speed of your break without the expensive equipment. What if you were to record the sound of you breaking the balls then load it into a sound application (like cakewalk) and find the peaks of the recorded sound file between the time that the cue contacts the cueball and the cueball contacting the rack. Cakewalk would give you the timing of the sounds and you already have the distance (i think it is 47 3/4 inches if you break from the spot). So if you have time and distance you can calculate mph.

1 inch = 0.0000158 mile

So to travel 1 mph you would cover (1/0.0000158=63,291) 63,291 inches or 1,054 inches per minute or 17.58 inches a second. So if you were to hit the ball and it took 2.4886 seconds to travel 47.75 inches between the time that you saw the spike in the sound file till it hit the rack you would be hitting the ball 1 mph. Knowing this if you were to hit the ball and the time was .10342 seconds then(2.4886/.10342=24.0630) you would be hitting the ball @ 24.0630 mph

Whadya think?

QUOTE]

Um, I think I feel dumb, lmfao! But, I will add this one observation: I have noticed that the sound of break often does not coincide with the speed or strength within which the ball are being broken. Just my observation.

Amanda :p
 
SonjaBlue03 said:
Um, I think I feel dumb, lmfao! But, I will add this one observation: I have noticed that the sound of break often does not coincide with the speed or strength within which the ball are being broken. Just my observation.

Amanda :p

Amanda, it's not the way the break sounds that he's measuring here. It's the sound of the cue tip hitting the cue ball and the sound of the cue ball hitting the apex ball. As long as you can discern the sound on the recording then that's all that matters. The only variables are the quality of the sound recording device that you have and the noise level of the room (as well as any other noises you make when you break and being able to seperate said noises on the wave readout).

Edit: You'd also want the receiver to be equidistant from both the starting and finishing point so as the time that it takes for the sound to reach the device is the same, other wise other calculations would be needed.
 
Johnny "V" said:
Whadya think?

JV<--- Please send all royalty checks via paypal...

Yeah, but what about the sound delay, it’s not instantaneous, how do you correct for that?

Rick <-- :D
 
hustlefinger said:
Yeah, but what about the sound delay, it’s not instantaneous, how do you correct for that?

Rick <-- :D




unless its moving faster than the speed of sound.......there would be no delay.

if you're breaking that fast......i don't want none...... :D

VAP
 
Johnny "V" said:
What if you were to record the sound of you breaking the balls then load it into a sound application (like cakewalk) and find the peaks of the recorded sound file between the time that the cue contacts the cueball and the cueball contacting the rack. Cakewalk would give you the timing of the sounds and you already have the distance (i think it is 47 3/4 inches if you break from the spot). So if you have time and distance you can calculate mph.


Whadya think?

JV<--- Please send all royalty checks via paypal...

Sounds like it would work.

Fred <~~~ or so I hear
 
hustlefinger said:
That isn’t fair you edited a post after the fact. Foul!

Rick

But I edited it before I read your post...lol. As soon as I posted it I realized that I forgot to include that part!

vapoolplayer said:
unless its moving faster than the speed of sound.......there would be no delay.

if you're breaking that fast......i don't want none......

VAP

Actually, there is always a delay measuring sound from a distance. The time delay would be the distance traveled divided by the speed of sound. However, if the receiver is equidistant from the two sources of sound the delay is the same and thus it cancels out.
 
why not ...

Why not just get a 'baseball gun' and let it tell you how fast you break?

Which doesn't mean a whole hell of a lot, since accuracy on the break
is just as important. There exists a continuum where your break is
optimized with speed vs. accuracy, and if you exceed the max of that
continuum, your accuracy drops off in a hurry, and pretty much renders
your break almost useless (lots of noise, no balls pocket off the break).
Likewise, if your speed is below the minimum of that continuum, it would
also render your break useless because their would not be enough power
to get a ball to the hole.

Breaking kind of takes on a nature all of its own sometimes, and noone
has perfected it over the long run, maybe during one playing session, but it can turn to sh*t the next time, and you will be breaking the same way as you
did before, maybe even on the same table.
 
Wouldn't everybody also have to be hitting from the exact same spot on the table since the inches could change based on a side break to head spot break and anywhere else in between?
 
drivermaker said:
Wouldn't everybody also have to be hitting from the exact same spot on the table since the inches could change based on a side break to head spot break and anywhere else in between?

I think the program would just tell you time between peaks. It'd be up to the breaker to measure the distance and do a little math (very little).

Fred
 
drivermaker said:
Wouldn't everybody also have to be hitting from the exact same spot on the table since the inches could change based on a side break to head spot break and anywhere else in between?

For this method, you would just need to do the distance measurement since he proposed manually finding the amplitude peaks and calculating the average speed.
 
Fred Agnir said:
I think the program would just tell you time between peaks. It'd be up to the breaker to measure the distance and do a little math (very little).

Fred

You beat me to the punch by a hair!
 
drivermaker said:
Wouldn't everybody also have to be hitting from the exact same spot on the table since the inches could change based on a side break to head spot break and anywhere else in between?
the 2.4886 seconds is based on the 47.75 inches (breaking from the spot). if you were to break from the side rail lets say it was 52.45 inches from the head ball then your base second calculation would be 52.45/17.58 or 2.9835 seconds for your 1 mph calculation. Its not rocket science :D

JV<---- Looking into writing the VB app to run it.
 
Johnny "V" said:
the 2.4886 seconds is based on the 47.75 inches (breaking from the spot). if you were to break from the side rail lets say it was 52.45 inches from the head ball then your base second calculation would be 52.45/17.58 or 2.9835 seconds for your 1 mph calculation. Its not rocket science :D

JV<---- Looking into writing the VB app to run it.

I'm with you all on the theory etc., but one must consider the timing error. Using roughly the numbers originally posted, it will take 100ms to travel 48" at 25mph. I do not know what the accuracy of PC real time clocks nor how cakewalk works, but I'm thinking that the real time clocks in many (most ? all ?) would not time things well in the ms range. Now if cakewalk uses some kind of time-code or synchronization from a fancy sound card (plain sound card maybe even ?) then you might get reasonable accuracy. This would need to be understood before you could have confidence in the resulting numbers. Setting the CB 48" +- 1/4 " would be fairly easy to do for any rack mechanic, but that would result in an additional error of +- 0.5%.

I think it would be more fun to make a little ramp and put it on the head spot, then 'break' over it and measure where the CB enters the drywall. A few basic trajectory calculations and you've got the true breaking speed :D (the timed method really results in the average speed of the CB from foot string to head spot) Doing this would also provide you with additional pool playing time as the wife would surely boot you out of the house for such a dumbass move ... I like it ;)

Dave
 
Rackin_Zack said:
!



Actually, there is always a delay measuring sound from a distance. The time delay would be the distance traveled divided by the speed of sound. However, if the receiver is equidistant from the two sources of sound the delay is the same and thus it cancels out.

ok......i stand corrected.

thanks

VAP
 
RichardCranium said:
Not knocking the effort....but it just seems like more sense to me just to work on creating the sound of a ball going into the pocket off the break....(preferably with shape on the lowest # ball) ...... :)
I agree but I thought it would be a fun experiment.
 
Back
Top