Post by gwenhwyfaer on Jul 26, 2007 2:50:19 GMT
A while ago, and in another place, I wrote this:
Thanks to jook's recent heads-up over there about the TTA format, I've taken another look at it. I was originally going to try applying the TTA compressor to the samples, but happily for me, the first sample I grabbed hold of was one of the Florestan Piano samples...
Happily, because it confirmed some guesses (the one about the sample rate, for example), but also shed some light on other things. The Florestan Piano sample has a different set of bytes at 20..23; instead of spelling 'amtt', they spell 'neno'. Which makes no sense at all, until you combine it with the facts that (i) the number of samples is exactly half the number of bytes - which means that the sample data is uncompressed; and (ii) the compression algorithm appears to be TTA. If you just flip the words, you get 'ttam' and 'none', and the purpose of the bytes becomes quite clear - it's a code describing the compression algorithm used for the sample data!
So, we have a little more information on the header. We also have somewhere to start looking if we want to unpick the compression algorithm the Fusion uses (I'm betting that the m in 'ttam' stands for 'modified', though - an algorithm optimised for encoding streams might well bear being tweaked to record samples). But we also now know that the Fusion can indeed take uncompressed 16-bit sample data - simply start with raw sample data (in signed, 16-bit, big-endian format) and add the 48-byte AFS header, in the format described and with the right values in it.
Which, for me, means I don't need to worry about getting Fusion Convertor working after all. Hurrah!
For reference, it looks as though the first 48 bytes of a .afs file is its header. Counting from byte 0 (the first):
* bytes 0 to 3 are always 53 38 30 73 (S80s)
* bytes 4 to 7 appear to be the number of bytes to follow - ie. the length of the file, less 8 (in big-endian format)
* byte 12 is always 2 - format?
* byte 13 seems to be a mono/stereo flag (0=mono, 1=stereo)
* byte 15 is the root key of the sample as a MIDI key (so G3 is 0x43)
* bytes 16 and 17 are the sample rate in Hz (big-endian, 0xAC44 = 44,100); possibly 18 and 19 are an extension of this, since the Fusion can handle sample rates > 65kHz
* bytes 20-23 are always 0x616D 0x7474 (amtt)
* bytes 28-31 are the sample length in samples (in IXUN format - 0xFA2D 0x0002 -> 2*65536+64045=195,117)
* bytes 32-35 are the loop start and 36-39 the loop end
* bytes 42 and 43 appear to have some significance, but I have no idea what - perhaps preferred starting sample?
* bytes 0 to 3 are always 53 38 30 73 (S80s)
* bytes 4 to 7 appear to be the number of bytes to follow - ie. the length of the file, less 8 (in big-endian format)
* byte 12 is always 2 - format?
* byte 13 seems to be a mono/stereo flag (0=mono, 1=stereo)
* byte 15 is the root key of the sample as a MIDI key (so G3 is 0x43)
* bytes 16 and 17 are the sample rate in Hz (big-endian, 0xAC44 = 44,100); possibly 18 and 19 are an extension of this, since the Fusion can handle sample rates > 65kHz
* bytes 20-23 are always 0x616D 0x7474 (amtt)
* bytes 28-31 are the sample length in samples (in IXUN format - 0xFA2D 0x0002 -> 2*65536+64045=195,117)
* bytes 32-35 are the loop start and 36-39 the loop end
* bytes 42 and 43 appear to have some significance, but I have no idea what - perhaps preferred starting sample?
Thanks to jook's recent heads-up over there about the TTA format, I've taken another look at it. I was originally going to try applying the TTA compressor to the samples, but happily for me, the first sample I grabbed hold of was one of the Florestan Piano samples...
Happily, because it confirmed some guesses (the one about the sample rate, for example), but also shed some light on other things. The Florestan Piano sample has a different set of bytes at 20..23; instead of spelling 'amtt', they spell 'neno'. Which makes no sense at all, until you combine it with the facts that (i) the number of samples is exactly half the number of bytes - which means that the sample data is uncompressed; and (ii) the compression algorithm appears to be TTA. If you just flip the words, you get 'ttam' and 'none', and the purpose of the bytes becomes quite clear - it's a code describing the compression algorithm used for the sample data!
So, we have a little more information on the header. We also have somewhere to start looking if we want to unpick the compression algorithm the Fusion uses (I'm betting that the m in 'ttam' stands for 'modified', though - an algorithm optimised for encoding streams might well bear being tweaked to record samples). But we also now know that the Fusion can indeed take uncompressed 16-bit sample data - simply start with raw sample data (in signed, 16-bit, big-endian format) and add the 48-byte AFS header, in the format described and with the right values in it.
Which, for me, means I don't need to worry about getting Fusion Convertor working after all. Hurrah!