pouët.net

Hi.

I'm trying to convert samples to .iff / 8bit to use them in a mod.
But I want to write the mod in milkytracker.

As far as I understand you can only use three octaves in an amiga-mod and you have to resample your samples to the right frequencies.

I'm following hoffmans guide from his talk at Revision, but something seems to go wrong.

#1 Use 44khz 16-bit source samples
Check

#2 Convert to mono
Check

#3 Apply pre-processing
Check

#4 While still at 16-bit, resample to required frequency
-> Required frequency is for example 11744 für F#-2

=> After doing #4 the sample is much longer and sounds much lower. Is this correct?
=> Problem is that a longer sample needs more space and the samples have to be under 64kb I guess.
=> Another problem is that the sample sounds like crap after downsampling.

So my question. How can I convert a sample to amiga-iff?

Heres a test-sound:
https://www.dropbox.com/s/bn2ktbsf8c37x11/TestChord.wav?dl=0

Please help. :o)

The "very" old Sound Forge 4.5 is the last version that loads / saves Amiga .iff files, it runs perfectly fine in Windows 7 but you need a newer version to resample and EQ your source file before saving it to .iff. At least that's how I've done it in the past.

Quick'n dirty Example

No, you probably didn't actually resample the sample but merely changed its sampling frequency. Resampling usually means changing the sampling frequency while keeping the pitch.


Actually your sample will get shorter. Of course, if you simply lower the sampling frequency without resampling the sample, it will sound deeper and longer, but will still take exactly as much space as it did before.


This is of course always an integral part of downsampling. :) Some samples survive the process in a better shape than others. It also depends on your resampler, not every resampler will give you satisfying results.
Also remember that the final sound very much depends on the type of interpolation used in the tracker. On the Amiga, you don't have any kind of interpolation, so a lot of aliasing is introduced, which gives you a lot of missing high frequency content that went away when resampling the sample to a lower sampling frequency.

Your example sound, after resampling with r8brain-free: Download me beautifull

You can try SoX. A command line tool to convert to a lot of formats.

You can find it even for Amiga OS on aminet.

Thanks for your help to all of you. :o)

Another problem:

When I load .iff-samples to milkytracker I can't play them. Their waveform is visible in the sample-editor but there is no way to hear them or edit hearable notes in the patterns.

Any idea why?

Hey Gaspode, I wrote a little Sox GUI which you can drag and drop .wav files onto the form and it will create an 8SVX version (raw) based on your conversion settings.

It's not great, but it works. If your regional settings use , for decimal separators, switch it to . instead (yeah I know, never got around to fixing that)

https://dl.dropboxusercontent.com/u/11843415/Wav2Amiga.rar

gaspode: Random thoughts:
- Sample default volume is set to 0 for some reason?
- Sample has an inaudible loop right at the start?
If you work in MilkyTracker anyway, there's no reason to use IFF. Just stick to WAV. It doesn't make a difference to the sample.

»Just stick to WAV. It doesn't make a difference to the sample.«

Yeah, but you cannot play the mod in ProTracker afterwards.
All samples sound weird if they are in .wav-format.

»Sample default volume is set to 0 for some reason?«

Oh ... you're right ... shame on me ...

That leaves only one problem.

Protracker plays samples written in Milkytracker 2 octaves lower, so that C-4 becomes C-2.
Do you know if there is a possibility to avoid that problem?

@djhoffman: Only mac here, sorry.

Errr, how about nooooo? It doesn't make a difference whether you load a WAV or an IFF sample into MilkyTracker. There is only one way to store samples in MOD files, and this way is independent of whether the sample used to be a WAV or IFF file.
However, I have an idea what's going wrong for you, and it's related to the fact that MilkyTracker is probably not the best tool for writing MOD files: When importing WAV files that have a sampling rate differing from 8363 Hz, such as the 11744 Hz in your original example, MilkyTracker will most likely change the "relative note" value in the Ins.Ed window, so that 11744 Hz (or something very close to it) would be the middle-C. However, the middle-C for MOD files always has to be 8363 +/- finetune, so after importing a WAV sample, simply go to the instrument editor and reset the "middle-C" value to "C-4".

This is not a problem, it's just a different way of looking at things.
Since ProTracker has 3 octaves, they are labelled 1, 2 and 3. Since the XM format has more octaves, they are labelled differently. Middle-C in MOD is C-2, while in XM it's C-4. Since MilkyTracker is first and foremost an XM tracker, it always displays the middle-C like in XM files, not like in ProTracker MOD files (that said, nothing prevents you from using the whole octave range in MOD, but ProTracker won't play it).
So there really is nothing to worry about for you, MilkyTracker will write the correct notes to the patterns. Just take care that the relative note for each sample is C-4, as said in my previous post.

»Just take care that the relative note for each sample is C-4, as said in my previous post.«

Yeah. That solves the problem. Thank you very much. :o)

Actually, to do some nitpicking on my own post, before someone else does it...


This works because the MOD format doesn't store notes in the pattern data, but "periods" (i.e. basically the frequency at which the sample advances). This dates back to the Ultimate SoundTracker, where finetune didn't exist, so it was a really fast way of playing notes without having to convert the note to a period first by means of a LUT or similar. There are 12 bits reserved for the period in every pattern entry, which is enough for most notes, but if you go way down to the lowest octave supported in the XM format, the period requires more than 12 bits. In this case, when saving such a note in Fasttracker 2, the period spills over into the instrument number, so e.g. G#0 00 turns into C#5 10 when saving the file as MOD and reloading it again in Fasttracker 2. Fasttracker 2 quirks are "fun".

It's possible to make a MOD file with MilkyTracker so that it crashes ProTracker or Amiga playroutines, if there are note period numbers that the Amiga program doesn't know about. Specifying note numbers as finetune 0 period numbers is an amazingly stupid thing, and we can only guess why it was never ditched, when they were making changes to the format anyway.

There are many more ways to crash ProTracker, it's not exactly programmed in a defensive style. :)
However, apart from the extra four "M.K." bytes, it is entirely possible to play a file with ProTracker extensions in an older SoundTracker version, so I'm pretty sure backwards compatibility played into this. The whole SoundTracker business is a big mess after all, and there are dozens of versions which add this or that feature, and in the end many of these features accumulated in ProTracker but were present in the oldskool SoundTracker format as well.

If you want to do a .mod for Amiga you can perhaps give a try with Protracker SDL :)

Yes i've been using that 8bitbubsy's Protracker that rez suggested a bit, seems to work nicely, for what i've used this far at least.

Avast doesn't like the look of those binaries, scans OK with ESET though.