advertisement


Wow and flutter 'meter', etc

I use WFGui for setting speed and W+F tests on tape decks, it can use 3000 and 3150 Hz tones, something that could tell me what the frequency was if not close to 3000 or 3150 Hz would be useful as WFGui starts rounding to the nearest 5Hz if it's far off. I have a half speed cassette deck and reel to reels to set the speed for too.

The program I've written takes in a 10 sec chunk of recording and measures the mean frequency over that time with an accuracy of a few parts per million. Should work over a range from somewhere below a 1kHz up to around 10kHz. It then uses this mean as the base for scaling the deviations.

Its basically what on a lab bench would be called a frequency counter. It scans the samples looking for waveform zero crossings, and counts how many there are. It also counts how many samples these cover from the first to last. It then knows how many cycles there are in about 10 sec with a precision of about +/- a sample interval. So for a 1kHz-ish tone it finds about 10,000 cycles over about 10 sec and knows the time taken to about +/- 1/96000 th of a sec. i.e an accuracy of 1 part in 960000. In practice it isn't perfect, so you get something around a few ppm.

The short term 'instantaneous' values use successive shorter chunks. But there I add in doing an interpolation to esitmate where between samples the crossings should be at the start and end of the count.

Provided you have a high tone/noise ratio this can work quite well.

Jim
 
Or you could just write it in Java and have no porting issues at all :)

Honest, Guv. I did *try* to learn and use Java. I struggled with it for over a year before I gave up. Afraid I found it was like learning Chinese characters. I spent all my time trying to find what 'method' and 'class' I wanted in order to do anything. Then kept finding the buggers would change everything and what I' done was 'deprecated'. I had a about a couple of feet of bookshelf devoted to a load of housebrick-sized Java manuals and books. Finally binned them as it was slowing me down so much, and went back to 'C'.

'C' is a language I find far easier to use. Fortunately, its source code is also pretty portable and is widely used. The IEEE still rate it as one of the dominant injuneering languages.

But then it did take about 20 years to get me to stop using FORTRAN. 8-]

Jim
 
I think you can make GNUPlot do that for you directly with some simple incantations.

Paul

Yes. I like the 'polar plot' idea. One key to it working, though, is to ensure you have nailed the correct value of the mean frequency of the test tone and rotation rate. That would then let you average over a number of rotations to improve the SNR of the plot.

By default, my programs tend to write out the data in CSV format so you can then plug that into your favourite plotting package and/or spreadsheet. However on linux I tend to also output 'veusz' files as I like the Veusz package because it reminds me of the '!Tau' plotter on RISC OS.

I'll experiment to see if I can generate useful 'polar' plots. But I'm also now going to have a go at seeing if I can spot the onset of modulation induced draw.

Glad I asked about this as I'm finding it interesting! :)
 
Honest, Guv. I did *try* to learn and use Java. I struggled with it for over a year before I gave up.
The suggestion to use Java might have been tongue in cheek. I see many issues with update to the JRE version and how platform independent Java really is is debatable
 
Honest, Guv. I did *try* to learn and use Java. I struggled with it for over a year before I gave up. Afraid I found it was like learning Chinese characters. I spent all my time trying to find what 'method' and 'class' I wanted in order to do anything. Then kept finding the buggers would change everything and what I' done was 'deprecated'. I had a about a couple of feet of bookshelf devoted to a load of housebrick-sized Java manuals and books. Finally binned them as it was slowing me down so much, and went back to 'C'.
Did you consider scripting languages/environments like matlab, scilab, octave, scipy, julia,... which would appear well suited to "computational engineering" tasks like this?
 
One problem with all of these things is they only test the deck when playing a constant amplitude test tone, i.e. there are no effects of modulation/transient drag, and I suspect that is the area that would seperate the good decks from the really great decks. Obviously one would need a two-arm deck to test this along with a record cut with both a test tone and some very dynamic and changing music or tone bursts. As an example it surprises me to see a little but noticable strobe drift on my TD-124 depending on whether the arm down and playing or cued. This is a deck with sufficient torque to get a hefty 5kg platter up to speed within a single revolution (about 2 seconds from stationary), i.e. very high torque/power compared to the typical modern belt-drive deck. My 301 is even higher torque, but it hasn't a strobe so I've never investigated the difference between playing and not.
 
One of the things on my to do list is to have a record cut with simultaneously a speed reference tone and synthetic dynamic 'music'.

The first test track has been designed, but I am still looking for a way to include a sweep or MLS such that I can get a waterfall plot in REW or similar.
 
One of the things on my to do list is to have a record cut with simultaneously a speed reference tone and synthetic dynamic 'music'.

The first test track has been designed, but I am still looking for a way to include a sweep or MLS such that I can get a waterfall plot in REW or similar.

If the test tone track is on the outer sections of the LP, you could pop a 45rpm single on top and clamp it....
 
If the test tone track is on the outer sections of the LP, you could pop a 45rpm single on top and clamp it....

Good idea, though it would make more sense to have the random highly modulated stuff on the outside and the test-tone on the 7" to maximise the drag effects. I assume someone somewhere must have cut a 7" test tone disc? I know the BBC had some 7" test records, but I've no idea what was on them.
 
Did you consider scripting languages/environments like matlab, scilab, octave, scipy, julia,... which would appear well suited to "computational engineering" tasks like this?

Afraid not. Mainly because I'm used to wriiting my own code in languages starting from FORTRAN that I can get my head around and where the source code is fairly portable anyway.

In addition, I'm wary of higher level languages like the above list as I suspect they are built using 'C', but prevent me from seeing the code they use to impliment their own functions, etc. I just find it easier and more 'down to the metal' open to use 'C'.
 
You can do a simple 'drag effect' test by observing what happens when a test tone 'switches on'. It should cause the result to have a frequency that drops over the response time of the system to drag. And also may show any 'wobbles' changing. I should be able to try this with the recordings and my program, but not yet got the round tuit.
 
Just had a quick look at the first ten secs of the test 1kHz recording I'm using. Any drop in rotation speed due to drag seems to be buried under the wow and flutter variations. May be there, but not obvious to Mk1 eyeballs looking at the plots.

How typical that is of other systems, dunno. FWIW I'm using my ancient Technics Direct Drive TT with a Shure V15/III. May be a case of low drag and high torque/feedback, or that what I've written wasn't designed for this, so buries it under other results.
 
OK, I've just poked the data produced by my test program into a spreadsheet and got that to do a 'polar' plot on the assumption that the rotation rate is 33.33333/60 Hz (0.555555) I get this
http://jcgl.orpheusweb.co.uk/temp/polar.png

The rate probably isn't exactly right, it may be possible to fit a best rate and thus unscramble any error in the recording rate from the rotation rate. In effect using the wow to distinguish. :)

Jim
 
If the test tone track is on the outer sections of the LP, you could pop a 45rpm single on top and clamp it....

No. The idea is to have a test record that works with just one arm/cartridge.

If you have two then using a single works indeed.
 
No. The idea is to have a test record that works with just one arm/cartridge.

If you have two then using a single works indeed.

I'm sure you can make it work.
A high compliance MM will track a low-medium level tone at <0.5g. Modern or vintage AT or Goldring MMs certainly will.

It depends what you want to dest and to what accuracy. If you want to determine the existence of any detrimental effect at reasonably common tracking forces it should work well enough.
 
I guess I'm somewhere around the average with a DL-103 tracking at 2.5g. There are plenty of MMs happy at a gram or so (assuming a real clean record) right through to things like SPUs etc at 4g or more. I'd expect the potential for transient drag to increase significantly with tracking weight. I guess this is a reason one tends to see idlers, DDs or real high-mass high-inertia decks like Verdiers under SPUs etc.
 
I must confess that when I think back to all the TTs I've owned, I've never noticed anything amiss with the sonics such that I'd spend time investigating this.

Where stability symptoms have been heard its been due to old belts or very old DD motor control circuits needing a service.

I'll happily stay in blissful ignorance on this one :)
 
I thought the same, then swapping from standard linn oil to thick viscous silicon oil in the lp12 bearing showed I was wrong. Adding constant drag at the bearing reduced measurable cogging effects and had an audible effect on sustained note stability. It also utterly swamped stylus drag effects rendering them inaudible.
 
I don't care if it can be heard, I just want to see if it can be seen...

FWIW my demodulation tool takes an argument regarding the notional rotation rate of the polar output, so you can set it to the base speed, or perhaps to something related to the idler, or the motor pulley. The idea being to let the eye determine the correlations. I haven't made any effort to determine the test tone frequency automatically.

Paul
 
I thought the same, then swapping from standard linn oil to thick viscous silicon oil in the lp12 bearing showed I was wrong. Adding constant drag at the bearing reduced measurable cogging effects and had an audible effect on sustained note stability. It also utterly swamped stylus drag effects rendering them inaudible.
Goes against the ultra-low torque motor theory then.
 


advertisement


Back
Top