jester wrote in 1998: Generally, most trackers read at least some form of raw sample data. If they output to some form of MOD format, they most probably read 8-bit signed data, while some PC trackers (most notably ST3) prefer unsigned samples. The more modern trackers which read 16-bit samples will most probably read some standard headered sample format, which makes conversion (with SOX, for example) pretty easy, so I won't elaborate on it. See your sample editor's or converter's documentation. To convert a sample from one filetype so that you can use it in a tracker for which only raw 8-bit data is suitable, you need:
If necessary, convert the input file to the interchange format, leaving its attributes untouched, if possible (which are the number of bits, channels and sampling rate). Now check to see if the sample will be suitable for the tracker. The main things to look for are sample size in converted state and the sampling rate. A lot of formats still impose limits on the sample size they are willing to deal with. Let's assume you have a limit of 64 KB, i.e. 65536 bytes. And that the tracker (or rather the format) uses 8-bit sample data. Assuming further that you have an input file that is a 16-bit stereo sample, you must divide that sample's size by four to estimate its size when converted so that it suits your tracker('s) format. Four because you divide by two when converting 16 to 8 bits, and by two again because your tracker can only use mono samples (sorry for having forgotten about this before). If the resulting approximate filesize (which is approximate because you haven't accounted for the file header in the calculation) is larger than your limit, write down your result and look at the sampling rate of the input file and the note that it plays at that sampling rate. It could well be that your tracker ('s format) uses a fixed sampling rate to reproduce a C in a certain octave and calculates the sampling rates to use for other notes with reference to this "master C playback sampling rate" (also known as CxSpd). So, if you have a sample with a different sampling rate than this CxSpd, the sample will sound off tune. Remember that the C is THE reference point in the tracker. This is getting too complicated, so I'll give an example. Say I want to convert this great Kurzweil 2000 patch for use in a M.K. tracker, in my case FastTracker 1 (as it imposes even harsher limits than PT). I know that FT1 only uses up to 64KB of a sample and that it uses raw 8-bit signed mono data. I also know that M.K.'s root C is the C-2 and that the playback sampling rate used for that note is 8287Hz for PAL Amiga systems (and I'm in Europe and NTSC Amigas are far too rare for me to care about). That's all I need to know about the target. I know that my source KRZ file is a multi-sample with five 16-bit signed mono samples in it. I use 2PAT (which has been renamed to AWAVE) or another program to tell me the KRZ file's information, which gives me the number of individual samples in the file, their note range, playback sampling rate and the note this rate represents. I then use 2PAT to extract the individual samples to WAV files (actually I already did that and looked up the information in the description file that was generated simultaneously). I like the third of the five samples and want to convert this one. The description reveals that it is 16-bit, mono and plays an A at a sampling rate of 32kHz. I want to tune my sample to C, so I look up appendix I in the MOD-FAQ and find that an A is associated to 440Hz and a C to 261.7Hz. From this I gather that I have to play the sample at ( 32000 * 261.7 / 440 = 19033 )Hz so it sounds like a C. So that's the first thing I do, I change the sample's playback rate to 19033Hz (NOTE: only changing the SPEED of the sample, no resampling involved). In my specific case, the sample I'm converting is not well suited to be played at more than one octave (this is the case with a lot of real-instrument samples). So I allow myself to use only the top M.K. octave (from C-3 to B-3) and resample from 19033Hz to 16574Hz (2 * 8287Hz), which represents a C-3 in M.K.. I do this while still in the 16 bit domain because of the larger precision (aliasing faults are less severe and interpolation is more exact). Then I convert the sample from 16-bit to 8-bit. If the input sample was pretty quiet, I'd probably maximize its volume first, thereby taking advantage of the 16 bits of resolution and reducing rounding errors. If my sample is now still larger than 64KB, I have four choices. I can resample the sample to 8287Hz (no aliasing errors induced, as this is downsampling by an integer) and halve the sample's size at the cost of losing high frequencies. I can also resample to a different note somewhere in between the C-2 and C-3, at the cost of having to transpose the instrument in the M.K. later (i.e. pitch shifting, as the note shown by the tracker isn't correct). My third choice is to crop the sample and find a good loop. My final choice is to apply a volume envelope to the sample and have it fade out fast enough to fit into the limit. Which method I choose depends on the sound I am converting. Quite often a combination of several processes will yield the best results. When I've finished the sample editing process, I either save it in an interchange format (if the editor doesn't support output in raw signed 8-bit mono data) which my converter understands, or I write the sample data to disk in raw signed 8-bit mono style. In the first case, I ask my converter to perform the just described conversion. Assuming I have written a WAV file and want to convert it to FT1-usable, I'd use SOX in the following manner: sox -V infile.WAV -ts8 outfile.SMP <- issued on the command line I could then load outfile.SMP into FastTracker 1. Hope this helps.
|