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
my band is in the studio right now and we've run into a little snag with the wavs ive exported from famitracker.
im wondering how accurate famitrackers bpm counter is in the bottom right corner.
ive read that with a speed of 6, bpms should be accurate. however im wondering for songs with other speeds and tempos for example:
I compose a song at a speed of 5, with a tempo of 160. according to famitrackers bpm counter, it is 192bpm.
however, when the wavs are put on a timeline in protools, and set to a click, my engineer is saying that the bpms arent matching, thereby having to adjust things by hand to tempos like 188.563, and so on...
im wondering if anyone else has run into this problem and if theres a remedy or some math behind it so we arent spending as much time trying to get these tracks lined up correctly in a DAW.
If you want to know what exactly the tempo is, you'll have to examine the exported waveform itself, comparing number of cpu frames to your sampling rate (for instance, 44100 samples per second). The NES hardware runs at about 60.1 frames per second...emulation might be very slightly different.
EDIT: Hmm, what I came up with is that you'd have to multiply the Famitracker tempo by 0.99989453115508488881614943790321 to get the real world tempo. Could be that the DAW itself is a little off. Going by your 188.563 bpm, it seems 0.982098958333 might work instead.
I've always found Famitracker's output to be very precise when I've needed to synchronize it.
1. The BPM refers to the time taken by four rows of the pattern. Make sure your "beat" is 4 rows long.
2. Famitracker's rows are bound to a 60Hz resolution, so that they will fall exactly on a 60Hz frame. This means if your tempo setting is not 150, the exact position of every beat will be jittered slighly to the nearest 60Hz. In the long run the BPM will be accurate, but if you look at individual beats they will appear ahead or behind slightly. This jitter can be quite significant if you're only looking at a short loop. (The general recommendation is to always use tempo 150 and only adjust the speed parameter.)
3. Cak's mention of the NES' ~60.1 frames per second is actually irrelevant because Famitracker does not use the NES' real framerate. Its default framerate it 60Hz, but you can change this in the engine speed setting in the menu. If you need a very specific tempo that does not jitter, you can adjust the engine speed and adjust the tempo to match, e.g. engine speed 58Hz, tempo 145. (Tempo setting should be 2.5 times engine speed.)
Remember: BPM = Tempo * 6 / Speed, and it is the time taken by 4 rows of the pattern.
Well, the error should not compound. There should only be an absolute error of up to 17ms on any particular tick, because any time left over goes into an accumulator to be taken up by the next tick.
Though there may be a precision limit on the accumulator... I'll have to check the code. If it's not precise enough, it could potentially skew the the target tempo (not in a way that is directly related to the 60Hz update- the skew would be the same regardless of engine rate).
Again, though, at tempo 150 there is no error at all. It is stable and accurate with no jitter.
Okay, I took a look at the algorithm. Apparently the length of a row is essentially measured at the resolution of "rows per minute", which does unfortunately result in a loss of precision in some cases. It does remain precise for most speeds where the tempo is 150, but apparently not for all of them.
The rows per minute is calculated as: (24 * tempo) / speed
(i.e.: 4 rows * tempo BPM * 6 / speed)
This calculation is rounded down to the integer, however, which is where the loss of precision happens. For most speeds at tempo 150, they will divide evenly and there is no precision loss by rounding. However, there are some speeds that are relatively prime to 3600 (150*24), like 7 or 11, and these will end up with a "rows per minute" value that is slightly low.
This means tempo 150 speed 7 runs slightly slower than 7 ticks per row, and will actually slip about 2 ticks per minute. An example is attached where you can hear an extra tick appear once every ~30 seconds. This also happens on the very first row so you can hear it there immediately as playback begins.
So... apparently due to the precision of the tempo algorithm, not even 150 tempo is entirely accurate all the time. It's perfect as long as the speed divides 3600 evenly, but there are some speeds that do not. Under 20, these speeds include: 7, 11, 13, 14, 17, 19.
At other tempos you will need to divide 24 * tempo evenly, which is fortunately always fine for these speeds: 1,2,3,4,6,8,12
However, whether you can divide speeds 5,7,9,11,13... depends on the specific tempo. If your tempo is divisible by 5, then 5 will be an accurate speed. Otherwise it will be slightly slow.
As stated above, tempos that are not 150 are subject to jitter as well, but if the speed divides evenly the tempo should still be accurate despite the jitter (individual beats will be off, but overall tempo should be accurate). However, yes, if the speed does not divide evenly, it will be slightly slower.
I might suggest that jsr should implement the round-down for the BPM indicator (to match the real tempo algorithm).
=== SUMMARY ===
1. If you want precise (no jitter) and accurate (at the speed it says) playback rates, use tempo 150 and one of these speeds: 1,2,3,4,5,6,8,9,10,12,15,16,18,20.
2. Other tempos will be accurate (but jittered) if the tempo * 24 divides the speed evenly. Speeds that will always divide 24: 1,2,3,4,6,8,12
3. To eliminate jitter, use a custom engine rate, and a tempo that is exactly 2.5 * the engine rate. This is will be accurate as long as an appropriate speed is chosen (see 2). This limits tempo values to increments of 5.
4. All inaccurate tempos will be slightly slower than advertised, never faster.
Unfortunately the only way to get a truly stable 7 frames is to alternate F04/F03. This is more complicated than the old rule of thumb "use tempo 150 and speed will match frames per row" (which is untrue for speed 7).
To elsh (O.P.): at 160 tempo speed 5 the tempo should be accurate but jittered. I presume you were using a short loop, which makes the effect of jitter more apparent? For a perfect tempo 160 speed 5 just change the engine speed to 64Hz.
Nice...sounds like you've hit on something that is more directly related to elsh's quandary.
To be clear, my test consisted of exporting 10 minutes of a 120 bpm (speed 24) pulse-channel "metronome" and comparing the total PCM samples to what would be expected from a 10 minute WAV file. By the end, it was off by 2791 samples, or 63 ms. It's possible there were added Famitracker ticks, but the RPM shouldn't be rounded in this case, so not really sure what's up.
I dunno at that point. I tried the same myself to test. (I also used V03 and H00 so the phase is consistent. Also tried various tempo/speed combinations, e.g. 150/6 at 5 row tick.) Possibly the engine is leaking ~4 samples per second? I don't really know how the engine actually determines the length of a frame. This is outside the realm of how the tempo logic works (it's not fine grained enough to produce such a fine offset).
thank you rainwarrior and cak for your detailed responses. this is going to help a lot!
also, i didnt mean to throw anyone off with the "tempos like 188.563, and so on..." in the OP. that was just an anecdotal example of whats been happening.
initially some songs will be in time with the metronome for the first 3 minutes, but by the end its off time.
we have firgured out a workaround for this issue, but for future recordings this is valuable info!
In my experience, the BPM is fairly inaccurate (it tends to slow down half a BPM or so when more complex parts are playing), but that's not a big deal. Try beat mapping the track to the wav, or vice versa (Flex Time in Logic or whatever the same feature is called in Ableton to snap all transients to the grid). Any time I export an FTM into my DAW, first thing I do is beat map the session to the 'drums', and it usually ping pongs around within a half a BPM +/- the average BPM.
It sounds like jsr will fix the rows-per-minute rounding, which is a big issue in regard to tempo. The sample leaking may be a different story (since it could be a blip-buffer problem). In that case, it is better to match the external audio to the exported WAV whenever possible. Other workarounds are increasing playback/sample rate to 44105, or trimming out 279 samples per minute.
