Print

[luke]

Hey!

I wrote a bunch of loops in SUNVOX and exported them as .wav files.

I loaded them into milkytracker so that i could write simple square wave leads over fm synth (sunvox) loops.

All the samples i made in sunvox have been automatically finetuned to -28. if I put the finetuning back to 0 then the loops go out of time. Also they dont sound out of tune when at -28?!!
After I noticed this, I checked all my drum samples from sample CDs and they are mostly finetuned to -28 as well, although some are finetuned to -12...I didnt do all this fine tuning myself so im wondering - What is going on?!!!! Any ideas?

by the way all this was playing at 125bpm, speed 6.

[raina]

Somebody else could probably tell you all kinds of interesting facts behind this but in the end, the reason for the -28 in MilkyTracker is because that's how it was in Fasttracker II.

[Deltafire]

This question has been asked before here.

I think it's because FT2 was designed to operate with 22kHz samples, so 44kHz samples have to be played at twice the pitch - hence the -28 detune.  Something like that anyway

[raina]

I thought all samples are treated as 8363Hz and relative note and finetune just multiply that.

[Deltafire]

Yeah, that must be it - it most probably dates back to the Amiga tracker formats.  The Amiga audio hardware (the 'Paula' chip) supported sample rates from 20Hz to 29kHz, so 8kHz must have been a good choice for a middle-C.

[raina]

AFAIR 8363 is also the initial value for sample finetune in Scream Tracker 3.

[jimee]

May I make a supposition?
8363Hz was the finest C that Paula could do.

The frequency of C is about 523.25Hz... Upper octaves are 1046.5, 2093, 4186, 8372Hz ...

So, if we have a sample consisting of 16 bytes, and we play it at 8372Hz, we ear a C.

Now, we have an Amiga's dsp called "Paula", able to replay that sample at some rates defined by the time between each byte (the period), and the time unit is "couples of CPU clock ticks". That dsp is clocked by a quartz at exaclty 7159090Hz (in the NTSC version). To rate at 8372Hz, we need to wait 7159090/8372=855.1 ticks between each byte. Once that number rounded to the unit (nearest even number is 856), the real rate played is :
7159090/856 = 8363Hz!

If trackers was born on a PAL amiga, we'd have chosen a period of 848 ticks, making a rate of 7093790/848=8365Hz... Instead, PAL amigas inherited the 856 period, and played a mistuned C at 8287Hz.

[luke]

WOW! Thanks everyone. that is really interesting. you guys got knowledge!! i need to learn more. i guess i should just ignore it in terms of making music as long as everything is staying in time and in tune. so any C is always a teency bit out of tune in milkytracker but its such a small amount its almost impossible to hear.....(i think, lol!!) and loading the xm into modplug would correct that anyways i guess... thanks again, nice one...i love this shit!!

[luke]

Just to clarify.....8372 divided by 16 (bytes) = 523.25Hz so milkytracker plays a perfect C.
I have to admit Im a little baffled here  !!!

[eightbitbubsy]

Sorry for bumping this thread, but I have some stuff to add to this topic...

8363Hz was the finest C that Paula could do.

8373 should be possible and is closer to 8372 than 8363.

7159090Hz/855per = 8373Hz (NTSC)
7093790Hz/847per = 8373Hz (PAL)

To rate at 8372Hz, we need to wait 7159090/8372=855.1 ticks between each byte. Once that number rounded to the unit (nearest even number is 856), the real rate played is :
7159090/856 = 8363Hz!

Rounded to the nearest even number? There are both odd and even numbers in the ProTracker/Ultimate Soundtracker period table. This is what makes me believe 8373Hz is possible (NTSC: 855 - PAL: 847), do you have any source for this?