scott wrote:
>> Only problem is that first I'd have to find out what the necessary API 
>> calls are. This is highly likely to be quite intractibly difficult.
> 
> It's not *that* hard to use the Windows wave API

O RLY?

Is this the same Windows API that takes a dozen API calls just to open a 
plain ordinary window on screen and put a button in it?

>> That way I only have to worry about WAV. (This is more complicated 
>> than it sounds!)
> 
> I thought WAV was quite easy to decode, isn't the data just stored 
> byte-by-byte after some header?

Yeah. The hard part is figuring out where the header ends.

(It's a RIFF file, which is an extension of the old Amiga IFF format. Or 
rather, it's IFF but with all the 4-byte quantities written the wrong 
way around.)

> Yeh, I can see how you would easily get an output was a multiple of the 
> actual BPM.

Actually, BPM is an inherantly ambiguous measurement anyway, since it 
varies according to what you consider to be a "beat".

> But even with that information you could figure out the 
> exact BPM yourself (or fix your software to automatically multiply the 
> BPM to be in a certain range).

That would mean that unusually fast or slow tracks would get measured 
wrong. But hey... ;-)

>> It then becomes a question of statistics. Just how accurately can you 
>> decide where the beats are, assuming all the tap signals contain a 
>> certain amount of jitter?
> 
> That's easy, the hard bit is figuring out if the person missed a tap, or 
> pressed one too many times.  This would give quite a large error (as 
> opposed to simply pressing all the taps half a second out).

I'm thinking you could probably do this by looking at the taps and 
rejecting any which vastly deviate from the others. But we'll see...

Initial testing indicates that I can tap with a standard deviation of 
around about 20 ms, which isn't too bad. Interestingly, the SD is much 
lower for fast tracks than slow ones. In all cases, I'm getting about +- 
5% jitter.

Post a reply to this message