advertisement


Wow and flutter 'meter', etc

Thanks for the calibration tones! :)

The results here are encouraging. e.g. from 6/6666_200_1_25/wav

I get a nice 'wobble' that is just under +/- 0.1% peak, with 'raw' and 'AES weighted' values of 0.096% and 0.088%. The 'two sigma' approach can get a bit confused by a 'sampled crown' produced by sinusoidal FM, so that seems fairly good to me.
 
Jim,

It builds on Windows fine.

There's a grumble from the C library about "rd" as an open mode for a file, and either that is an error or it's an undocumented extra for RISCOS. I changed it to "rb", if it's actually correct RISCOS then I'll conditionally compile it.

It doesn't like filename with spaces in them (don't ask...).

It doesn't let you analyse the file from the start.

96k24 WAV header required (as expected).

And it produces the same numbers from DC's test file as you report. So probably good. Happy to build this for anybody interested.

Paul
 
The read mode is probably my typo. Need to check that.

I don't like file names with spaces, either. They can screw up all kinds of things. 8-]

The program has a 'trap' to prevent out-of-range choices, so that may need a tweak.

The 'wandf_flex' version should work at any rate up to and inc 96k. Also 16 as well as 24 bit. I did put the code up for that, but as yet only done the RO version of it. You should be able to apply the same changes to that as Nick did for the earlier version.

However note that it still *only* understands the plain 44-byte headers. FWIW I always use my 'WAV_Cleaner' programs to remove other metadata as it saves me having to add the same extended header handling to every program when I'm just using them on test/measurement files.

All being well, I'll make the first 'general' RISC OS app version public on my webpages later today. I've just finished writing some better documentation explaining how it worlks. Also added some style files for the RO "!Tau" graph plotter so people can visualise the results as object-based plots. I'll then set about doing the Linux version to go there. Both will have the current source code, and anyone is welcome to use/modify/improve/port it as they wish.

I'll probably initially do a plain ROX Linux version that generates the same CSV file output. But at some point I'll add 'vesuz' plotter output so the user can look at the graphics, etc.

Jim
 
I've now put a full RISC OS Application version up that is linked to my main software page at

http://www.audiomisc.co.uk/software/index.html

That won't be of direct use for most people here, but does contain the current version of the source code. I'll put up an equivalent ROX/Linux version when I've made the relevant changes.

My use of "rd" is a real curio! I've been using that for years and not had either the RO compiler or GCC complain about it! Seems to be an odd habit I acquired ages ago for some reason, and which the compilers I've used didn't warn me about. I'll try to correct this in future, but I tend to re-use a lot of my old C proceedures, so it may tend to keep appearing. The remarkable thing is that this is the first time anyone has noticed and pointed it out! Sorry about it. Shows I never really did get taught any programming. Just banged rocks together until I got a spark! :)
 
I don't see the source.

The Windows debug C library asserted at run time with the invalid file open mode. The 'b' is redundant but good practice on Unix derived systems, it's necessary on others (such as Windows) to distinguish between text files and binary files.

Paul
 
I don't see the source.

The Windows debug C library asserted at run time with the invalid file open mode. The 'b' is redundant but good practice on Unix derived systems, it's necessary on others (such as Windows) to distinguish between text files and binary files.

Paul

If you're referring to the RISC OS app linked from my software page, open the zip and look inside the 'c' subdirectory. This is inside the main application directory "!LP_WowAndFlutter".

The RO convention is that the source code in 'C' is in a 'c' subdirectory within the application's directory, not in a file with a '.c' type. The file name is "!RunImage" because that's the RO convention. When compiled and linked it generates an executable called "!RunImage" at the top level in the application directory.

(Similarly, the 'o' and 'h' subdrectories are where a RO programmer would put the relevant types of files.)

I think this arose because from the start RO uses '.' as the directory delimiter. Quirk of history.

WRT fopen, the curio is that I've been using "d" (not "b"). I assume the compliers are simply looking for the options they expect and ignoring the "d".
 
I see it now. Should have twigged...

In essence the Linux variation builds on Windows, I'm happy to put a build on my web space for anybody who'd like a play.

Paul
 
In that case, many thanks to Paul :).

I'm not sure whether this is the correct thread to discuss the results though?
 
I've run YNWOAN's file through Jim's process, the reported W&F was,

Limit raw of 1523 at +/- 81 [ 0.162 percent]
Limit weighted 1523 at +/- 55 [ 0.110 percent]

I persuaded the polar output to plot,

150110_02_waf_polar.png


The scaling and filtering is completely incomparable, but the same 16 bumps I think.

The Jim source I built, which is essentially a merge of the Linux code upthread with the latest AudioMisc drop, and the executable is at http://www.epicyclism.com/audio/WinWF.zip.

Paul
 
Thanks for that. It'll be handy when I do a ROX-Filer app for Linux. :)

FWIW The scaling for my 'polar' plots is that a perfect circle of radius '1' would mean no wow and flutter at all. The variations are such that +/- 0.5% (peak) wow and flutter would cause the wiggles to extend from the center zero up to a radius of '2'. So it should show variations over a +/- 0.5% range before it "falls though the center". That seemed to me a reasonable range.

BTW Like most true audio geeks I have an asortment of test LPs. But someone has asked me if they can get an "inexpensive" test LP in the UK. These days I tend to use the "Analogue Productions" one. But is there an alternative anyone can suggest for a UK buyer?
 
16 bumps per platter revolution, I assume your pulley ratio is roughly the same as mine Mark 1:7.5 so i'm wondering what the cause of those bump is, because it aint cogging, as that would be 120 little bumps per rev.

Could it be asymmetry in the pulley? 2 high and low spots caused by the interference fit. I know it shouldn't be as they were CNC machined, faced and parted in one pass so they should be nominally perfect.

I wonder if the record production is the source, or could it be a combination arm/suspension mode at circa 8hz?

I might plug my scope into my tonearm and see what i get?
 
Yes, the drive ratio is roughly the same as yours though not exactly the same. I doubt is the drive pulley. It could be a suspension mode I guess. I could disable the suspension and do the test again which would clarify that issue. However, it could easily be the record.
 
It's not going to be the motor pulley on a belt drive, the ratio would have to be factor of 16. Sometimes I think this happens with an idler, the EMTs seem to have a whole number of idler revolutions per platter revolution, so an idler bump gives you the fifty pence piece look to the polar.

A suspension or belt resonance at exactly 8.89Hz also seems really unlikely.

So it's either in the recording or there's something odd about the drive surface of the platter.

I'll have a poke about for older samples from Mark's TT.

Paul
 


advertisement


Back
Top