I don't think there's any suggestion of loose headshells etc as a cause of pitch instability - perhaps confusion with 'headshell movement' meaning that the tonearm is free to pivot and so the headshell is always free to move?
In response to headshell displacement, eg due to a click or patch of different friction, there is pitch variation due to scrubbing. This, IME from polar plots, typically follows a natural oscillatory decay, with spectral content at the cart/arm resonant frequency or frequencies. It shows up on polar plots as a classic decay pattern, following a log dec path.
Its effect can be significant, and is due to an interaction of cart/arm/record which is fairly random. When other things are going on at the same time, it can be tough to separate visually, but sometimes it's obvious. Also can be difficult to separate from what variation there is cut into the test record, and that's why rigs like JP's which show it only to a small extent should be used in test record reference recordings, IMO. It will still be there, of course, to a small extent - but shouldn't be there from the lathe.
I'll try to dig out polar plots of a bad example of cart/arm stability or two....... [EDIT: check out post #89 et seq on this thread for a clear demo and discussion]
Tonearm/cart stability typically can be a significant or dominant contributor to pitch instability, moreso than platter speed variation in a healthy TT, IME. As discussed earlier in the thread.
LD
In response to headshell displacement, eg due to a click or patch of different friction, there is pitch variation due to scrubbing. This, IME from polar plots, typically follows a natural oscillatory decay, with spectral content at the cart/arm resonant frequency or frequencies. It shows up on polar plots as a classic decay pattern, following a log dec path.
Its effect can be significant, and is due to an interaction of cart/arm/record which is fairly random. When other things are going on at the same time, it can be tough to separate visually, but sometimes it's obvious. Also can be difficult to separate from what variation there is cut into the test record, and that's why rigs like JP's which show it only to a small extent should be used in test record reference recordings, IMO. It will still be there, of course, to a small extent - but shouldn't be there from the lathe.
I'll try to dig out polar plots of a bad example of cart/arm stability or two....... [EDIT: check out post #89 et seq on this thread for a clear demo and discussion]
Tonearm/cart stability typically can be a significant or dominant contributor to pitch instability, moreso than platter speed variation in a healthy TT, IME. As discussed earlier in the thread.
LD
Last edited:
Pretty easy to mix in a once per rev signal off the table. Maybe a small reflective opto or tiny neo-magnet and hall sensor? I would just either mix it in or record it on one channel.
Also last night I realized that just to get to a certain point quickly I used the code I wrote for my article. The Scipy package probably has a far richer set of options for filtering built in.
EDIT - Yes Scipy has the back and forth IIR filtering built in, which is linear phase. Also the internal routines will be compiled and get closer to real time processing. On my machine two revs takes 3 or 4 seconds as is but that includes drawing the plot.
Last edited:
Good idea.... however we are victims of success in that amplitude mixing won't show up in the FM domain, ie the polar plots, because the detectors are too good at AM and baseband noise rejection..... (!?!)
So one might need to manually mute a section of suitable duration where the marker should be.......? That should do it.
I should say, I haven't found much need to know absolute rotational position, but for sure there will be times.
LD
Last edited:
As Pano said, I was thinking use the second channel as a guide for grabbing your frames. Should be easy to get a few msec 1V blip every rev. Thinking of doing this real time is getting ahead of ourselves for now. Or adding the marker to the plot is trivial since I can read both channels, or in fact use the marker to rotate the plot to 0.
Last edited:
Yes probably confusion from my side. I will re read those post again to understand.
This is exactly what I'm going to endeavor to do this weekend. I've all the bits, just a matter of finding the time.
Thoughts on how to optimise the capture:
1) Sample at 32000, this is perfectly adequate for accurately capturing the test tones (16000 is fine if your ADC can do it) and makes the file smaller and maths quicker
2) RIAA equalisation is not necessary
3) An analog input High Pass of about 300Hz to get rid of mains hum and rumble
1) Sample at 32000, this is perfectly adequate for accurately capturing the test tones (16000 is fine if your ADC can do it) and makes the file smaller and maths quicker
2) RIAA equalisation is not necessary
3) An analog input High Pass of about 300Hz to get rid of mains hum and rumble
Makes sense, the post filtering is all in Scipy so it's conceivable an Rpi could run it near real time. BTW I brickwall filtered some of the data sets at 400Hz and got no change, I suspect the noise near the frequency of interest is more important? Also I have not even explored shorter transforms stitched together, though I suspect there will be issues.
Last edited:
I have a PCM2902 USB ADC that I can dedicate to this with a Pi 3B.
This can do sampling at 16000. I need to think about how this affects the two biquad filters, as the original code was based on Fs = 96000
To make this really realtime means skipping the SOX stage, portaudio perhaps
Not sure I understand the upside of realtime, beyond being fun to do, but here's my 2p worth:
In the interim, it's easy to adjust sample rates in Sox, in case that helps.
HTH!
LD
It's true that such sample rates are fine and should have no meaningful compromise - but only necessary if calc time is an issue and from a non-realtime perspective it's better to support as many standard sample rates and file formats as possible. The rate and channel format is always in the file header, and can be read. From what Scott posted, I think the python function code is snappy - why not try it at 96 or 44.1 and see ?
In the interim, it's easy to adjust sample rates in Sox, in case that helps.
This is true, but it doesn't affect the result either way.
Again, this is harmless and easy but not necessary given excellent noise rejection performance. Mains hum and rumble isn't FM, of course. There's a downside of filtering because it hampers one using 300Hz as a test tone, which cropped up earlier in the thread and is common enough.
HTH!
LD
Last edited:
The filters adapt to any Fs if I missed that I'll fix it (just replace the 96000 with Fs in the coefficient making function). I'm also working of using the filters in Scipy mine are written in Python and are probably a major speed hit. For this portaudio should be fine but I don't know anything about it.
- Status
- This old topic is closed. If you want to reopen this topic, contact a moderator using the "Report Post" button.