Amiga Protracker frequencies
category: code [glöplog]
So if I load an Amiga MOD into any PC-tracker, the samples with finetune +0 get speed=8363. But if I look at the standard note periods at https://www.exotica.org.uk/wiki/Protracker I see that "middle-C"'s period is 428. With PAL clock rate, this becomes 3546895 / 428 = 8287.13 Hz. On NTSC this would be 8363Hz.
I have never observed mods being played differently on PAL amigas or PC trackers, so can someone explain why the +0 finetune speed for samples is 8363Hz and not 8287Hz? Does Protracker have different note-to-period tables for PAL and NTSC amigas?
I have never observed mods being played differently on PAL amigas or PC trackers, so can someone explain why the +0 finetune speed for samples is 8363Hz and not 8287Hz? Does Protracker have different note-to-period tables for PAL and NTSC amigas?
8287Hz (sometimes called "PAL") is the correct middle-C rate for .MOD on Amiga, while 8363Hz ("NTSC") is the default middle-C rate for most trackers in the PC world.
Ideally, import of Amiga MODs in a PC tracker should tune the samples to a middle-C frequency of 8287Hz, but only if it can for sure identify this module as coming from the Amiga world. Loads of PC trackers could export to .MOD, and they used 8363Hz middle-C rates.
Fun fact:
The Ultimate Soundtracker on Amiga uses a period table whose values are tuned for NTSC machines, while the program itself is meant for PAL machines. The later trackers on Amiga kept this NTSC table (NoiseTracker, ProTracker, etc). This is where you get the seemingly random 8287Hz value from (period 428 would actually be 8363Hz on an NTSC machine!).
Ideally, import of Amiga MODs in a PC tracker should tune the samples to a middle-C frequency of 8287Hz, but only if it can for sure identify this module as coming from the Amiga world. Loads of PC trackers could export to .MOD, and they used 8363Hz middle-C rates.
Fun fact:
The Ultimate Soundtracker on Amiga uses a period table whose values are tuned for NTSC machines, while the program itself is meant for PAL machines. The later trackers on Amiga kept this NTSC table (NoiseTracker, ProTracker, etc). This is where you get the seemingly random 8287Hz value from (period 428 would actually be 8363Hz on an NTSC machine!).
Quote:
8287Hz (sometimes called "PAL") is the correct middle-C rate for .MOD on Amiga
It's perhaps worth stressing that "correct" in this context means "correctly out of tune". :)
This is however an excellent opportunity like the whole 432 vs 440 Hz business to do a youtube chan... 'mod.elysium in HEALING 8287.13 Hz' :D
The 436 Hz you get from using one of these trackers on a PAL Amiga is an excellent compromise!
But why Elysium demo sounds the same as the elysium.mod played in impulse tracker?
The difference should be a small fraction of a semitone, so it's quite subtle.
So this basically means I've been listening to amiga mods with wrong sample pitches for my whole life :O jesus christ
(log(8363/8287)/log(2))*12=0.158047689527 so about 15 cents too high pitches than what the artist meant
Those two YouTube videos you posted aren't 16 cents apart tho, this would be a noticeable difference if you played them directly back to back or over each other, and at least according to my ears there isn't one.
just my 2 cents, not sure if it is relevant: to have some "objective" frequency, you could try to play some defined note on the tracker and measure the tuning with an actual tunig device (like a separate guitar tuner or a tuner app for a smartphone). Depends on what you finally want to do. I actually did this recently to make some basic bass track for guitar practice.
Observation: I set sample speed=8363 in Schism Tracker. I load the .it to OpenMPT, convert to mod, and the resulting sample has finetune +1. When loaded again to Schism, sample has speed=8413. If the sample speed was initially 8287, then after mod conversion the speed in schism is 8363. :D
So it looks like different trackers behave differently regarding this issue. Specifically my interpretation is that Schism uses the NTSC period table, but OpenMPT seems to use PAL one.
So it looks like different trackers behave differently regarding this issue. Specifically my interpretation is that Schism uses the NTSC period table, but OpenMPT seems to use PAL one.
That's correct, OpenMPT uses PAL tuning. I think XMPlay also uses it by default, unless you force the "FT2 mode" on MOD playback.
Fasttracker never played Protracker mods (made for PAL at least) in correct tempo. It was very noticable if loops were used :)
PAL Amiga trackers has always played in exact beat per minutes while Fasttracker didn't (afaik).
Beats per minute* :D
Quote:
Fasttracker never played Protracker mods (made for PAL at least) in correct tempo. It was very noticable if loops were used :)
Yeah :facepalm: - always very noticeable when I had to expand from 4 channel to larger channel count and save as .xm..
Quote:
PAL Amiga trackers has always played in exact beat per minutes while Fasttracker didn't (afaik).
This is more likely the other way around. The BPM accuracy of a ProTracker mod is dependant on how the CIA interrupt has been coded within the replay. If its not set to continuous mode then the system will effect the speed, for example the same code on a faster CPU will yield a slightly different BPM.
We found this while working on PT-1210. Run the same mod on two different systems, say a 600 and a 1200, at the same BPM and they drift. We switched the CIA to run in continuous mode and the mod plays the same speed no matter what CPU you are running on.
Quote:
It's perhaps worth stressing that "correct" in this context means "correctly out of tune". :)
Yes, correct as in what the standard is on Amiga for .MOD. It's some cents off, definitely audible.
Quote:
Fasttracker never played Protracker mods (made for PAL at least) in correct tempo. It was very noticable if loops were used :)
It plays in the correct tempo, it's just the pitches being off (more in tune according to A4=440Hz, actually).
(FT2 tempos can be off by a fraction because of rounding errors when converting from BPM to the integer unit the SB mixer and GUS timer uses, but it's the difference in tuning/pitch that breaks drumloop alignment etc)
Quote:
Quote:PAL Amiga trackers has always played in exact beat per minutes while Fasttracker didn't (afaik).
This is more likely the other way around. The BPM accuracy of a ProTracker mod is dependant on how the CIA interrupt has been coded within the replay. If its not set to continuous mode then the system will effect the speed, for example the same code on a faster CPU will yield a slightly different BPM.
We found this while working on PT-1210. Run the same mod on two different systems, say a 600 and a 1200, at the same BPM and they drift. We switched the CIA to run in continuous mode and the mod plays the same speed no matter what CPU you are running on.
Aha! That's very interesting. I have no deeper technical knowledge more than that I've never noticed any drift when I'm recording from my Amiga 1200/030 with Protracker to Cubase ;). Thanks for clarifying!
Quote:
(FT2 tempos can be off by a fraction because of rounding errors when converting from BPM to the integer unit the SB mixer and GUS timer uses, but it's the difference in tuning/pitch that breaks drumloop alignment etc)
That was what I was thinking of. I know that when I used Madtracker 2 in the early 2k it suffered from the same rounding errors making the BPM slightly off (which was fixed in a later version of it..). A totally different topic from this one though since we were talking pitch, not tempo :P
Oh, btw, I noticed that the Win32 conversion of Pt2.3 drifts a bit in tempo though, which I never managed to replicate with real hardware..
(spam, sorry), now that I come to think of it might aswell be the mod2wav function that drifts.. ;)
Quote:
(spam, sorry), now that I come to think of it might aswell be the mod2wav function that drifts.. ;)
Latest version (v1.31)? I fixed some issues with tempo some time ago.
Also remember that you can't really compare the output to real hardware, as every machine will be off by some amount the longer the song is, becuase of small differences in the main crystal oscillator (error is probably <1%), of which every Amiga clock is derived from. I assume WinUAE is ok for comparison.
The PT2 clone is based on the exact nominal PAL master crystal frequency so it should be accurate, given that there's no bugs in the tick handling, of course. It also converts BPM to integer CIA period with rounding error, just like real PT (with the infamous one-tick-delay in the Fxx command), then it converts that value back to "samples per tick" with fraction decimals for maximum accuracy.