Akira

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 :/

Advertisement:

StingRay

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

__________________
Makes me sick when I hear all the shit that you say
So much crap coming out, it must take you all day
There's a space kept in hell with your name on the seat
With a spike in the chair just to make it complete

Akira

So how should I interpret them?

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

thomas

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).

__________________
Home: thomas-rapp.homepage.t-online.de
Email: thomas-rapp@web.de

daxb

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.

Akira

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

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.

__________________
Home: thomas-rapp.homepage.t-online.de
Email: thomas-rapp@web.de

StingRay

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

__________________
Makes me sick when I hear all the shit that you say
So much crap coming out, it must take you all day
There's a space kept in hell with your name on the seat
With a spike in the chair just to make it complete

Advertisement:

Hewitson

This isn't true either.

__________________
"The sad thing is that today's computers totally abuse their memory - totally wasteful, you have to wait for the damn things to boot up, just appalling designs." -Sir Clive Sinclair

Akira

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

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.

__________________
Henrik. Programs Amiga demos, iPhone apps, websites, etc.
A1000/512k - A500 2.0/040@28/4M/.5M slowmem/8M/SCSI/CF - A600 portable II 3.1/ACA630/WiFi/CF - 'A1700' 3.1/68060@80/64M/IDE-Fix Express/CF - etc."The difference between PC and Amiga is that 10yo PCs are worth $0. 20yo Amigas are worth a lot, and Amigas that are only 15yo cost a fortune!"
If you like Portal 2, try my >> single player and cooperation maps <<

Akira

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

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.

Akira

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

Advertisement:

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.

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.