|
![](/i/fill.gif) |
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
|
![](/i/fill.gif) |