SC55 Sound bank of VSC 2.x has "226 Tones + 9 Drumsets". That coincides exactly with what Microsoft GM.DLS file has - i am attaching picture to show that.
....
I am able to find only 217 tones (216 on my picture as I count from 0) - see the attached picture. That's another unexpected thing - maybe I missed something obvious - anyway as next step I will need to compare my list and the list I got from MS GM.DLS to see which 9 "tones" I am missing and why, i.e. where they are to be found in SC55 VSC 2.x Sound Bank.

Hi,
I do not want to be a party killer but you have not found 217 tones. Everything on your picture starting from '169: High Q' are part of the 9 Drumsets and not the 226 tones. If you inspect the names carefully you should recognize the individual drum sounds that make a drumset (such as Hi-hats, Cymbals, Kick drums, Snares, Congas etc.).
According to GM specification (and also in GS) in case of channel 10 every single note represent an individual drum sound, not the same sound/instrument on different pitches.
In GM (and in GS Standard drumset) these individual drum sounds are the following ( they can be reached from note 35 to note 81):

35 Acoustic Bass Drum
36 Electric Bass Drum
37 Side Stick
38 Acoustic Snare
39 Hand Clap
40 Electric Snare
41 Low Floor Tom
42 Closed Hi-hat
43 High Floor Tom
44 Pedal Hi-hat
45 Low Tom
46 Open Hi-hat
47 Low-Mid Tom
48 Hi-Mid Tom
49 Crash Cymbal 1
50 High Tom
51 Ride Cymbal 1
52 Chinese Cymbal
53 Ride Bell
54 Tambourine
55 Splash Cymbal
56 Cowbell
57 Crash Cymbal 2
58 Vibra Slap
59 Ride Cymbal 2
60 High Bongo
61 Low Bongo
62 Mute High Conga
63 Open High Conga
64 Low Conga
65 High Timbale
66 Low Timbale
67 High Agogô
68 Low Agogô
69 Cabasa
70 Maracas
71 Short Whistle
72 Long Whistle
73 Short Guiro
74 Long Guiro
75 Claves
76 High Woodblock
77 Low Woodblock
78 Mute Cuica
79 Open Cuica
80 Mute Triangle
81 Open Triangle

hi Falcosoft,

not a party killer at all, actually very valuable comment. Could you please, help and define what is supposed to be tone, what is supposed to be instrument, because as I mentioned here:

Re: About Roland Virtual Sound Canvas 3

I am confused by the terms used by Roland and Microsoft?

Other than that - you're totally correct '169: High Q' (and all the rest after it) is not in the list from GM.DLS of those 226 "instruments" as Microsoft call them (and Roland call them "tones" in the GUI of VSC).

So, yeah, that spoils my 1-to-1 map between VSC SC55 soundbank and MS GM.GLS. I need to look more into it, but first I guess I need to clear my confusion about the definition of the "tone" (by Roland) and "instrument" (by Microsoft).

Falconsoft, BTW, if the following definition that combines Roland and Microsoft terms, is correct (I've just came to it), then there is no contradiction:

Definition:
* Instruments (from 0 to 127, total of 128)
* Tones: all instruments from all Midi banks, because same instrument number could be different tone (actually different instrument, but it gets really confusing if i say it like that) in different Midi bank

is that makes sense to you?

[EDIT] Actually, it seems to me, what MS calls "instrument", Roland call "Patch Number" and then everything goes in place like this:

{ "Patch Number", "Bank Number } = Instrument (MS) or tone (Roland)

I see no contradiction, but maybe I am missing again something...

OMG, it looks like "block2" data are stored unencrypted in Roland Sound Canvas VA VSTi Plugin - 20 years newer software, but less protected than VSC 1.x from 1996, is that for real?! Also, they are packed the same way I explained here:

Re: About Roland Virtual Sound Canvas 3

Falconsoft, I re-check MS GM.DLS - there is no contradiction they count the sounds that form the drumkits as individual instruments (in MS speak). So, it's still correct statement that both GM.DLS and VSC SC55 soundbank have 226 instruments (MS speak) or 226 tones (Roland speak). So, i guess, what i suggested as definition:

{ "Patch Number", "Bank Number } = Instrument (MS) or tone (Roland)

is kind of correct, but it is not accurate when we talk for drumsets. More correct is that by "tone" Roland mean all different { "Patch Number", "Bank Number } (because it's possible to have the same sound on different bank number) sounds plus all different sounds (or tones) that form a drumset. It's something like that, I believe...

mattw wrote on 2020-09-29, 18:40:

Falconsoft, I re-check MS GM.DLS - there is no contradiction they count the sounds that form the drumkits as individual instruments (in MS speak). So, it's still correct statement that both GM.DLS and VSC SC55 soundbank have 226 instruments (MS speak) or 226 tones (Roland speak)...

No, 226 is not correct if drum sounds are included 😀. If full drum sets are included as individual instruments the correct number is 235. These are the patches/instruments from GM.DLS :
(I have just generated this list with one of my programs directly from gm.dls . As you can see there are 226 real/melodic instruments and 9 full drum sets moreover each drum set contains at least ~46 additional drum sounds, but many are shared between different drum sets)

Also in SC-55 documentation (and in SC-VA documentation as SC-55 Map) you can see the same. MS Soft Synth/GM.dls actually contains the instruments from SC-55 except the MT-32 compatible insteruments at Bank 127 and MT-32 compatible drum set at Channel 10 program 127.

@Edit
Roland itself refers in documentation to tones as instruments (e.g. in parts like 'Instrument maps'). And the instruments in main bank (Bank 0) are usually mentioned as 'Capital Tones', and instruments in other banks as 'Variation Tones'.
But tones/instruments in Roland documentation means mainly melodic instruments. Drum sounds are listed separately in 'Drum set tables'.

Here you can download cut parts from SC-55 mkII documentation (Instrument map + Drum set table):

My list follows the Midi protocol so programs are 0 based (0 -127), but Roland instrument map is 1 based (1 -128)

@Falcosoft :

Many many thanks, I am working hard on making sense of it based on the structure of VSC soundbanks, what I already reversed-engineered of that structure and the excellent information you provided!

So, I believe I made huge progress today and I finally found how the big "block2"where all the sound samples (their WAV/PCM data) are located is structured, i.e. how to tell where each individual sound sample starts and where it ends and effectively cut and extract them.

Please give me some time to automate the process in a small tool - let's see how many "sound samples" it will can count there...In any way that's really huge, because effectively allows us to "patch" the bank and replace a sound, which is the sole goal of it.

Of course, still SC55 ROM structure to get the highest quality SC55 samples is totally an open question - it will be good if someone can give any ideas on that - even how the 3 x 1MB soundbank ROMs of SC55 are supposed to be "stitched" together - currently I just "interleave" them, but I have doubts that is the correct way - when I look at the datasteam it just doesn't feel right, but it's not based on a fact, but on my intuition. So, I could be very well wrong.

@Falcosoft :

correct me, if I am wrong, but MS GM.DLS has 495 WAV/PCM sounds in total, from which those 226 instruments and 9 drum-sets are made?

I counted 529 WAV/PCM samples in VSC 2.x SC55 soundbank - that looks correct to me, after all VSC is both GS and GM and I guess 34 extra WAV/PCM samples is not abnormal.

At least the good news is that I can now extract, unpack and listed to each WAV/PCM sample in VSC 2.x SC55 bank - even better double confirm that I reversed-engineered that correctly comparing with VSC 1.c SC55 bank - luckily VSC 2.x bank has only 1 extra PCM sound compared to VSC 1.x and my current tool give results consistent with that.

Another big OMG, Guys! all the structures I found out yesterday from unencrypted VSC soundbank (VCSSB) are available in Real Hardware SC55 module ROM Dump (dump of IC23 on the PCB)!

So, what (if you follow this thread), I called "block1" from VSCSB and it's encrypted with what I called "1st layer encryption", is actually available in SC55ROM in unencrypted form!! That means currently what seems possible (with very simple tool actually) is making the whole "block1" of VSCSB by converting the corresponding data from the SC55ROM (encrypted or unencrypted since the 1st layer encryption algo is known).

If I figure out how PCM/WAV data are stored in SC55ROM, then making full VSCSB (with encrypted "block1" and "unencrypted block2") from SC55ROM is done and only how to patch VSC to disable "block2" decryption on VSCSB load (that way it will be able to work with unencrypted banks) will be left for full success of this project.

Last, but not least, probably my findings so far, when release some source code that illustrates them could greatly help if someone is interested in making free and open-source emulator of SC55.

ok, now after I understand some of the SC55ROM structures, what I can tell with certainty is that Real Hardware SC55 module has a little over 6MB of PCM/WAV data, but they are stored in 3 x 1MB dumps. So, I guess mu-law compression as @Cloudschatze suggested here:

Re: About Roland Virtual Sound Canvas 3

or some other sort of compression is used for sure.

[EDIT] hmm, in SC55ROM what I call "samples offsets table" looked very similar to VSC, but now after I dig more into it, seems it's different format and so my conclusion that the last sample in SC55ROM is located on address 6MB+ seems wrong at the moment.
[EDIT2] got confused with SC55ROM again - maybe I am tired or maybe it's because Intel x86 is little-endian and what is used in SC55 module is big-endian. maybe for the time being is better to continue with VSC and learn more of the soundbank stucture on Intel x86.

i progressed more in RE of the VSC soundbank format, actually very few remains not fully RE, let me give status update:

1. first roughly segment of 70KB is not yet fully RE - that maybe sound like a big number, but it's actually not, because those are 300 or so chunks of 216 bytes each. So, when one such chunk is fully reversed-engineered the whole segment is done. I don't know what to call those definitions "instruments" or something else (check my discussions with Falcosoft above), but what is obvious in those chunks is they contain name and the names are like "Piano 1", "Honky-tonk", etc

2. then there is another segment of 10K, which RE is not done yet - it contains the Drumsets definitions, except the names of those sets, I did not RE anything more about it

3. All the rest of the VSC is fully reversed-engineered, including where each sound sample starts and ends and how those are convert to playable WAV/PCM data

So, unless 1. and 2 are not super hard to understand, we can say the format is already reversed-engineered on 99%, at least on bytes with known function vs those bytes with yet unknown function.

@Falcosoft:

please, look at the 2 attached list of "things" (i sorted them alphabetically) - i am calling them "things", because i don't know what to call them instruments tones or whatever exactly they are.

So, list1 has 284 unique entries (there were duplicates, but i removed them; with the duplicated it's over 300 entries), list2 has 214 entries.

All metadata related to list2 are very simple and I already reversed-engineered - essentially their metadata contain list of address offsets of the PCM samples (in the PCM data block) from which they are made.

List2 metadata I still don't understand, but hope what is the difference, what those 2 different list represents, will help me to understand.

There are many names from list1 missing in list2, but there are names like "Train" that are in both list.

mattw wrote on 2020-10-02, 16:25:

@Falcosoft: […]
Show full quote

@Falcosoft:

please, look at the 2 attached list of "things" (i sorted them alphabetically) - i am calling them "things", because i don't know what to call them instruments tones or whatever exactly they are.

So, list1 has 284 unique entries (there were duplicates, but i removed them; with the duplicated it's over 300 entries), list2 has 214 entries.

All metadata related to list2 are very simple and I already reversed-engineered - essentially their metadata contain list of address offsets of the PCM samples (in the PCM data block) from which they are made.

List2 metadata I still don't understand, but hope what is the difference, what those 2 different list represents, will help me to understand.

There are many names from list1 missing in list2, but there are names like "Train" that are in both list.

Yeah, it seems both lists have melodic instruments and drum sounds mixed. I'm not sure if either of them is the full list. To tell you the truth even 284 seems to be a small number if we consider that VSC 3 contains even MT-32 compatible bank with 128 unique non GM/GS compatible instruments like Water Bell or Jungle Tune... ( I have not seen them on the list but you can inspect them on VSC 3 interface if you select GS mode and switch to bank 127).

@Falcosoft:

I understand, but there is just nothing more inside neither VSC soundbank , nor Hardware SC55 ROMs - it fact in the list "SC55_Inst_map.pdf" you provided from the manual, there is for example "Piano 3w",but there is just no such thing to be found in SC55 firmware ROM v1.21.

As I mentioned above I now found all Hardware SC55 ROM structure and their corresponding ones in VSC bank. So, excluding "0","f", etc. used for padding, we have the following:

1. several hundreds chunks with size of 216 bytes each, those are "list 1", from those 216 bytes I currently know only first bytes, that indicate the name, but I guess the rest is Midi patches/Midi banks assignment, etc. also, which one is GM, which is GS.
2. several hundred chunks, but less than "list 1", that is "list 2", their size is 60 bytes each - all those 60 bytes, I fully reversed engineered, they are the name plus list of indexes - those indexes point to what i am calling "pcm data address map". That allows everything from "list 2" to be directly extracted as playable WAV sound (i can do that currently)
3. then there are several chunks describing each drumset
4. then is the "pcm data address map" : basically array with format "index, start address(offset), size" of each individual pcm sample
5. all the rest is the pcm samples with resolution 12-bits and encoded as 2-samples in 3bytes (using same algorithm as Yamaha TG100 ROM - see some of my previous posts, when I went in full details about it)

and that's it - there is just nothing more there!!

Also, let me list the differences (I found so far) in the above 5 points between Hardware SC55 ROM and VSC:

A. in VSC the names are "null-terminated" (like in C language), in SC55ROM they are "space-terminated" (i.e. using "0x20" byte to indicate the end of it)
B. all indexes, 16-bit addresses, etc in SC55ROM are Big-endian compared to VSC, for example index 456 in SC55ROM is "01 d5" and "d5 01"in VSC
C. the "pcm data address map" in SC55ROM is different structure (I still cannot make full sense of it), because with VSC we have the whole Sound Bank in RAM, which means we have 24-bit addresses (enough to address the size of a lot more than the whole block2 of pcm data), but in SC55ROM there is no such amount of RAM and so how pcm samples and their offsets are organized in Hardware SC55 is still mystery to me based on the "pcm data address map" in SC55ROM (the addressing could even include something like ROM number as there are 3 rom chips and offset within that ROM), but anyway the point here is I found the bytes from which the "pcm data address map" consist in SC55 ROMs

So, there is just nothing more neither in VSC, nor in Hardware SC55 ROMs - there are not even many of the names mentioned in "SC55_Inst_map.pdf" - Each byte is currently accounted for and each byte is in one of the above categories.

mattw wrote on 2020-10-03, 04:52:

@Falcosoft: […]
Show full quote

@Falcosoft:

I understand, but there is just nothing more inside neither VSC soundbank , nor Hardware SC55 ROMs - it fact in the list "SC55_Inst_map.pdf" you provided from the manual, there is for example "Piano 3w",but there is just no such thing to be found in SC55 firmware ROM v1.21.
...
So, there is just nothing more neither in VSC, nor in Hardware SC55 ROMs - there are not even many of the names mentioned in "SC55_Inst_map.pdf"

Hi,
This is because you use use the 'wrong' SC-55 firmware. As I wrote at the attachment of SC55_Inst_map.pdf that was from the documentation of SC-55 mkII.
This was an upgraded SC-55 with more polyphony (28 instead of 24) and instruments (354 instead of 317).
Later emulations such as MS GM/GS Softsynth, VSC3, SC-55 map of SC-VA are based on the instrument set of SC-55 mkII.
https://en.wikipedia.org/wiki/Roland_SC-55

So e.g. your mentioned Piano 3w can be found only in SC-55 mkII not in original SC-55, but it also can be found in VSC3 at Bank 8 Patch 3 (with 1 based patches).

@Falcosoft:

many thanks again!

I understand now about SC55 vs SC55mkII, but in my "vsc55.dat" from VSC there is no "Piano 3w" - are you sure you're not looking at "vsc88.dat" or "vsc88pro.dat" or maybe it depends on the exact VSC version itself and that makes the inconsistency between us? (I will re-check mine as well, because I changed mixed several version, but in my current "vsc55.dat" there is no "Piano 3w").

@All:
guys, do you know are there SC55mkII (or SC88) ROM dumps available anywhere or know how to make one?

[EDIT] Falcosoft - I sorted it myself:

SC55 Soundbank from VSC 1.x and VSC 2.s has no "Piano 3w"
SC55 Soundbank from VSC 3.x has "Piano 3w"

I was actually lucky I made that mistake, because I don't have SC55mkII ROMS. So, for reverse-engineering with currently only SC55 ROMs available, then SC55 Soundbank from VSC 1.x and VSC 2.x are supposed to be used. I guess what we have is that VSC 1.x and VSC 2.x are SC55-compatible and VSC 3.x is SC55mkII-compatible. Bottom like, SC55 Soundbank from VSC 1.x and VSC 2.x must be compared with SC55ROM - as what I did (by mistake, but this mistakes was at the end right) and not with VSC 3.x soundbank. It's good with discussion with you we got to the bottom of it!

just to add SC55 Soundbank from VSC 2.x and SC55ROM match that much even addresses are similar for the blocks with same function, for example what is at 0x0DEC0 in VSC is at 0x1DEC0 and 0x2DEC0 in SC55ROM - the reason I guess they split it that way in SC55ROM, because of lack of resources and RAM with the hardware module compare to PC emulation.

I have just found out that SC55 program code is actually not dumped as of 2020.
So, IC26, IC27 and IC28 are the 3 x 1MB ROMs in SC55 that correspond to "block2" in VSC Sound bank, i.e. the PCM/WAC sound data. IC23 (based on my analysis) is mostly what is "block1" in VSC Sound bank - you can almost directly convert them into each other. Unfortunately, the firmware itself of SC55 is not dumped - that's IC30. I guess without being able to inspect the code in IC30 it will be kind of impossible to figure out the format of IC26/7/8 and the "pcm data address map" in IC23, which I'm already struggling to understand - the corresponding one in VSC is so easy to make sense of it.

Extremely fascinating work mattw. I'll have to read through it one or two more times to digest everything. Have you tried to look at the jd800 program dump from dbwbp (jd800 waveroms), the guy who dumped them managed to extract the companded waveforms from the JD800? The waveform dumps look pretty similar to the SC-55 (and some a different dump I'm currently looking at). Just from looking at the hex editor contents, it seems there are similarities among JD800, SC-55 and JV80/JV-cards.

@bnz99

I've just looked at the jd800 dump from dbwbp, but it's only 256KB . So, it doesn't seem to contain the waverom data. It looks very differently structured to me compared to IC23 dump of SC-55, which is almost identical to "block1" content of VSC soundbank. It's possible waverom data are encoded the same between JD800 and SC55, but since I don't know anything about how jd800 wavedata were extracted and I cannot extract those from SC55 3x1MB waverom dumps, I just cannot say anything more on this subject, I simply don't know anything more. What I can tell you though - wav data are 2 layers encrypted in VSC and while the 1st layer is easy to remove, the 2nd layer algo is currently unknown - the only way to remove the 2nd layer encryption is to make "ram dump" and extract "block2" from there where Roland software already decrypted it. Also, that approach, curiously enough works only with VSC 2.x (most of the time I use VSC 2.1a to do it), because both VSC 1.x and VSC 3.x doesn't store the decrypted "block2" of the sound-bank as continuously memory , but scatter those data all over the place in 4KB chunks (1 memory page in Intel x86) and it's almost impossible to reconstruct gathering those pieces.. So, at least in VSC Roland made significant effort to protect their wav data.