Stupid IFF 8SVX sample problem...

[Amiga1992]

I have a ton of samples, mostly coming from the ST-XX disks, and while they run fine in Octamed or Protracker, any other app that supposedly loads 8SVX IFF samples fails with them. I loaded them in a PC converter program and most of these show up as UNKNOWN FORMAT.

How the hell can I fix them all and how? In batch, preferrably.
I tried a sound converter program I found on Aminet but same deal, they show up as UNRECOGNIZED.

Please help :/

[StingRay]

Err, ST-XX samples are usually in RAW format, not 8SVX-IFF.

[Amiga1992]

So how should I interpret them?

OK they are RAW, 8-bit. But what sample rate?
And it is Little Endian, right?

[thomas]

And it is Little Endian, right?

8bits are one byte. There is no endianess in a byte.

The samples are signed (i.e. -128 to 127) and not unsinged (0 to 255).

[daxb]

Originally Posted by Akira

So how should I interpret them?

OK they are RAW, 8-bit. But what sample rate?

In batch it might be impossible because the samples could have different sample rate. In RAW samples there is no header with informations. Try the usual 16kHz for all. SoundFX can do this but also other sound converter.

[Amiga1992]

Yeah let's assume they all have different sample rates (going from 8000 to 16000 Hz from what I have sen): how am I suppose to know or guess this? I will destroy the sample if I choose this wrong.
I really need to try to batch this. Otherwise I have to load them one by one in Protracker and re-save them.

[thomas]

Yeah let's assume they all have different sample rates

They cannot have different sample rates, otherwise they could not be used in Soundtracker and the like. Soundtracker assumes that all samples have the same rate. It plays them at different rates to get different notes.

[StingRay]

Originally Posted by thomas

They cannot have different sample rates, otherwise they could not be used in Soundtracker and the like.

This is not true, of course the samples can have different sample rates. To quote Lars Hamre (Protracker coder):

There are _NO_ standard sample rate for the samples used in modules.
But most often the samples are done on the rate called C-3 (which is
about 16574 Hz if you have a PAL machine). Sometimes drums are sampled
at A-3 (around 28 kHz), and some sounds are at ~8 kHz or anything else
to save space.

[Hewitson]

There is no endianess in a byte.

This isn't true either.

[Amiga1992]

Yes, what Stingray said.
So what, do I just assume they are all at 16Khz or something? They will all be re-pitched to accomodate.
There has to be a way or a tool that works with RAW files ;(

[Rixa]

No tool can guess the sample rate a raw file has been recorded with. I would think that Soundtracker and the like will just pick a certain rate for all. How about you load a raw sample into Protracker and save it in iff 8svx format. Check the rate of the resulting file. Use the same for everything.

Some or all of them will sound 'wrong' as such, but they'll be wrong in the tracker too and are being compensated for in modules by being played slower or faster.

[Photon]

Originally Posted by Hewitson

This isn't true either.

Well, he probably meant bits are not jumbled within bytes, like bytes are within words on PC. Shift left still doubles the byte value, so writing a byte with the value 128 sends a 1 to D7, not D0 on the memory bus, whereas with big-endian insanity data lines are grouped and jumbled differently depending on the size of the data.

Anyway, I think someone had made a huge archive with all* ST-xx samples converted to IFF already? Presumably with the guidelines Stingray quoted.

If you doubt your converters, you can open the samples in a hex-editor or file editor - first four bytes should be the ascii "FORM". But it's not very likely converters made to read IFF files fail if that is so. It's much more likely the files are raw.


Edit: apparently big-endian according to Wikipedia is when the small values come at the end of the longword. You may substitute the endianness terms in my post with whatever term you want, main thing is that Intel uses the weird slash insane method of storing stuff in memory and everyone else uses the sane method. I'll check my records and see what the correct term is.

[Amiga1992]

I'm really fucking confused by all this. Thanks a lot for your help guys, it's not your fault rather than people not following standards when making filetypes :/

I think I will slim this down to a selection of samples and then I will try to convert them by hand. Theoretically if I open them in Protracker and re-save them as IFF they should get the proper header, right?

[daxb]

Originally Posted by Akira

I think I will slim this down to a selection of samples and then I will try to convert them by hand. Theoretically if I open them in Protracker and re-save them as IFF they should get the proper header, right?

Thats a hell of work. So I would first search for st-xx samples in 8svx format. If they don`t exists, use a sampleconverter with a fixed sample rate (e.g. 16kHz). If all fails use the manual method.

[Amiga1992]

The problem is that I can't ook for that unless I open them up with some sort of samplevconveter or something, since Protracker just opens everything fine.
I will give a try to th sample converter with fixed rate

[daxb]

I guess that Protracker just load the sample and don`t care about sample rate (maybe RAW load/playback). E.g. you can load a sample record with 44kHz into PT and it will be played to slow with B-3 note. C-1 to B-3 "notes" just equal samplerate (about 4kHz to 27kHz). PT load each filetype (ascii, binary, ...).

[Rixa]

In the off chance that this will be of help to you, this shell code should convert all files in current directory into wav format using a tool that I think is installed by default in most Linux distributions. It assumes that everything that is not obviously an IFF file is a signed 8-bit mono raw sample recorded at 16574Hz and appends .wav into the output filename.

for file in *; do
if [ "$(head -c4 "$file")" = "FORM" ]; then
sox "$file" "${file}.wav"
else
sox -t raw -r 16574 -b -s -c 1 "$file" "${file}.wav"
fi
done

As discussed above, the rate that the sample has been recorded with can not be deduced from the file and playback rate is determined by the note in the module. I did not read the spec, but also suspect that IFF 8SVX does not record the actual sample rate but an amiga-specific number of ticks between samples. The rate used here is calculated from the C-3 note (214) on a PAL machine like this:

3546895/214 = 16574

But an NTSC machine would play it slightly faster:

3579545/214 = 16726

The only IFF sample on ST-01 is strings6, and converted by sox it becomes the latter so sox may assume NTSC. If you want the NTSC throughout, use 16726 instead of 16574.