Before I dig deeper into analysing mathematical functions, does anyone have an idea (or knows for a fact, maybe) what it might be? Maybe looking at the pictures below will give an idea to some. The upper track is a representation of the 8 bit value in the compressed KSF file. The lower track is the sampled output of the corresponding wave on a Korg T2. They sound similar, but the compressed sample is very "noisy" (as can be expected based on the waveform). Other than that, the two tracks might be skewed, there is no sync cue but I tried to match them based on the patterns I've seen on screen - maybe I've gone completely wrong.
Compressed Trinity Samples
Moderators: Sharp, X-Trade, Pepperpotty, karmathanever
Compressed Trinity Samples
I have stumbled upon the fact that compressed Trinity samples do sound something reminiscent of the original when converted to WAV (for example) bluntly as an 8 bit sample. But the end result should be 16 bits, and a lot cleaner than the 8 bit conversion I get. It has something like a dithering noise to it, but it is not that - I don't quite know what to make of this compression. It does not seem too complex, yet resembling nothing I've seen so far. Additionally it appears that there are several compression schemes used by the Trinity (piano & flute = code 1, DWGS Triangle = code 3).
Before I dig deeper into analysing mathematical functions, does anyone have an idea (or knows for a fact, maybe) what it might be? Maybe looking at the pictures below will give an idea to some. The upper track is a representation of the 8 bit value in the compressed KSF file. The lower track is the sampled output of the corresponding wave on a Korg T2. They sound similar, but the compressed sample is very "noisy" (as can be expected based on the waveform). Other than that, the two tracks might be skewed, there is no sync cue but I tried to match them based on the patterns I've seen on screen - maybe I've gone completely wrong.



Before I dig deeper into analysing mathematical functions, does anyone have an idea (or knows for a fact, maybe) what it might be? Maybe looking at the pictures below will give an idea to some. The upper track is a representation of the 8 bit value in the compressed KSF file. The lower track is the sampled output of the corresponding wave on a Korg T2. They sound similar, but the compressed sample is very "noisy" (as can be expected based on the waveform). Other than that, the two tracks might be skewed, there is no sync cue but I tried to match them based on the patterns I've seen on screen - maybe I've gone completely wrong.
It looks like the compression is some form of differential PCM encoding. Think of the original data as pulling up or pulling down the result, rather than a value that directly reflects the desired signal.
This seems most obvious to see in the second pair of signals. Notice how the first signal starts with a negative value, then the result gets pulled down, then the first signal goes up while the second signal follows upwards, then it follows this pattern for the whole signal.
The third pair shows a simlar pattern. Note how the peak in the center of the result signal is gradually pulled up by the first signal, then a sharp downward value in the first signal triggers a downward move in the second signal.
This also accounts for the approximate 50 percent compression factor between the higher bit resolution result vs. the 8 bit encoded source, I think.
This seems most obvious to see in the second pair of signals. Notice how the first signal starts with a negative value, then the result gets pulled down, then the first signal goes up while the second signal follows upwards, then it follows this pattern for the whole signal.
The third pair shows a simlar pattern. Note how the peak in the center of the result signal is gradually pulled up by the first signal, then a sharp downward value in the first signal triggers a downward move in the second signal.
This also accounts for the approximate 50 percent compression factor between the higher bit resolution result vs. the 8 bit encoded source, I think.
Thanks for the comment xmlguy!
Yeah, that would have been my first guess, too. However, I don't know the threshold for negative values - the differential signal does not seem to move to the negative range (indicated by the X axis here) where there's a fall in the resulting waveform. Also, the little 'flat' at about 2/3d of the piano sample (first picture) does not seem to match - the line in the differential signal should be around 0, not at a distinct positive value. However, since there is also your vote now to look at differential, I might do the actual calculation.
Any other votes, suggestions?
Yeah, that would have been my first guess, too. However, I don't know the threshold for negative values - the differential signal does not seem to move to the negative range (indicated by the X axis here) where there's a fall in the resulting waveform. Also, the little 'flat' at about 2/3d of the piano sample (first picture) does not seem to match - the line in the differential signal should be around 0, not at a distinct positive value. However, since there is also your vote now to look at differential, I might do the actual calculation.
Any other votes, suggestions?
Could it be u-law compression? I'm not familiar with it. A full set of similar compressions indicated by the compression type? AU/SND file format vote, anyone? Would make sense, considering the age the Trinity was developed in.
Having looked at all the Trinity KSF files I have, compression types 0-5 were found (coded on 4 bits in the KSF attribute byte, so theoretically it coud go from 0 to 15). Whatever they are.
Having looked at all the Trinity KSF files I have, compression types 0-5 were found (coded on 4 bits in the KSF attribute byte, so theoretically it coud go from 0 to 15). Whatever they are.
its most proberly the same system as the 01w and its other synths its a 2-1 compression
the kurzweil k250 was the first sampler to impliment it ray kurzeil used picture recognition algo that took a picture and compressed it so it took a picture of the waveform with its loop markers
and then compressed it with an 16 2-1 compression most proberly into 8bits
then the sampler would read this compression which regenerated the picture of the waveform and turn it into digital data that the synth chip could read then its output was sent to a 12bit dac
emu used the same type of trick with the emax the imput sampling is 16bits
its compressed into 8bits then the 8bit compression samples are read into 2 6bit acumulators lsb msb the echip is 16bits but the last 4 bits are discarded from the echip and it only sends out 12bits from the echip data outputs
i have tried to decode the 8bit samples myself and the results are always noisey and glitchy and very 8bits rather than the prestine sounding ones on the trinity
are you trying to learn this so that you cn get more samples into the trinity with longer sample times
i have been doing long samples and have been truncating them to just under 8 seconds at 32 khz so that they can be used in the korg dss1
they also fit in the trinity but a full multisample comes close to 1.5mb
so you dont get many into the trinity that way
i have a full user wave collection sampled from my prophet vs i have done a full 100 multisounds all with 5 sample multisounds which uses the full 500 sample locations from c2 to c6
i have also been sampling my e4k with cross fade samples to get the efect like the wavestation but with my own samples
the kurzweil k250 was the first sampler to impliment it ray kurzeil used picture recognition algo that took a picture and compressed it so it took a picture of the waveform with its loop markers
and then compressed it with an 16 2-1 compression most proberly into 8bits
then the sampler would read this compression which regenerated the picture of the waveform and turn it into digital data that the synth chip could read then its output was sent to a 12bit dac
emu used the same type of trick with the emax the imput sampling is 16bits
its compressed into 8bits then the 8bit compression samples are read into 2 6bit acumulators lsb msb the echip is 16bits but the last 4 bits are discarded from the echip and it only sends out 12bits from the echip data outputs
i have tried to decode the 8bit samples myself and the results are always noisey and glitchy and very 8bits rather than the prestine sounding ones on the trinity
are you trying to learn this so that you cn get more samples into the trinity with longer sample times
i have been doing long samples and have been truncating them to just under 8 seconds at 32 khz so that they can be used in the korg dss1
they also fit in the trinity but a full multisample comes close to 1.5mb
so you dont get many into the trinity that way
i have a full user wave collection sampled from my prophet vs i have done a full 100 multisounds all with 5 sample multisounds which uses the full 500 sample locations from c2 to c6
i have also been sampling my e4k with cross fade samples to get the efect like the wavestation but with my own samples
Thanks for your comment!jhulk wrote:its most proberly the same system as the 01w and its other synths its a 2-1 compression...
i have tried to decode the 8bit samples myself and the results are always noisey and glitchy and very 8bits rather than the prestine sounding ones on the trinity
are you trying to learn this so that you cn get more samples into the trinity with longer sample times...
I'm only guessing, but it would be good to know for sure whether the same kind of compression was used on the 01w and others (which ones?).
I'm trying to decode compressed Trinity samples for two reasons: 1. to have access to the M1 sample ROM content (many seem to want that and there's not one good source), 2. to understand what happens under the hood and use the principle in my T-series multisoud editor (for importing Trinity samples, if nothing else).
OK, by now I'm fairly sure that this compression is some sort of an A/mu-law (kind of analogue) companding scheme, perhaps with 6 (0-5) different coefficients. I'd need to create a function easy to parameter with these coefficients so that I can verify my theory.
As an illustration, you can see below the (almost) vanilla mu-Law decompression of the 77_SAB_4.KSF sample (saw wave) from the 'M1 Factory' Trinity disk. The ripples at the two extremes suggest that there's a mismatch in the mantissa/coefficient department, but the theory seems to be pointing in the right direction. Off to do some programming on an adjustable compander emulation...

Any opposing views? Or maybe agreeing?
As an illustration, you can see below the (almost) vanilla mu-Law decompression of the 77_SAB_4.KSF sample (saw wave) from the 'M1 Factory' Trinity disk. The ripples at the two extremes suggest that there's a mismatch in the mantissa/coefficient department, but the theory seems to be pointing in the right direction. Off to do some programming on an adjustable compander emulation...
Any opposing views? Or maybe agreeing?

the waveforms like saw are dwgs waveforms made by the additive engine of the dsm1
they are sinus additive so that that waveform looks to vector straight rather than wavy like a true additive saw
but it would be nice to get the correct algo as compressing 16mb of samples into the 8mb of flash ram would be great
i know some one i can ask who worked on the m1 and the wavestation and the oasis system including the z1 and trinity
il ask him what algo they used he might know
they are sinus additive so that that waveform looks to vector straight rather than wavy like a true additive saw
but it would be nice to get the correct algo as compressing 16mb of samples into the 8mb of flash ram would be great
i know some one i can ask who worked on the m1 and the wavestation and the oasis system including the z1 and trinity
il ask him what algo they used he might know
That would be really nice to know. I don't remember anymore whether compressed samples are also written out from the Trinity's FLASH, or only read in? It is conceivable that the Trinity expands data while reading the disk, so it might be uncompressed in the FLASH, already... So I'm not sure whether one can really fit 16MB on the 8MB PBS-TRI... But I sure would like to see - so I carry on!jhulk wrote:il ask him what algo they used he might know
-
- Full Member
- Posts: 119
- Joined: Fri May 21, 2010 6:28 am
- Location: Greece, Athens
- Contact:
-
- Full Member
- Posts: 119
- Joined: Fri May 21, 2010 6:28 am
- Location: Greece, Athens
- Contact:
Having done some testing I can confirm that a compressed sample is written out compressed to the floppy. Which means that we stand a good chance that it resides compressed in the flash memory, too. So jhulk's desire of loading 16 MB worth of samples in the 8 MB flash memory might possibly become reality... Just so that you know.synthjoe wrote:That would be really nice to know. I don't remember anymore whether compressed samples are also written out from the Trinity's FLASH, or only read in? It is conceivable that the Trinity expands data while reading the disk, so it might be uncompressed in the FLASH, already... So I'm not sure whether one can really fit 16MB on the 8MB PBS-TRI... But I sure would like to see - so I carry on!jhulk wrote:il ask him what algo they used he might know