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
After noticing that wavs exported from Famitracker didn't match their reported BPM I started doing some experiments. I discovered that what is reported as 150 BPM is consistently 150.078 BPM. Now this obviously sounds like a small amount of error but after a minute or so it will be noticeably out of sync with things running at 150 BPM.
It's not hard to work around this, but it's still obviously wrong.
If my maths is correct, this means the engine is actually running at 60.0312Hz when it's reporting 60Hz. I can understand inaccuracy during real-time playback, but to be consistently wrong in an offline render seems like a bug.
Either the engine runs fast by accident, or it runs fast deliberately (perhaps in imitation of the hardware) in which case the engine speed and tempo readouts in the status bar are inaccurate.
I also found that there was no difference between the default NTSC speed and choosing a custom speed of 60Hz. If the engine is running fast deliberately, it might make sense to have the custom speeds run at the actual stated speed.
This would mean that there would actually be a difference between NTSC default and NTSC custom 60Hz, making them both useful options for different reasons. At the moment it's just two ways to select the same thing.
This is not a hard thing to work around, I'm just reporting my observations because bugs are bugs. It did sort of start turning into a feature request though.
I'll continue in this thread since the issue isn't really related to the one in the other thread.
"SirPrimalform: It's true that the BPM value is still rounded and not exactly as displayed, the problem discussed here earlier was of a different kind. The tempo calculation is based on what's possible to achieve when exporting to NSF, rather than having it as accurate as possible. The NSF format (and NES) have limited timing resolution so there will always be some rounding differences.
Running PAL at 60Hz is fine, the difference you see is that the playback speed is derived from the PAL clock (1.66 MHz) instead of NTSC clock (1.79 MHz). The next version of famitracker will base this on the actual NSF clock (1 MHz) instead, so then it should be exactly the same in both cases."
Hmm... but in the case that I was testing, the BPM would have been exactly 150 if the engine was actually running at 60Hz, so it's not being rounded. I understand that tempos like 128.57 will be rounded, but for ones like 150 the readout would be correct if the engine was running at the correct speed.
So I guess the bit I don't understand is why Famitracker is running fast when it says it's running at 60Hz. I know that an NSF is entirely dependent on the player, but when doing a .wav render in Famitracker itself, is there a reason that it runs fast?
Your observation is correct, and the reason is that it's not running at exactly 60Hz. It's closer to 60.0024Hz (calculated from 1000000/16666) which is as close as it's possible to get, according to the NSF specification.
That is not exactly true either, as that speed is also converted to NES cycles; the actual speed should be around 60.0031Hz (if my calculations are correct). This is the part that will change in the next version.
The reason this has been employed inside the tracker is to get it to sound as close as possible to a NSF playing back on the actual hardware.
Perhaps it wouldn't be a bad idea to add a dialog box that shows the exact BPM? (Or at least to the nearest 10 decimal places.) Maybe by clicking on the BPM display in the lower right-hand corner?
I understand that would be desired, but it's slightly complicated and I'm not sure right now how to do it.
I forgot to mention that the down-sampling library (called blip-buffer) also might affect the resulting BPM slightly, since it doesn't guarantee that the selected sample rate will be the actual sample rate. It might be off by a few Hz (depending on the sample rate), and that affects the tempo too.
If 60.0031Hz is correct, then that would result in a BPM of 150.00775, and that differs a bit from SirPrimalform's measured 150.078, which might be explained by the down-sampling step. It should be predictable though, I'll check this a little.
