VOGONS


About Roland Virtual Sound Canvas 3

Topic actions

Reply 20 of 321, by Stretch

User metadata
Rank Member
Rank
Member

mattw, I have included 2 links to old posts with some info on modding the VST plugin: Roland Virtual Sound Canvas - VST sysex tune-up and Old Sound Canvas VST 1.6 Mod for SC-55 instruments

Win10 - AMD Ryzen 9 3900 - 16 GB - GeForce RTX 2060S - Sound BlasterX AE5-Plus
Win98SE - ASRock 775i65G R3.0 - Celeron 2.2 GHz - 2 GB - GeForce FX5700 - Audigy 2 ZS
Win98SE - Via Apollo Pro Mobo - Pentium II 233 - 256 MB - Voodoo 3 1000 - Yamaha YMF724

Reply 21 of 321, by mattw

User metadata
Rank Member
Rank
Member

@Falcosoft , thanks for the info. I guess is some compatible with "CM-32/64 sound bank" definition, but as you said nothing close to the real device or what Munt is capable to do. I guess same is with TR-808/909 text I found in the VSC Sound Bank - interesting, now Roland has VST that is TR-808 emulator and it's current product I believe it was released this year, but yet they did have some form of TR-808 and even TR-909 included in 1996-1998 release of VSC.

Reply 22 of 321, by mattw

User metadata
Rank Member
Rank
Member

@Stretch

thank you, at the moment, the 2nd post is useful to me, because it shows where in the VST DLL v1.60 the Sound Bank data are embedded. I think to prepare post, were I collect information for all VSC Sound Banks available and especially those that allow direct comparison between their structure - for example "VSC 1.00 Trial" and "VSC 1.20 Retails" Sound bank - they have only 2 different bytes between them. So, even if someone can figure out that slight 2 bytes difference it gives some new information for VSC Sound Bank format structure. Another good candidates for comparison and analysis are "VSC 2.1 Trial" vs "VSC 2.1a Retail" SC-55 Sound bank, etc. I will try to put more details about those all together, including now based on your older post what is packed together with the 3 VST verstions (1.00, 1.01, 1.60).

Reply 23 of 321, by mattw

User metadata
Rank Member
Rank
Member

In this post I want to make list of All VSC Sound Banks that are available and can be used in Format analysis effort:

VSC 1.00 Trial ("VSC55T.EXE") : SC-55 Sound bank "vsc.dat", size: 1,452,448 bytes
VSC 1.00 to 1.20 Update ("v5up120e.exe"): no new Sound bank is included with the update
VSC 1.20 Retail : SC-55 Sound bank "vsc.dat", size: 1,452,448 bytes
More Details about VSC 1.x: https://www.vogons.org/viewtopic.php?p=895386#p895386

VSC 2.1 Trial ("TVSC8821.EXE") :
* SC-55 Sound bank "vsc55.dat", size: 1,592,400 bytes
* doesn't include SC-88 bank as part of the trial version limitations
VSC 2.1 to 2.1a Update ("vsc8821a_updater.exe") : no new Sound bank is included
VSC 2.1a Retail:
* SC-55 Sound bank "vsc55.dat", size: 1,592,400 bytes
* SC-88 Sound bank "vsc88.dat", size: 2,684,568 bytes
More Details about VSC 2.x: https://www.vogons.org/viewtopic.php?p=895413#p895413

VSC 3.00 Trial, based on web-archives of Roland web-site:
* all links are dead, in fact the only version I was not able to find anywhere
* filename "VSC88V3T" and "Tvsc30j.exe" (Japan)
* file size over 6MB suggests at least SC-55 and SC-88 banks were included

VSC 3.20 Retail :
* SC-55 Sound bank "vsc55.dat", size: 1,807,804 bytes
* SC-88 Sound bank "vsc88.dat", size: 2,820,984 bytes
* SC-88Pro Sound bank "vsc88pro.dat", size: 3,965,564 bytes

VSC 3.xx to 3.23 Update (VSC323U.exe) : no new Sound bank is included with the update

VSC 3.23 Retail :
* SC-55 Sound bank "vsc55.dat", size: 1,807,804 bytes
* SC-88 Sound bank "vsc88.dat", size: 2,820,984 bytes
* SC-88Pro Sound bank "vsc88pro.dat", size: 3,965,564 bytes

VSC VST 1.00 : "RVI01.dat" byte-by-byte identical to 'vsc88pro.dat' from VSC 3.23
VSC VST 1.01 : SC-88Pro Sound bank embedded in the DLL:
* byte-by-byte identical to 'vsc88pro.dat' from VSC 3.23
VSC VST 1.60 : SC-88Pro Sound bank embedded in the DLL:
* byte-by-byte identical to 'vsc88pro.dat' from VSC 3.23 ()
* 'Stretch' posted the DLL offsets where it's located (see his post above)
More details about VST:
https://www.vogons.org/viewtopic.php?p=895259#p895259

Reply 24 of 321, by mattw

User metadata
Rank Member
Rank
Member

In this post I want to compare differences between some of the available VSC Sound Banks.

Instead their actual filename, I will use descriptive name - for example "vsc100_sc55_trial", which is self-explanatory and obviously means "SC-55 Sound bank from VSC version 1.00 Trial".

vsc100_sc55_trial vs vsc120_sc55_retail: only 2 bytes difference in the header wrote:

offset 0x10 : 0x30 0x2E 0x39 0x37 0x00 0x00 0x8A 0xC4 0x72 0x7B 0x82 0xE4 0x7F 0x50 0xCC 0x7B
offset 0x10 : 0x30 0x2E 0x39 0x37 0x00 0x00 0x8A 0xC4 0x72 0x7B 0x82 0xC9 0x7F 0x50 0xCC 0x56

vsc210_sc55_trial vs vsc210_sc55_retail: 4 bytes difference in the header at offset 0x00 wrote:

offset 0x00 : 0x52 0x6F 0x6C 0x61 0x6E 0x64 0x20 0x56 0x53 0x43 0x20 0x54 0x2D 0x32 0x75 0x00
offset 0x00 : 0x52 0x6F 0x6C 0x61 0x6E 0x64 0x20 0x56 0x53 0x43 0x35 0x35 0x00 0x75 0x75 0x00

vsc210_sc55_trial vs vsc210_sc55_retail: 8 bytes difference in the header at offset 0x00 wrote:

offset 0x10 : 0x31 0x2E 0x30 0x31 0x00 0xFF 0xFF 0x8B 0x69 0x3D 0x4C 0x9D 0x27 0x94 0x18 0x3C
offset 0x10 : 0x31 0x2E 0x30 0x31 0x00 0xFF 0xFF 0x8B 0x46 0xFA 0xF7 0x6E 0xF8 0x89 0x46 0xF8

vsc210_sc88_retail vs vsc3xx_sc88_retail: different encryption key and thus very different wrote:

useful to compare only after decryption for how sounds/instruments are added

vsc210_sc55_retail vs vsc3xx_sc55_retail: different encryption key and thus very different wrote:

useful to compare only after decryption for how sounds/instruments are added

all VSC 3.x versions have the same banks, as well the VST uses the SC88Pro bank from VSC 3.x and thus not useful for comparison of the file structure.

Reply 25 of 321, by Falcosoft

User metadata
Rank Oldbie
Rank
Oldbie
mattw wrote on 2020-09-23, 03:32:

... I guess same is with TR-808/909 text I found in the VSC Sound Bank - interesting, now Roland has VST that is TR-808 emulator and it's current product I believe it was released this year, but yet they did have some form of TR-808 and even TR-909 included in 1996-1998 release of VSC.

Hi,
Much more likely that you have found the reference text for the GS standard TR-808/909 drum kit that can be found on any SC devices starting from SC-55 at channel 10/Program 25. So no full emulation , just samples for a drum kit.
And TR-808/909 were drum machines released by Roland in 1980/1983

Here is the list of GS standard drum sets (later SC devices of course expanded it)
0 Standard Kit
8 Room Kit
16 Power Kit
24 Electronic Kit
25 TR-808 /909 Kit
32 Jazz Kit
40 Brush Kit
48 Orchestra Kit
56 Sound FX Kit
127 CM-64/CM-32L

Last edited by Falcosoft on 2020-09-23, 05:50. Edited 1 time in total.

Website, Facebook, Youtube
Falcosoft Midi Player + Munt VSTi + BassMidi VSTi topic

Reply 26 of 321, by mattw

User metadata
Rank Member
Rank
Member
Falcosoft wrote on 2020-09-23, 05:35:

likely that you have found the reference text for the GS standard TR-808/909 drum kit that can be found on any SC devices starting from SC-55 at channel 10/Program 25. So no full emulation , just samples for a drum kit.

I see, I really hope, someone that actually have good knowledge about those things will just take "vscdec.c" that I posted, decrypt all the banks from different versions and actually be able to make real sense of them. also, SC-55 ROM dump of its sound bank needs the eyes of someone more knowledgeable than me. it's too bad, there are no publicly available SC-88 and SC-88Pro dumps of their ROM sound bank.

Reply 27 of 321, by mattw

User metadata
Rank Member
Rank
Member
Falcosoft wrote on 2020-09-23, 05:35:
Here is the list of GS standard drum sets (later SC devices of course expanded it) 0 Standard Kit 8 Room Kit 16 Power Kit […]
Show full quote

Here is the list of GS standard drum sets (later SC devices of course expanded it)
0 Standard Kit
8 Room Kit
16 Power Kit
24 Electronic Kit
25 TR-808 /909 Kit
32 Jazz Kit
40 Brush Kit
48 Orchestra Kit
56 Sound FX Kit
127 CM-64/CM-32L

Many thanks, that fully explains it - basically both " CM-64/CM-32L" and "TR-808 /909" text I found are Drum sets. Also, "later SC devices of course expanded it" is essential note, because when I decrypt Sound bank of older VSC version some of those are missing. So, that is also useful how those instruments sets are added to the bank. In any way, I think there is no doubt (at least to me) that my "vscdec.c" can decrypt all the VSC versions Sound Banks - that is very useful, because with the old "sm0n" tool we were limited to VSC 3.x sound banks only and that doesn't allow to compare between different versions of the sound banks.

BTW, I have just tried to use VSC 3.x bank in VSC 2.x and vice-verse and it fails, which suggest to me that contrary to "vscdec.c" that can find the decryption key, Roland hard-coded that key (the same way as "sm0n" tool did require pre-fixed key as input). So, maybe making encyption "vscenc.c" tool would be useful, i.e. re-encrypt that way VSC 2.x to VSC 3.x bank and vice-verse. maybe that will help at least to find out where the un-encrypted Header of the Sound bank ends. I think that idea worth to try and further explore.

Reply 28 of 321, by mattw

User metadata
Rank Member
Rank
Member

OMG, while looking to make more sense of the Sound bank unencrypted header, I noticed another flaw in Roland encryption - due to the nature of the data and the encryption algorithm, as a side effect, the encryption key gets stored in plain text in the encrypted data section at offset 0x50 in the file - epic fail!

So, attaching "vscdecv2.c" - now ultra simple, if you compare to "vscdec.c" - the whole "find_key()" function is gone, because it's just not needed anymore with the aforementioned defect in Roland encryption - we can just read the key instead to search for it.

Attachments

Reply 29 of 321, by mattw

User metadata
Rank Member
Rank
Member

just for fun used SheepShaver to install the Macintosh version - interesting, even VSC 3.x retail distribution comes with VSC 2.1 for Macintosh. So, that makes the only known version for Mac to be 2.1. the sound bank in Mac is called "VscStdSet", but it's actually "vsc88" from VSC 2.x for Windows. that means Mac version doesn't give anything new in term of Sound banks and my list from one of my previous posts, stays the same.

Reply 30 of 321, by mattw

User metadata
Rank Member
Rank
Member

hmm, i found very interesting thread in another forum about reverse-engineering Yamaha TG100. So, after they acquired the raw sound bank data, they did:

sox -t raw -e signed-integer -b 24 -c 1 -r 8000 bank.raw bank.wav

and indeed you can play the wav file and you can hear the sound samples one after another. as far as I understand "-b 24" is because Yamaha use 12bit samples (not 8 or 16 bit ones). Further I found post here:

Re: SCC1 vs Roland SC-55 modules.

that SC-55 uses 12-bit samples as well. However, when i do:

sox -t raw -e signed-integer -b 24 -c 1 -r 8000 vsc.dec vsc.wav

where 'vsc.dec' is VSC Sound bank decrypted with 'vscdec' and play the wav file, then no good sound samples can be heard.

So, another open key question is the format in which the samples are stored in the VSC sound bank. I wonder if something is wrong with the 'sox' command line, i.e. something needs to be changed for VSC or its Sound banks use some "encoding" and need processing before they become wave PCM data.

Reply 31 of 321, by mattw

User metadata
Rank Member
Rank
Member

I made very simple new attack - I wonder how I didn't think about it earlier (I guess my lack of experience working on such tasks), but no one else here suggested it either...

So, I just dump the RAM - after all the Sound bank has to be loaded to the RAM and yes it's loaded unencrpyted, i.e. decrypted by original Roland software, that give some answers:

1. the unencrypted header of the bank is first 0x32 bytes
2. interestingly when Roland decrypt and load the bank to the RAM, the header bytes offset 0x18 to 0x1f are changed compared to encrypted bank - I still cannot make sense of why those 8 bytes are changed and what they mean (and why they are basically "protected" in the encrypted bank)
3. after fist 0x32 bytes, it seems original Roland decryption is identical to what "vscdec" and "vscdecv2" outputs

So, I guess next improvement is "vscdecv3" that can handle the header - even better if I can understand and address what i mentioned in point 2. that will generate unencrypted banks consistent with what Roland software puts in the RAM.

[EDIT] actually, currently, I can confirm only first 4096 bytes, i.e. 4K or "1 page" of RAM that what original Roland software decrypts and loads from the bank in the RAM is identical to what my "vscdec" outputs. Because in x86 the RAM is divided in 4K pages it will be quite an effort to do that with the whole Sound Bank(because even the smallest one is 1.7MB or that takes about 441 "ram pages". I am paranoid if "vscdec" is able to decrypt the whole bank (i.e. if there are no data blocks encrypted with different key), that's why i will try to make that huge effort - let see how much time it will take me.

Last edited by mattw on 2020-09-24, 14:17. Edited 1 time in total.

Reply 33 of 321, by mattw

User metadata
Rank Member
Rank
Member
Cloudschatze wrote on 2020-09-24, 13:43:

In theory, the Roland PCM data is mu-law companded.

many thanks, that could explain it... let me first finish what i mentioned in the "[edit]" of my previous post - just to double-check and make sure the decryption works properly on the whole bank and there are no some blocks of the bank encrypted differently.

Reply 34 of 321, by mattw

User metadata
Rank Member
Rank
Member

I believe I am up to something and I don't believe it's just a coincidence and that it happens immediately after "CM-64/32L.ME" text is decrypred.

So, I am testing with "vsc55.dat" from VSC 3.x - both old "sm0n" and my "vscdec" generate the same file output, but after 422588 bytes and exactly after string "CM-64/32L.ME" is decrypred - no more of the decrypted data can be found in my RAM dumps, i.e. like after that point decryption fails.

Also, there is not a single readable ASCII string after that point - that could be normal, but it could be another proof that after 422588 bytes, what can decrypt those first 422588 bytes cannot decrypt the rest of the data.

Now, I confirm exactly the same thing with "vsc88pro.dat" bank - there it happens after 441425 bytes , because there that is the moment when "CM-64/32L.ME" text is decrypred.

So, at this point I strongly believe that after "CM-64/32L.ME" is decrypted, after that exact point, encryption changes - I am not sure if just the key or the algorithm as well. It really cannot be a coincidence that on 2 banks it happens exactly after "CM-64/32L.ME" is decrypted.

Reply 35 of 321, by mattw

User metadata
Rank Member
Rank
Member

There is no doubt now (at least to me) that after "CM-64/32L.ME" text is decrypred, the Sound samples begin (i.e. definitions of the instruments end and the actual PCM/WAV data begins) and the sound samples are encrypted with new keys/algorithm.

Please, check the attachment and tell me your opinion:

* "ramdump.bin" : 4KB (1 page of RAM) dump at the point when "CM-64/32L.ME" text is decrypred
* "baddec.bin" : same 4KB block, but decrypted with either the old "sm0n" or my "vscdec" tool

* "ramdump.wav" - made with:

sox -t raw -e signed-integer -b 24 -c 1 -r 8000 ramdump.bin ramdump.wav

* "baddec.wav" - made with:

sox -t raw -e signed-integer -b 24 -c 1 -r 8000 baddec.bin baddec.wav

when listen to "ramdump.wav" it's very clear (again at least in my opinion) that is some sound, but listen to "baddec.wav" is just noise.

If you agree with my conclusion, that means VSC sound banks are encrypted in blocks, i.e. 1st block is up to "CM-64/32L.ME" text is decrypred and that we know how to decrypt (double-confirmed by my RAM dump as well that part is decrypted correctly by the old "sm0n" or my "vscdec" tool), after that Sound data begins and they are encrypted with another algorithm. It's possible there are more that 2 blocks as well, but at least 2 we know about at the moment.

By all means, it's not simple... unfortunately...

Attachments

  • Filename
    dec_data.zip
    File size
    13.96 KiB
    Downloads
    13 downloads
    File license
    Public domain

Reply 36 of 321, by mattw

User metadata
Rank Member
Rank
Member

and guess what - the point at which the encryption algorithm changes is defined in the File Header of the Sound Bank at offset 0x28 to 0x2a. So, 3 bytes from the header discovered what they are, the hard way...

Reply 37 of 321, by mattw

User metadata
Rank Member
Rank
Member

found another key fact about point 2. here:

Re: About Roland Virtual Sound Canvas 3

or in other words about "header bytes offset 0x18 to 0x1f" : they seem that important for Roland that they made great effort even between 2 consecutive versions 3.2 Retail and 3.23 Retail to conceal them further. It's very interesting, let me define 4 "letters" for easier explanation:

A. Sound bank files from Roland 3.2 Retail, in the installation files (the "data1.cab" that can be extracted with 'i5comp' tool)
B. Sound bank files from Roland 3.2 Retail as they are installed in the HDD, i.e. in ProgramFiles directory
C. Sound bank files from Roland 3.23 Retail, in the installation files (the "data1.cab" that can be extracted with 'i5comp' tool)
D. Sound bank files from Roland 3.23 Retail as they are installed in the HDD, i.e. in ProgramFiles directory

"A", "C" and "D" are the same, but not "B" - in "B" exactly "offset 0x18 to 0x1f" are changed, i.e. they are changed after the installation to the HDD

again, here:

Re: About Roland Virtual Sound Canvas 3

I already mentioned that 3.23 changed those in memory (when the bank is loaded to the RAM) confirmed by my RAM dump. I guess they consider what 3.2 is doing security flaw and changed in 3.23. So, it's a key observation and also easy to miss, because here:

Re: About Roland Virtual Sound Canvas 3

I said all VSC 3.x have the same Sound Banks, but now it's clear that's true for the files found in the "installer", not for the files when they are "installed". At least in case of 3.2retail. Very interesting...

Reply 38 of 321, by mattw

User metadata
Rank Member
Rank
Member

made a little more progress - based on my analysis it seems "block 2" is encrypted with "mirror image" of the "block 1" key (i am very confident about that) - "vscdecv3.c" taking that into account is attached.

unfortunately, that's not all - it seems after decryption the wave data are unpacked (maybe what @Cloudschatze said mu-law encoded, even i tried some mu-law decoders without success) and also the unpacked block2 data are no longer stored in the RAM linearly as the same sequence like in the soundbank file , but they are rearranged - I guess based on instrument tables, etc information from "block 1".

So, it's quite complicated. My last effort is to find the exact chunk of data from the soundbank file that are stored after "CM-64/32L.ME" is decrypred in memory - that's not simple task, but it will give how packed vs unpacked data look like.

Attachments

Reply 39 of 321, by Cloudschatze

User metadata
Rank Oldbie
Rank
Oldbie

I wonder if companding only applies to the hardware counterparts. I hadn't looked at the sizes of the VSC .DAT files prior to now, but assuming we're still dealing with ~6MB of uncompressed data (as concerns the 1.72MB VSC55.DAT file), there's a greater reduction in size than what 2:1 companding alone would provide. Some variant of 4:1 ADPCM compression instead, perhaps?