Yeah it is strange that a 500$ vidcard from a few years ago can't run this on max.
Not a deep comparison of the two waveforms, but just one with a +/- 5% difference margin. It shows the waveform of a played track in the scoreboard already, so comparing that shouldn't be hard.
You might get differences greater than that if you compare a compressed MP3 vs something lossless like FLAC.
I don't think so. maybe 2-3%, but not sure.
I have thought about this before (I think I mentioned it when I was new to the forums at some point), but there's a few problems with it.
Firstly, the only way I can see this vaguely working is to reduce the quality of the WAV significantly, down to 8-bit mono at ~20Khz. This would sound dreadful to the ear but
might make a good comparison track.
However we still have three issues at this point: How do we get this data to the server? How exactly do we do the comparison and what do we do if there's 5 seconds of silence at the beginning of one of the tracks?
To elaborate: uploading or downloading even an 8-bit mono file for every song will mean heavy server costs (even compressed, it's going to add up very quickly), Dylan provides all the score server costs FOR FREE once you've bought the game. Expecting him to support this traffic is unreasonable (he could easily add adverts to the scoreboards now they're just HTML, I'm glad he hasn't thought I would understand if he did).
Assuming we get past the upload/download data issue, we then have to spend a significant amount of CPU power on comparing the tracks. Expecting this on the server is again unreasonable, doing it locally will almost certainly require a significant delay before playing the track (although this may only be needed once). There is a potential solution here using OpenCL/CUDA/etc, but none of these technologies are mature or multi-platform enough (OpenCL is barely out of beta with many bugs found every release, CUDA was nvidia only last time I looked), however at some future point this would be feasible as it would be possible to parallelise the comparison test.
Lastly, the comparison will be very, very hard to use with significant amounts of silence at the beginning of the track and difficult to verify with silences at the end. What if there's many blocks near the end and adding 10 seconds of silence allows a gravity drop that wouldn't otherwise be possible for instance. Would you still class the tracks as the same?
Long post, but I think it covers the logistic and programmatic issues inherent with the idea of using a WAV. I'm not saying it's not feasible, just that it needs some further thought.
