Deprecated: mysql_connect(): The mysql extension is deprecated and will be removed in the future: use mysqli or PDO instead in /storage/content/49/145849/famitracker.com/public_html/forum/classes/dbHandler.php on line 29
FamiTracker
It would probably be helpful if the BPM indicator were accurate to the actual BPM produced by the tempo algorithm, rather than the ideal. Currently it does not take into account the round down.
CSoundGen::GetTempo should probably return:
0.25f * float(int((m_iTempo * 24)/m_iSpeed))
This would more accurately reflect the target BPM produced by m_iTempoDecrement.
More thoughts at: [url=http://famitracker.com/forum/posts.php?id=4715]http://famitracker.com/forum/posts.php?id=4715
Additionally, the output seems to get about 4 samples behind per second of output. I haven't yet managed to determine how the actual engine rate vs samplerate is managed in the engine, so I don't have any idea of the cause.
Yeah rounding the BPM would probably be better, I can add that (or you if you want).
What's more problematic is that tempo 150 issue, that was completely overlooked by me. :(
Using 150 should guarantee the same duration for every row (this is what the documentation says) so I must add some kind of workaround for that.
I don't know what's up with the missing samples. Do you get the same issue with different sample rates? It could be some blip-buffer rounding.
I haven't tried other samplerates, but I have some thought about the NSF standard, which in itself limits accuracy a little bit:
1000000/60 = 16666.6...
Generally NSFs use 16666, so there is 2/3 of a millionth extra per frame that is missing there. At 44100Hz, if each frame is 16666/1000000 of a second, this would result in each second being ahead by about 1.8 samples vs a true 60Hz, which would be about 1000 samples fast at 10 minutes.
So... that kind of inaccuracy that's inherent in NSF due to the resolution of its specified timer is interestingly in the same ballpark at this problem. Obviously it's in the opposite direction (FTM is slow, NSF 16666 is fast) but it shows how much error an integer approximation can accumulate over time, and that there is a limit to the precision you can get within the NSF format. I dunno if Famitracker tries to emulate the 1MHz timer from the NSF spec (I presume it isn't), but it seems there is a small error accumulating somewhere, regardless.
Of course, if you want to approximate 60Hz with NSF you should really use 16667, since it has only half the error. Or maybe 16639 if you want closer to the real NTSC NES rate.
