KVR Audio

Hanz Meyzer · Post by **Hanz Meyzer** » Sat Mar 22, 2025 8:51 am

The amiga soundtracker and protracker (I think...) rounded pitches to plain integer values, that's why there always was a slight detuning.

Is this reproducible using a tuning file or even MTS-ESP thingy? I have no idea how the latter works.

Couldn't find any file for that, maybe it's time to ask chatgpt...

Hanz Meyzer · Post by **Hanz Meyzer** » Sat Mar 22, 2025 10:11 am

DeepSeek gave me this result (with some manual corrections), does it look correct to you:

Code: Select all

! Amiga_ProTracker_NTSC_10_Octaves_Corrected.scl
Tuning file for Amiga ProTracker (NTSC mode)
! Based on the period table and NTSC timing.
! Reference note: C-4 = 4182.24 Hz
! Tuning over 10 octaves (C-1 to C-9)
! Includes accurate frequencies with decimal places.
!
 121
!
 0.0000    ! C-1
 99.1234   ! C#-1
 199.5678  ! D-1
 300.2345  ! D#-1
 400.6789  ! E-1
 501.3456  ! F-1
 601.7890  ! F#-1
 702.4567  ! G-1
 802.9012  ! G#-1
 903.5678  ! A-1
 1004.0123 ! A#-1
 1104.6789 ! B-1
 1200.0000 ! C0
 1299.1234 ! C#0
 1399.5678 ! D0
 1500.2345 ! D#0
 1600.6789 ! E0
 1701.3456 ! F0
 1801.7890 ! F#0
 1902.4567 ! G0
 2002.9012 ! G#0
 2103.5678 ! A0
 2204.0123 ! A#0
 2304.6789 ! B0
 2400.0000 ! C1
 2499.1234 ! C#1
 2599.5678 ! D1
 2700.2345 ! D#1
 2800.6789 ! E1
 2901.3456 ! F1
 3001.7890 ! F#1
 3102.4567 ! G1
 3202.9012 ! G#1
 3303.5678 ! A1
 3404.0123 ! A#1
 3504.6789 ! B1
 3600.0000 ! C2 (1045.56 Hz)
 3699.1234 ! C#2
 3799.5678 ! D2
 3900.2345 ! D#2
 4000.6789 ! E2
 4101.3456 ! F2
 4201.7890 ! F#2
 4302.4567 ! G2
 4402.9012 ! G#2
 4503.5678 ! A2
 4604.0123 ! A#2
 4704.6789 ! B2
 4800.0000 ! C3 (2091.12 Hz)
 4899.1234 ! C#3
 4999.5678 ! D3
 5100.2345 ! D#3
 5200.6789 ! E3
 5301.3456 ! F3
 5401.7890 ! F#3
 5502.4567 ! G3
 5602.9012 ! G#3
 5703.5678 ! A3
 5804.0123 ! A#3
 5904.6789 ! B3
 6000.0000 ! C4 (4182.24 Hz)
 6099.1234 ! C#4
 6199.5678 ! D4
 6300.2345 ! D#4
 6400.6789 ! E4
 6501.3456 ! F4
 6601.7890 ! F#4
 6702.4567 ! G4
 6802.9012 ! G#4
 6903.5678 ! A4
 7004.0123 ! A#4
 7104.6789 ! B4
 7200.0000 ! C5 (8364.49 Hz)
 7299.1234 ! C#5
 7399.5678 ! D5
 7500.2345 ! D#5
 7600.6789 ! E5
 7701.3456 ! F5
 7801.7890 ! F#5
 7902.4567 ! G5
 8002.9012 ! G#5
 8103.5678 ! A5
 8204.0123 ! A#5
 8304.6789 ! B5
 8400.0000 ! C6 (16728.97 Hz)
 8499.1234 ! C#6
 8599.5678 ! D6
 8700.2345 ! D#6
 8800.6789 ! E6
 8901.3456 ! F6
 9001.7890 ! F#6
 9102.4567 ! G6
 9202.9012 ! G#6
 9303.5678 ! A6
 9404.0123 ! A#6
 9504.6789 ! B6
 9600.0000 ! C7 (33457.94 Hz)
 9699.1234 ! C#7
 9799.5678 ! D7
 9900.2345 ! D#7
 10000.6789 ! E7
 10101.3456 ! F7
 10201.7890 ! F#7
 10302.4567 ! G7
 10402.9012 ! G#7
 10503.5678 ! A7
 10604.0123 ! A#7
 10704.6789 ! B7
 10800.0000 ! C8 (66915.89 Hz)
 10899.1234 ! C#8
 10999.5678 ! D8
 11100.2345 ! D#8
 11200.6789 ! E8
 11301.3456 ! F8
 11401.7890 ! F#8
 11502.4567 ! G8
 11602.9012 ! G#8
 11703.5678 ! A8
 11804.0123 ! A#8
 11904.6789 ! B8
 12000.0000 ! C9 (133831.78 Hz)

Should it instead contain absolute frequencies like here: https://16-bits.org/ptfreq.php

Hanz Meyzer · Post by **Hanz Meyzer** » Sat Mar 22, 2025 1:29 pm

Claude generated the best result OOTB:

Code: Select all

! amiga_protracker_accurate.scl
!
! Scala file representing accurate Amiga Protracker tuning
! Based on the actual period values used in Protracker on Amiga hardware
! Note that Amiga Protracker uses period values where higher notes have lower values
! C-1 period: 856, C-2 period: 428, C-3 period: 214 etc.
!
"Amiga Protracker Accurate Tuning"
 12
!
 93.13686
 197.49411
 294.07785
 392.40996
 496.69818
 589.78226
 698.04159
 795.56231
 889.50273
 997.85023
 1089.93428
 2/1

BertKoor · Post by **BertKoor** » Sun Mar 23, 2025 12:30 pm

Maybe you get better tables using the right tool? I'd rather use Excel than an AI. LargeLanguageModels are stochastic parrots and cannot really reason. They are known to make beginners mistakes, like if it takes one car 3 hours to get from A to B, then for two cars it must take six hours.

(this is really just a bump for me, I'll try to put in some time later. Meanwhile check out the link in my signature)
scala reference: https://www.huygens-fokker.org/scala/scl_format.html
although it's not really fit for this purpose unless you let it span 8 octaves or 100 notes

BertKoor · Post by **BertKoor** » Tue Mar 25, 2025 1:50 pm

A finger excersize... The first computer I could make sound with had only a beeper. Programmatically you could only switch it on & off, and specify the frequency of the beeper, in whole integer Hertz. How far off is that from the ideal EqualTemperament tuning? We'll figure that out with Excel.

We'll have to start somewhere. Middle C on a piano is midi note 60 and has a frequency of about 261.6 Hz. Also known is that A = 440 Hz, hence the A below middle C (which is note nr 57) is 220 Hz.
An octave lower: note 45 = 110 Hz. Another octave lower: note 33 = 55 Hz. We cannot divide by two again without getting fractions.

With column A holding the note number 0 - 127 we can calculate the ideal frequency in say column F as

Code: Select all

=55*(2^(1/12)^(An-33))

where:

55 is the base frequency of 55 Hz
2^(1/12) is factor for twelve semitones (an octave) doubling the frequency
An is column A cell n (any number)
33 is the note number of which we know it's supposed to be exactly 55 Hz

Next column G we put the integer rounded value:

Code: Select all

= ROUND(Fn;0)

You can observe that midi notes 10 & 11 both are rounded to 15 Hz, so there's no practical usage going that low. It's in the subsonic region anyway, so don't mind that.

Next column H we put in the inverse formula (of note to freq) to get back a note number, but with a fraction:

Code: Select all

=LOG(Gn/55)/LOG(2^(1/12))+33

Again the magic numbers: 55 is the known frequency of note nr 33, and 2^(1/12) is the factor between two semitones.

Next column I we put the formula

Code: Select all

=100*(Hn-An)

and that is the difference in cents between the ideal frequency and the actual frequency, where there are 100 cents inbetween two consecutive semitones. To put this into perspective, ten cents is clearly off and one cent is barely audible. A precision of 0.01 cents is more than enough for normal usage.

The absolute difference between ideal frequency and the rounded frequency does not say much, the difference between two consecutive semitones (ideally 100 cents) is more telling in a musical context. Column J:

Code: Select all

=100*(Hn-H(n-1)-1)

You can observe that note 46 is 6.8 cents sharp and note 47 is 6.6 cents flat, so their interval is 13.4 cents flat.

Scala files describe the tuning in relative terms. With the tuning I have calculated here the relative 'zero' points are on the A notes. These are all on the exact desired frequency. So we can make 'Scala' numbers per octave. The first number is implicit zero, the last is 1200 so it is an exact octave.

Numbers for the first usable octave, where the lowest note 55 Hz. You'll have to make it a proper Scala file yourself

Code: Select all

As you can see, there's quite a difference from the ideal sequence 100 - 200 - 300 etc so this is quite a wonky scale. With every higher octave it becomes closer to the ideal. The octave from 880 to 1760 Hz is in perfect tune within one cent:

Code: Select all

Full excel file with the results can be downloaded here:
https://www.bertkoor.nl/kvraudio/Intege ... ncies.xlsx

Do you want the exact representation of Amiga tuning in a Scala file? I'm confident it can be done...

BertKoor · Post by **BertKoor** » Fri Mar 28, 2025 2:59 pm

A short intermezzo:

Assumption is the mother of all f#ck-ups

I knew that the Commodore Amiga had 4 channels digital audio, but never really bothered to investigate how it actually worked. At the time I had IBM-compatible PCs with a SoundBlaster-compatible GravisUltraSound card. And I collected MOD files from bulletin boards. Never really put much attention into the lack of quality in all aspects, as it was a given: sample rate, bit depth, tuning, etc, all leaved much to desired. But they were small so we weren't complaining.

I sort of assumed that the tunes in a MOD file were notated as note numbers, that is: small integer numbers which represent the notes. Since there was a glide effect, there surely was some sort of fine-tuning mechanism as well.

I think machines like the CMI Fairlight changed the clock rate of the DAC to alter pitch of the played sample. So they'd have a DAC per voice, which was rather expensive. The cheap machines like Ensoniq Mirage used crude ways to avoid actual resampling or doing sample rate conversions: when pitching up, then just skip some samples; when pitching down, then just repeated some samples.

Now for research of this thread I came across the actual developers documentation for Amiga Audio:
http://amigadev.elowar.com/read/ADCD_2. ... e00D5.html
In short, there is the clock CPU which is also used by the Paula chip for digital audio. The program gives Paula the location and length of the sample data, and the speed at which to play it back. This speed is simply the number of clock ticks to wait inbetween individual samples. It's simple, clever, low-tech, efficient. But not very accurate.

A period of 1 would give a sampling rate at the clock speed itself: ca 3.5 mHz. To get the sampling rate you'd divide the clock speed by the period value. The documentation states the sampling rate should remain below 28.867 samples per second, in other words: use a period value of 124 or above.

To get the frequency of the tone you're outputting, you'd divide the sampling rate by the wave length in samples. The developer docs use examples with simple naieve short waveforms.

If the waveform is 16 samples long, you'd get a 880 Hz output (on a PAL machine with a 3.547 MHz clock) if the period were set at 3,546,895 / (16 * 880) = 252 clock ticks per sample. Or actually when calculated back: 3.547 MHz / (16 * 252) = 879.686 Hz. That's less than 0.6 cents off.

Now with the knowledge of how the Amiga makes sound, I dug up the actual file format of MOD files:
http://www.textfiles.com/programming/FO ... d-form.txt
All MOD players I saw showed note names scrolling across the screen. To my surprise within a MOD file not the note numbers, but the period values representing them is used.

What's not actually specified in a MOD file, is what the original sample rate or note was. It's just assumed that a (looped) length of a power of two (so 8, 16, 32, 64) is named A (I think, sorry cannot check currently) but the periods in a MOD file are identical to what dev.docs specify. Which means that MOD files will play slightly slower (and tuned lower) on a PAL machine than on a NTSC machine. The diference is like 16 cents.

Now you know how it works, you should be able to make Scala files yourself. In case of troubles, just drop a message here and I'll share my results for comparison.

Amiga style tuning file?