96kbps is a bizarre choice for analysing wow and flutter, also excluding many 48k max PCM290x based ADCs like the old NADs
Since - so far - I've mainly been testing and developing the measurement computation, 96k/24 was convenient for me.
Firstly, I do all my LP recordings 96k/24 anyway.
Secondly, since I started off doing plain 'fringe counting' the higher the sample rate, the more accurate I can get the frequency measurements.
This is because the program counts the number of zero-crossings it can find, and counts how many samples apart the first and last example are. As a result, the accuracy of the mean frequency determined is related to the sample rate. That's what lets me get a few parts-per million *provided* the signal/crap ratio is high enough.
I've sinced added in interpolating for the sectional counts. So the sample rate should now matter less than it did. However I've not yet added the code to cope with other rates or 16bit.
As I've explained, all I've done thus far is an *experimental* version to see if it works. It seems to, so I can now do a 'better' version to allow other input rates, etc...
...and now so can others. I've just put up copies of the source code and a 'help' text file which anyone who is interested can get from
http://jcgl.orpheusweb.co.uk/temp/wandfprog.zip
Anyone who can program in 'C's welcome to help themselves. Adapt, improve, use, as you fancy. Good programmers may find the source code amusing, or may weep at my rubbish programming skills, as they prefer.
Jim