| | TWW
Registered: Jul 2009
Posts: 544 |
The old PAL/NTSC question
Hiho
So I was fiddling around with a v-sync'ed / fully stabilized NMI timer in conjunction with IRQ timers so that any screen effect can be controlled by a tight NMI while music is played by a CIA timer (which would allow you to adjust the timing so the player routine is called at the same intervall pr second on all models).
Now I would like to test this and there are a couple of issues which needs to be ironed out (Disclaimer, I know fuck all about music):
#1 - As I understand it by reading this forum, it is not enough to call the routine at a fixed / pr. second interval, you also need to change some of the note / frequency tables in the player routine itself. Can someone confirm and elaborate?
#2 - Given #1 is neccessary, is there any SID available which could be used to test this, where the location and contents of these tables are known so it would be trivial to make said test? |
|
... 7 posts hidden. Click here to view all posts....
|
| | chatGPZ
Registered: Dec 2001
Posts: 11350 |
Speaking of that, did anyone yet come up with a table that shows least quantization errors (by carefully tuning it up or down a bit)? I did this on other platforms (where freq is even less accurate) and it did make a great difference. |
| | acrouzet
Registered: May 2020
Posts: 91 |
Quote: Speaking of that, did anyone yet come up with a table that shows least quantization errors (by carefully tuning it up or down a bit)? I did this on other platforms (where freq is even less accurate) and it did make a great difference.
A friend of mine calculated one. In the end, it doesn't make a difference (at least to my ears) cause the SID has such a fine frequency resolution. |
| | chatGPZ
Registered: Dec 2001
Posts: 11350 |
Yeah, perhaps doesn't matter much for SID. A tiny bit of detune can be good too :) |
| | acrouzet
Registered: May 2020
Posts: 91 |
Quote: I always wondered why the didnt print a small BASIC program in the Manual that calculates the note frequencies... instead of that giant table :)
Precision error?
On the software side however, a common technique for reducing the space taken up by a full tuning table (at the expense of pitch accuracy on high notes) is to find an octave where all the frequency values have a high byte of 01, and store just the low bytes in the player. To get the freq. values back, add back the high bytes of 01 and shift left to get the rest of the octaves.
The most accurate (interval-wise) low bytes in this case are:
0D 1D 2E 40 53 67 7C 93 AB C4 DF FC
To me, this does make an audible difference. Here's an example of these values in use: The Rainbow Test |
| | chatGPZ
Registered: Dec 2001
Posts: 11350 |
I really like the approach LFT used... similar, but more in- between steps (which gives you nice base for linear vibrato and slides) |
| | Fungus
Registered: Sep 2002
Posts: 680 |
The even tempered scale isn't mathematically correct either. For example when tuning pianos they start in the middle and they tune the rest of the keyboard relative to middle A.
Guitar is the same, we often tune some notes a little bit flat in order to make the entire guitar play more in tune when with keyboards as the instrument can't have exact pitches without special frets.
The human ear tolerates a little flatness more than sharpness too. There's lots of interesting studies on it. |
| | McMeatLoaf
Registered: Jan 2005
Posts: 108 |
Quote: Quoting Fungusthe values are actually correct for NTSC as they are taken from the Programmers Reference Guide. Wasn't there this story about HAL Labs Japan and composing tunes strictly by The Book, which came out utterly detuned in the end? :)
Might have been another case, though, like sticking to an early datasheet while SID changes were on the way, too.
But anyways, yes, the difference between NTSC and PAL isn't so big.
Having a different intonation would probably make more of a dent in a given tune.
With "utterly detuned" I can only imagine something in the vein of mistaking the pitch register (the upper 8-bits I'd guess) as an index to some 12-tone equal temperament-based pitch lookup table, which AFAIK was one of Bob Yannes' unimplemented ideas?
As for Rob Hubbard's A440 pitch table, I checked some pitch tables and among the non-one off, *notably* out-of-tune ones, at least mathematically, were Dave Kelly along with Maniacs of Noise's sore A#1, if you don't count Parker Bros who use 8-bit pitch but downpitched 2 octaves (divided by 4, so in effect "10-bit" pitch). Background Music Editor does something similar but in reverse by up-pitching a low-octave table, so it's actually somewhat off-tune. |
| | acrouzet
Registered: May 2020
Posts: 91 |
Okay. So to get back to the original post topic, here are my answers to OP's questions. I'm actually quite interested in the hyper-specific topic of sound chip tuning tables, if you haven't noticed that already.
1. Stone is right in that, within the realm of SID frequency and envelope timings, changing the clock speed of the CPU is effectively like speeding up or slowing down a song, so all SID music will sound "in-tune" no matter what region your C64 is meant for (unless you're playing along on an instrument with a different tuning reference). In fact, the difference in clock speed between regions is so slight that you shouldn't notice a difference unless you have absolute pitch.
2. Try any .sid with player ID "JCH_NewPlayer", "Vibrants/Laxity", or "Rob_Hubbard". Open the .sid in a hex editor and search for "16 01 27 01". Then, starting from "16", select bytes until you've selected 192 of them. The entire tuning table should now be selected. You can now replace that table with a Little Endian Interleaved Table generated with this tool I made: https://docs.google.com/spreadsheets/d/1zjroenEv8O8WT05sCiKdbX_.. |
| | TWW
Registered: Jul 2009
Posts: 544 |
Thanks all for your input and clarifications. Most usefull! I'll give this a try.
Cheers! |
| | Bansai
Registered: Feb 2023
Posts: 48 |
Quoting chatGPZI really like the approach LFT used... similar, but more in- between steps (which gives you nice base for linear vibrato and slides)
Fred Gray on Legend of Kage (and Roadrunner among other tunes) used this scheme with 4 steps between semitones:
L_MICROTONE_FREQTAB
.byte $97,$7E,$6E,$80,$4D,$82,$32,$84 ; B-6 first in row
.byte $1E,$86,$11,$88,$0C,$8A,$0E,$8C ; C-7 first in row
.byte $18,$8E,$29,$90,$41,$92,$62,$94 ; C#7 first in row
.byte $8B,$96,$BB,$98,$F4,$9A,$35,$9D ; D-7 first in row
.byte $7E,$9F,$D0,$A1,$2B,$A4,$8E,$A6 ; D#7 first in row
.byte $FA,$A8,$6F,$AB,$EE,$AD,$75,$B0 ; E-7 first in row
.byte $06,$B3,$A1,$B5,$45,$B8,$F3,$BA ; F-7 first in row
.byte $AC,$BD,$6E,$C0,$3A,$C3,$11,$C6 ; F#7 first in row
.byte $F3,$C8,$DF,$CB,$D6,$CE,$D8,$D1 ; G-7 first in row
.byte $E6,$D4,$FE,$D7,$23,$DB,$52,$DE ; G#7 first in row
.byte $8F,$E1,$D6,$E4,$2B,$E8,$8B,$EB ; A-7 first in row
.byte $F8,$EE,$72,$F2,$F9,$F5,$8C,$F9 ; A#7 first in row
...vibratos and glides scale nicely across the entire pitch range regardless of what your note of interest is. The only downside is the right shift loop burning some rastertime to get to the correct octave.
Regarding detune frequency not scaling properly, earlier Whittaker players (e.g., Quartet, Street Surfer, etc.) specified an absolute +/- SID freq added for vibrato which he had to vary manually from octave to octave, then later on (e.g., Menace) he scaled vibrato up automatically according to octave, but for the note before you jumped from one octave to the next, your vibrato would be shallow--if that's the right word--by almost 2x of what it should be if it were scaled with frequency. Microtone-based tables are a very nice solution to that problem, though I suppose one could interpolate an approximation that was fast and good enough. I need to revisit the code as it's been a while, but if I remember correctly, I think the FAME player might do just that. I know there is special handling for glides with it. |
| Previous - 1 | 2 - Next | |
