• WANTED: Happy members who like to discuss audio and other topics related to our interest. Desire to learn and share knowledge of science required. There are many reviews of audio hardware and expert members to help answer your questions. Click here to have your audio equipment measured for free!

Turntable RPM Measurement Script

Digital1955

Member
Joined
Feb 26, 2022
Messages
61
Likes
49
I have been inspired by @JP 's various scripts for measuring cartridge frequency response and plotting W&F. It gave me an idea of writing a similar script to calculate the RPM of a turntable platter with as much precision as possible. I settled on a method of using the 'click' that is produced as the stylus loops in a dead-end groove. The click is the result of the stylus passing by the entry groove into the dead-end groove each rotation. Because my main turntable (Sony PS-X50) auto-stops records, I ended up using a dead-end groove from the CBS STR-100 test LP (Issue 3). Band 3A has a low noise floor and produces a clean click waveform. I thought using this for testing was also helpful because I know a lot here have that particular LP. However, it isn't a requirement, any LP should work (they all have a dead-end groove, right?).

So I wrote the script in Python, to keep with what JP has done. You must make a WAV stereo recording of the stylus looping in the dead end groove. After that, using Audacity, I like to normalize it to 0 dB, so that I can easily visualize / count how many clicks I captured. You need to pass the number of clicks as an argument to the script, along with the minimum expected time (in ms) between clicks. This is so the script can easily identify the target clicks. The script then calculates the timing between click peaks with as much precision as available (according to the sample rate used). When it is completed, it then displays minimum, maximum, average, and standard deviation for both time intervals and RPM values.

I have decided to keep the script on github, for easier versioning and sharing. I have included a README with more information and instructions. That README links to this thread as the central place for discussion and results. However, I do have it in my mind that I would like to duplicate published user results in the github repo, similar to how AutoEq does.

Feel to review the technical accuracy of my statements and methods. You can give your comments here, or if you have a github id, you can also submit a pull request.
We can use this thread for discussion and results.

Below is an example of the output. It writes to standard out where the script is run (there aren't any chart, graph, or image generated). I tested running very long tests,
as well as back to back tests, 1 minute long each. The results are very consistent and stable regardless. This method is obviously only capturing the average RPM over
one revolution. I believe its uniqueness and usefulness is its accuracy. In addition, measuring the speed this way includes stylus friction.

Note that when reading the output, the minimal time interval produces the maximum RPM, the the maximum interval produces the minimal RPM.

python3 rpm.py ~/test103c34.wav 34 1700 --channel_mode left Channel mode: left Revolutions: 33 Statistic Time Intervals (s) RPM Values ------------------------------------------------------------------------------------------ Min 1.7998958333333332504 33.3335262356842392251 Max 1.7999895833333332540 33.3352624573181302026 Average 1.7999444444444443469 33.3343621830166867426 Std Dev 0.0000332055103909648 0.0006149542691192381

LINK TO SCRIPT >>> Turntable RPM Analysis script on Github
 
Last edited:

JP

Major Contributor
Joined
Jul 4, 2018
Messages
2,295
Likes
2,473
Location
Brookfield, CT
Have you compared it to the typical phone apps? I've not found them to be very accurate, but haven't had the benefit of quite this much precision.
 

Bob from Florida

Major Contributor
Joined
Aug 20, 2020
Messages
1,307
Likes
1,199
The Waxwing preamp actually does this as part of the app used on the smart device of choice. You select RPM measurement for 33,45,or 78 and let the stylus click on the runout track and a few rotations later you get the speed. I use it to quickly provide feedback as I adjust the speed pot on my turntable. Nice feature. Also, cool that you took the time to develop your own solution!
 
  • Like
Reactions: JP

USER

Addicted to Fun and Learning
Forum Donor
Joined
Mar 30, 2019
Messages
967
Likes
1,598
I have been using @JP's polar plot script to fine tune speed adjustment. I look forward to comparing the results.

Clearaudio Concept · Tacet.png
 
OP
Digital1955

Digital1955

Member
Joined
Feb 26, 2022
Messages
61
Likes
49
Have you compared it to the typical phone apps? I've not found them to be very accurate, but haven't had the benefit of quite this much precision.

The particular RPM app on my Android phone (Samsung S22), located directly over the spindle, reads faster (33.36 vs 33.3343621830166867426).
But I really have no idea of the accuracy of those things. They are cool to look at though. But when I see the RPM readout drifting from the starting
azimuth (least it does on my phone), then I lose some hope. We need at least 10 decimal places of precision or else it just ain't gonna sound right. :)

------

I very carefully wrote and reviewed the Python script to maintain as much precision as possible. I was pretty excited to quickly share it, however, I admit there seems to be some unrealistic(?) stability. Maybe? That's why I am looking forward to some other measurements from others.

The first post sample is a real measurement from my Sony PS-X50, using a Motu M4, recording at 24/192 (Audacity software), over 1 minute.

Let's say we were playing a LP with a perfect 1000 Hz tone @ 33.3333...

According to my tests results:

Min : 33.3335262356842392251 RPM = 1000.005787 Hz
Max: 33.3352624573181302026 RPM = 1000.057874 Hz

Offhand, that looks unrealistically stable, doesn't it? I know we are averaging the speed over 1 revolution, and there is stability from that averaging.
I've looked for any unexpected source of averaging that I might have missed - and I can't find any. The timing of the peaks captured via the library I am using in
Python look accurate.

I have a few cheap belt drive AC synchronous motor turntables boxed up with no cartridges mounted on them. I'm hoping to have a few more data points here
so I don't have to drag them out.
 

anmpr1

Major Contributor
Forum Donor
Joined
Oct 11, 2018
Messages
3,741
Likes
6,455
Have you compared it to the typical phone apps? I've not found them to be very accurate, but haven't had the benefit of quite this much precision.

I tried a phone app (not sure which one--the one with the most downloads from the Playstore) on a pretty recent model Galaxy phone (S22). One record player was quartz locked (SL-1200 MK5) and the other servo but no quartz PLL (SL-1100a). With the strobe centered the app showed 33.5 rpm on both. My guess is that the turntables (especially the Quartz PLL) were accurate, and the phone app is off. But I have no way of knowing for certain.
 

morillon

Major Contributor
Joined
Apr 19, 2022
Messages
1,380
Likes
279
firstly there is a huge precaution to take with our applications on telephone... it is that a lot of "too light" manufacturing, tolerance on the axis etc or principle of suspension etc does not allow their use, with the unbalance or the dysemetry of the weight of the phone.... the limit too often their interest
 

Balle Clorin

Major Contributor
Joined
Dec 26, 2017
Messages
1,347
Likes
1,219
Compared with a quartz controlled lamp and strobedisk, my phone apps are 0.2% off on absolute speed, while variations seem accurate
 

JP

Major Contributor
Joined
Jul 4, 2018
Messages
2,295
Likes
2,473
Location
Brookfield, CT
Hmm. It showed RPM properly when I tested originally. Will have to look at that.
 
OP
Digital1955

Digital1955

Member
Joined
Feb 26, 2022
Messages
61
Likes
49
Hmm. It showed RPM properly when I tested originally. Will have to look at that.

I was having trouble understanding it until I realized the "-" in front of the RPM axis isn't a negative sign, rather it is a plot hash mark.
 
Top Bottom