Korg Forums

Hi. I'm fiddling with DSS-1 disk images. I'd like to have some kind of browser to preview sounds, edit systems and multis... Bref.

Here's the graphic representation (as an unsigned, 8-bit, 44100kHz PCM) of a multi-sampled sine ("DWSIN0 ").




I thought, some of you might recognize this coding scheme. I remember seeing that kind of distorted waveforms on a topic I can't find anymore.

For the sake of completeness, here's a link to the raw data (Sample data seems to start at offset ( 8 + 21 * 16 = 344). I haven't figured out addresses or lengths yet, so there might be padding between the single-cycles!

Get it here

(Also, are there such tools as "graphic interactive audio coding identification tools" out there?)[/url]

Salut fzn!

Perhaps you're alluding to my Compressed Trinity Samples thread?
It looks similar, but it is not the same thing at all - no coding is involved, these are linear values. How did you create this raw file? Using some floppy imaging tool?

What you're looking at is a multisample, meaning that you have several individual samples in one 'file' (in this case seven or eight, each one spreading one octave, if I'm not mistaken).

DSS-1 sample data is 'packed', meaning that to save floppy space they've stuffed two consecutive 12-bit samples in 3 bytes (24 bits). This means that starting from offset 349 (decimal) in your file, you should take the first byte (0x80) and append the high nibble of the next byte (0x0 from 0x09) to get a 12 bit value (0x800). Then you take the low nibble of this byte (0x9) and append it to the end of the next byte (0x81) to get the 12 bit value of 0x819. Take the next byte (0x83) and append the high nibble of the byte thereafter (0x2 from 0x2b) to get 0x832. Remaining 4 bits (0xb) appended to the end of the following byte (0x84) yields 0x84b. Rinse and repeat.

You should get values (all hexadecimal): 800, 819, 832, 84B, 864, 87D, 896, 8AF, 8C8, 8E1, 8FA, 913, 92C, 945, 95E and so on. Yielding a perfectly nice sine wave.

Depending on your floppy imaging tool you might find that after 1024 bytes things get out of whack. This is because the DSS-1 uses sector interleave on the disk, but this seems to be implemented in hardware and therefore imaging tools cannot read data in a consecutive way. After 5 * 1024 bytes the 'skip' pattern should repeat, given that there are 5 sectors in a track on the floppy. In the image file you'll have sectors 1, 3, 5, 2, 4 following each other (1024 bytes each), so you'll have to reorder these blocks to restore the linear stream of data.

Hope this helps.

Woah, thanks synthjoe!

Perhaps you're alluding to my Compressed Trinity Samples thread?

Yep, that was it

It looks similar, but it is not the same thing at all - no coding is involved, these are linear values. How did you create this raw file? Using some floppy imaging tool?

I took CopyQM images as a starting point and converted them into dd images using the ExpandQM program (Open source, found via google)

What you're looking at is a multisample, meaning that you have several individual samples in one 'file' (in this case seven or eight, each one spreading one octave, if I'm not mistaken).

Yup, I guessed so. Thus the plural "sines" in the title

DSS-1 sample data is 'packed', meaning that to save floppy space they've stuffed two consecutive 12-bit samples in 3 bytes (24 bits). This means that starting from offset 349 (decimal) in your file, you should take the first byte (0x80) and append the high nibble of the next byte (0x0 from 0x09) to get a 12 bit value (0x800). Then you take the low nibble of this byte (0x9) and append it to the end of the next byte (0x81) to get the 12 bit value of 0x819. Take the next byte (0x83) and append the high nibble of the byte thereafter (0x2 from 0x2b) to get 0x832. Remaining 4 bits (0xb) appended to the end of the following byte (0x84) yields 0x84b. Rinse and repeat.

Thanks a lot for the very visual explanation.

You should get values (all hexadecimal): 800, 819, 832, 84B, 864, 87D, 896, 8AF, 8C8, 8E1, 8FA, 913, 92C, 945, 95E and so on. Yielding a perfectly nice sine wave.

Well, I get those values, but the work's not finished on that matter ! (Or am I? Example above serializes as 00 08 19 08 32 08 4B 08... I'll be checking Alchemist's source code when I have a moment)

Depending on your floppy imaging tool you might find that after 1024 bytes things get out of whack. This is because the DSS-1 uses sector interleave on the disk, but this seems to be implemented in hardware and therefore imaging tools cannot read data in a consecutive way. After 5 * 1024 bytes the 'skip' pattern should repeat, given that there are 5 sectors in a track on the floppy. In the image file you'll have sectors 1, 3, 5, 2, 4 following each other (1024 bytes each), so you'll have to reorder these blocks to restore the linear stream of data.

Now I couldn't have possibly guess that ! Heaps of thanks!
Having applied your desinterleaving pattern, the data organization looks more obvious. I still run into some inconsistencies tho (Off-by-some-pages adresses, the direction of the error not being constant, nor the very presence of it).

Hope this helps.

It sure does. I'll get back to the code later, this was a nice night

Yep, copyQM files typically have the sector seqence wrong. As to the de-interleaving, you'll have to observe the 'files' in the 'directory' (terms are not quite right, because it is a different structure, but anyways...)

Right after the name you'll find the sectors (off the top of my head I can't recall exactly, but I believe it is on 2 bytes, bit 7 of one of the two indicating upper/lower side of the disk) as they are linked, if a file has more than a certain number of sectors to it then you'll have an identical filename with the continuation (I think one byte somewhere before the name indicates the order of the named file fragment). So you'll have to observe that sector sequence to read the file properly.

I've created some document about the DSS-1 disk format and file structure roughly 10 years ago but I don't have it handy and it was never finished... So it is pretty much the end of my knowledge here - maybe I can specify the offset of the bytes I've mentioned above, but that's probably it.

Good luck!

Maybe you'll like this, I've found it in my notes... Certainly not the absolute truth from Korg, but the result of some extensive experimenting (so prone to errors and ignorance).

Directory:
• starts on C/H/S 0/0/3 (logical address is C/H/S 0/0/2)
• ends at C/H/S 0/1/2 (logical address 0/1/4)
• 8 sectors long (8 Kbyte), holds max. 128 entries (128 x 64 = 8 Kbyte)

each entry consists of 64 bytes and has the following meaning:

0x00 directory entry valid. This byte is 0x00 for all valid directory entries, deleted entries are indicated by a 0xe5 value.

0x01 sequential ID. Given that one directory entry can hold the sector chaining for 24 blocks (see later) only, a file that is larger than 24 K will be described by more than one directory entry, ordered by this byte. For the first (or unique) entry of any file the value of this byte is zero.

0x02 file name checksum. It seems to be calculated as the 8 bit running total of the values in the eight succeeding bytes (i.e. the file name without extension). Some constant ID’s for standard directory items created by DSS-1 during formatting are:
0xb0 SYS1.SPG
0xb1 SYS2.SPG
0xb2 SYS3.SPG
0xb3 SYS4.SPG
0x75 WTBLLIST.LST
0x47 MIDIPARA.SAV

0x03 – 0x0d 8+3 file name in 7 bit ASCII coding(?), both parts are trailing space padded if shorter than the 8+3 mask.

0x0e – 0x0f(?) LSB & MSB(?) of the number of chained blocks contained in the current directory entry. It is set to 0x19 if the chaining extends to an additional directory entry. Byte at offset 0x0f might have some other function, as there can be only 24 (0x18) chained blocks in one entry, and the value 0x19 at 0x0e is used to describe spanning files. Hence using two bytes for this purpose appears to be superfluous.

0x10 – 0x3f the logical sector and track address of each chained block belonging to the directory entry (file), in the order of the chaining. Bit 7 of the sector value corresponds to the head (0 = head 0, 1 = head 1). Given that a directory entry can hold only 24 chained block addresses on these 48 bytes, all files longer than 24 K will have to take up more than one directory entry. These subsequent entries are described by the same name (and checksum), but at offset 0x01 of the directory entry the sequential ID will indicate the order of succession of such spanned directory entries, as described above.