Sample Frequency of ProTracker note F-3?
category: offtopic [glöplog]
Does anyone know the exact sample frequency of note F-3 is in ProTracker? I think it must be around 22050 Hz (half of 44100 Hz), but there seems to be a slight difference when comparing back?
According to the magic formulas it's 22168,09125 Hz.
Code:
(For a PAL machine)
7093789.2
SampleRate = --------------
Period * 2
Period table:
C-1 to B-1 : 856,808,762,720,678,640,604,570,538,508,480,453
C-2 to B-2 : 428,404,381,360,339,320,302,285,269,254,240,226
C-3 to B-3 : 214,202,190,180,170,160,151,143,135,127,120,113
that would explain why the samples I'm doing a just a tiny bit faster than when they are 44100 Hz.
Cheers CCE, will give that a whirl.
Cheers CCE, will give that a whirl.
for the lazy fucks (like me), who doesn't want to bother with the formula:
PAL NTSC
C-2 8287 8363
C-1 4143 4181
C#1 4389 4430
D-1 4654 4697
D#1 4926 4971
E-1 5231 5279
F-1 5542 5593
F#1 5872 5926
G-1 6222 6279
G#1 6592 6653
A-1 6982 7046
A#1 7389 7457
B-1 7829 7901
C-2 8287 8363
C#2 8779 8860
D-2 9309 9395
D#2 9852 9943
E-2 10462 10559
F-2 11084 11186
F#2 11744 11852
G-2 12445 12559
G#2 13185 13306
A-2 13964 14092
A#2 14778 14914
B-2 15694 15838
C-3 16574 16726
C#3 17558 17720
D-3 18667 18839
D#3 19704 19886
E-3 20864 21056
F-3 22168 22372
F#3 23489 23705
G-3 24803 25031
G#3 26273 26515
A-3 27928 28185
A#3 29557 29829
B-3 31388 31677
PAL NTSC
C-2 8287 8363
C-1 4143 4181
C#1 4389 4430
D-1 4654 4697
D#1 4926 4971
E-1 5231 5279
F-1 5542 5593
F#1 5872 5926
G-1 6222 6279
G#1 6592 6653
A-1 6982 7046
A#1 7389 7457
B-1 7829 7901
C-2 8287 8363
C#2 8779 8860
D-2 9309 9395
D#2 9852 9943
E-2 10462 10559
F-2 11084 11186
F#2 11744 11852
G-2 12445 12559
G#2 13185 13306
A-2 13964 14092
A#2 14778 14914
B-2 15694 15838
C-3 16574 16726
C#3 17558 17720
D-3 18667 18839
D#3 19704 19886
E-3 20864 21056
F-3 22168 22372
F#3 23489 23705
G-3 24803 25031
G#3 26273 26515
A-3 27928 28185
A#3 29557 29829
B-3 31388 31677
I've found he calculation works great, but the amiga uses weird base frequency. This means when samples are bounced down, the don't quit e fit a chip sample rate, I.e wave length of 128 or 256 bytes!_
The values are weird because everything is derived from the video clock, which is why there's a slight difference in pitch between PAL and NTSC machines.
The values are also weird because they contain hand-corrected values / typos. If you want to read some mind-boggling stuff, read this document:
http://resources.openmpt.org/documents/PTGenerator.c
http://resources.openmpt.org/documents/PTGenerator.c
Would using a more exact period table really "break" (I assume play out of tune) modules, as suggested in that document?
It could easily break synchronized riffs and loops, and depending on the octave, a few Hz off can create more or less drastic effects.
F-3: 3546895/160 = 20864.088 Hz.
F-3 finetune -1 = 3546895/161 = 22030.404 Hz, which is the closest match.
I.e. if you sample a synth (to 22050 on PC) by pressing an F key, you'll almost get it, it will be playing a bit too fast. Use finetune -1 to play it as close as possible.
It's easy to make a correct PAL period table from a formula. The reason it's hard to make a formula to match the period table adhered to by all trackers is that Obarski typed them in from the (then NTSC only) Hardware Reference Manual and doubled the values for lower octaves, introducing rounding errors.
More info on sampling and converting on Coppershade.
F-3 finetune -1 = 3546895/161 = 22030.404 Hz, which is the closest match.
I.e. if you sample a synth (to 22050 on PC) by pressing an F key, you'll almost get it, it will be playing a bit too fast. Use finetune -1 to play it as close as possible.
It's easy to make a correct PAL period table from a formula. The reason it's hard to make a formula to match the period table adhered to by all trackers is that Obarski typed them in from the (then NTSC only) Hardware Reference Manual and doubled the values for lower octaves, introducing rounding errors.
More info on sampling and converting on Coppershade.
20864 should be 22168. Wrong paste from calculator.
it wasnt pasted from the calculator, found those values on some chiptune forum. i used to render to 44.1khz and play it somehwere around F-3, but this time i had a slower track, and had to convert to the exact rate beforehand (and thought sharing my findings). deeply sorry if there are some wrongly calculated values.
ah you meant your calculator, lol :D
teo: Yeah, I meant my wrong paste. :) I mistakenly took the period value of E-3 from the original PT source period table, then noticed... hey, that's not even close, so took the F-3 period. But the second Ctrl+C didn't take, apparently. Anyway.
absence: technically, all Protracker songs are played off key. That doesn't break them, of course. The pitch of the whole song is just shifted 1/100th of an octave or something. But as you compose you may find that you have to adjust fine-tune to make some tonal (melody, chords or bass) instruments "like each other" (harmonize). This is because of rounding errors which are partly in the period table values, partly in the hardware integer precision needing rounding in the first place, and partly in the pitch accuracy of the sampled equipment and any detune etc effect present.
Having a drum loop sample playing too fast or slow could make a song sound a little more off, but still not "break" it. But it has a second variable, drum machine tempo vs. computer timer accuracy - timer values don't give f.ex. 120.000 bpm. So you sample and listen. A few Hz off will still work, if a standard period table (no matter if it's slightly off) is adhered to. Then you will get no surprises for drum loops at least, simply because you will have listened and adjusted using standardized timer values and period values.
absence: technically, all Protracker songs are played off key. That doesn't break them, of course. The pitch of the whole song is just shifted 1/100th of an octave or something. But as you compose you may find that you have to adjust fine-tune to make some tonal (melody, chords or bass) instruments "like each other" (harmonize). This is because of rounding errors which are partly in the period table values, partly in the hardware integer precision needing rounding in the first place, and partly in the pitch accuracy of the sampled equipment and any detune etc effect present.
Having a drum loop sample playing too fast or slow could make a song sound a little more off, but still not "break" it. But it has a second variable, drum machine tempo vs. computer timer accuracy - timer values don't give f.ex. 120.000 bpm. So you sample and listen. A few Hz off will still work, if a standard period table (no matter if it's slightly off) is adhered to. Then you will get no surprises for drum loops at least, simply because you will have listened and adjusted using standardized timer values and period values.
Grmf, this is info I needed about four weeks ago :S
Photon: I asked because I wonder if it was "necessary" for Protracker to inherit the inaccurate Soundtracker table in the first place. I can see that modern, carefully adjusted Protracker mods would suffer if the periods changed at this point, but mods from before Protracker introduced fine tuning in 1990 never seemed that well-tuned to me to begin with. Better safe than sorry I guess, though I'm sure the guys analysing the table were at least a bit sorry. :D
How do I calculate such frequencies in PC multi-channel trackers like Milkytracker or FT-II?
mccnex: Very carefully.
Yeah, thanks, mate, very helpful answer.
Anyone?
Anyone?
you just google it, very carefully.
thanks @grogon