VOGONS


About Roland Virtual Sound Canvas 3

Topic actions

Reply 80 of 377, by bnz99

User metadata
Rank Newbie
Rank
Newbie

Sorry, I haven't paid attention on the rom size of the program rom. Just wondering, do you know where in Munt in synth.cpp the bit reordering in the pcm loading code comes from? If that is also some kind of descrambling by shuffling the bits around every 16 bit, I might take a look at how to attack transposition/permutation ciphers as my hunch would be that this then would probably be the general direction how they scramble stuff. Unfortunately, I'm not very knowledgable in both reverse engineering nor cryptography (just some basics). What I didn't pick up from your posts: does the second layer of vsc block2 look (kind of) similar to the hardware rom waveform dumps or is this something completely different?

Reply 81 of 377, by mattw

User metadata
Rank Oldbie
Rank
Oldbie
bnz99 wrote on 2020-10-05, 11:02:

do you know where in Munt in synth.cpp the bit reordering in the pcm loading code comes from?

I don't know from where that code comes from, but my best guess is they had dump of the actual MT-32 firmware and disassemble/reverse-engineer the algo from there, i.e. with looking at the (dis)assembler code.

thanks for mentioning this, because I didn't know MT-32 uses any kind of bit"shuffling" - there is good chance it's similar algo to VSC - I am going to look into that.

As I mentioned few post ago, we don't really have dump of IC30 from SC55, i.e. the actual firmware of SC55 and so getting the algo from there is dead end.

bnz99 wrote on 2020-10-05, 11:02:

I might take a look at how to attack transposition/permutation ciphers as my hunch would be that this then would probably be the general direction how they scramble stuff.

my hunch is the same, i.e. that they use similar algorithms, but please, note I did replace "block2" of VSC soundbank with the one from SC55 ROMs and it fails to decrypt - but read the end of this post to understand why I think it failed - not because it's the wrong algo, but because it's the wrong input size - I did prove that the scrambling depends only on the input size - see below. BTW, let me give you here some main points about making "fake" block2 for experimentation:

* thanks to that we know the encryption/decryption algo for layer1 encryption of "block2" (see my "vscdec.c" - the encryption is the same in reverse), we can change "block2" of VSC soundbank with whatever we want, that way I saw how their shuffling algo does with 1, 2, ..., 8, etc bytes, see:

Re: About Roland Virtual Sound Canvas 3

and

Re: About Roland Virtual Sound Canvas 3

but basically all posts in that series - essentially, I used special input number matrices, that I can see easy how they snuffled the bytes.

* I know the above trick with changing the "block2" works with absolute certainty, because that is how I got decrypted copies of the Soundbanks from VSC 1.x and VSC 3.x - remember, getting decrypted "block2" from RAM dump works only with VSC 2.x. So, in order to get for example "vsc.dat" from VSC 1.x unecnrypted you need to:

- decrypt its block2 layer1 encryption with vscdec.c
- then re-encrypt it with layer1 keys of VSC 2.x soundbank
- replace "block2" of VSC 2.x soundbank with that last one you prepared above

Actually, that was huge stepping stone for me to understand the VSC Soundbank structure, because SC55 soundbank from VSC 1.x and the one from VSC 2.x has only 1 extra PCM sound in "block2" and it's small - if I recall corectly 1105 bytes. So, comparing decrypted "block2" from VSC 1.x and VSC 2.x gave me the first clue how to find what I am calling "pcm data address map".

bnz99 wrote on 2020-10-05, 11:02:

Unfortunately, I'm not very knowledgable in both reverse engineering nor cryptography (just some basics).

I am the same, but yet I did some progress...

bnz99 wrote on 2020-10-05, 11:02:

does the second layer of vsc block2 look (kind of) similar to the hardware rom waveform dumps or is this something completely different?

again, if you look here:

Re: About Roland Virtual Sound Canvas 3

the scrambling algo depends heavily on the size of the input block2 (or part of it) to encrypt/decrypt. So, my hunch are they are the same between SC55 and VSC, but the input size is not the same as VSC, because on PC there is plenty of RAM. So, my hypothesis is they use the same scrambling, but not on the whole "block2" as it seems they do in VSC, but in SC55 they do it on every single WAV sample. if you look here:

Re: About Roland Virtual Sound Canvas 3

point C - the "pcm data address map" is the only real difference I have found so far between SC55 and VSC. So, my guess is that based on SC55 "pcm data address map" they pickup the exact chunk of bytes from "block2" (those 3x1MB ROMs), put in RAM and descrambler. In PC they descrambler the whole "block2" and put unencrypted in RAM, but that is just impossible to do on SC55. That also explains why the "pcm data address map" there is different. The "pcm data address map" with VSC on PC is ultra simple: "index, start address(offset), size" of each individual pcm sample in the "block2" - i still consider finding that fact my greatest success so far, because it allows me to extract each PCM data as playable WAV file - when you hear those sounds, it just gets real you really found out something.

Reply 82 of 377, by Lord Nightmare

User metadata
Rank Newbie
Rank
Newbie

For the Roland LA32 PCM roms, the scrambling is consistent across the MT-32, D-50, CM-32L, LAPC-I, D-10/110, D-20/220, and is:
rawSample = BITSWAP16(rawSample, 15, 6, 14, 13, 12, 11, 10, 9, 8, 5, 4, 3, 2, 1, 0, 7);

This is using the BIT and BITSWAP macros from the older C versions of MAME (this specific code in question was always BSD licensed) and is reproduced below:
// from MAME, 3bsd
#define BIT(x,n) (((x)>>(n))&1)

#define BITSWAP8(val,B7,B6,B5,B4,B3,B2,B1,B0) \
((BIT(val,B7) << 7) | \
(BIT(val,B6) << 6) | \
(BIT(val,B5) << 5) | \
(BIT(val,B4) << 4) | \
(BIT(val,B3) << 3) | \
(BIT(val,B2) << 2) | \
(BIT(val,B1) << 1) | \
(BIT(val,B0) << 0))

#define BITSWAP16(val,B15,B14,B13,B12,B11,B10,B9,B8,B7,B6,B5,B4,B3,B2,B1,B0) \
((BIT(val,B15) << 15) | \
(BIT(val,B14) << 14) | \
(BIT(val,B13) << 13) | \
(BIT(val,B12) << 12) | \
(BIT(val,B11) << 11) | \
(BIT(val,B10) << 10) | \
(BIT(val, B9) << 9) | \
(BIT(val, B8) << 8) | \
(BIT(val, B7) << 7) | \
(BIT(val, B6) << 6) | \
(BIT(val, B5) << 5) | \
(BIT(val, B4) << 4) | \
(BIT(val, B3) << 3) | \
(BIT(val, B2) << 2) | \
(BIT(val, B1) << 1) | \
(BIT(val, B0) << 0))

Keep in mind the actual format the actual data is encoded in is a strange u-law like format which must be converted to PCM, there is a formula to do this as well. The LA32 internally uses a less accurate version of this using an exponential lookup table with linear interpolation between entries.
It can be done with pure integer math and that exponential lookup table, but the way I did it cheated and used floating point math:
for (int smpNum = 0; smpNum < len; smpNum += 2)
{
// parse out one sample
// first descramble the sample, which while stored in big endian,
// has the absolutely bizarre bit order of:
// 15, 6, 14, 13, 12, 11, 10, 9, 8, 5, 4, 3, 2, 1, 0, 7
int16_t rawSample = ( ((uint16_t)(*(ptr+smpNum)<<8)&0xFF00) |
((uint16_t)(*(ptr+smpNum+1)<<0)&0xFF) );
rawSample = BITSWAP16(rawSample, 15, 6, 14, 13, 12, 11, 10, 9, 8, 5, 4, 3, 2, 1, 0, 7);
double floatSample = pow(2.0f,(((rawSample & 0x7fff) - 32767.0f) / 2048.0f));
int16_t pcmSample = (floatSample * 32768.0f * ((rawSample&0x8000) ? -1.0f : 1.0f));
// little endian output because .wav
fputc((uint8_t)(pcmSample&0xFF), out);
fputc((uint8_t)(pcmSample>>8)&0xFF, out);
}

LN

"When life gives you zombies... *CHA-CHIK* ...you make zombie-ade!"

Reply 83 of 377, by bnz99

User metadata
Rank Newbie
Rank
Newbie

@Lord:
thanks for chiming in and giving us this is very useful information. I'll try if we'll maybe have a lucky strike and it is possibly the same descrambling with the other roms as well or some variant of it.
On that note, comparing the munt code and the one you have posted, I'm a little surprised that there is a difference. In synth.cpp, the loop stops at 14 (<15) instead of 15. So I'd guess that bit number 8 from the order array (first bit of the second byte) is missing if I'm not totally wrong.
@Mattw:
Thanks again for this very detailed sum up. That is interesting stuff, because if you look at the waveroms, you can clearly see repeating patterns and block forms, e.g., several bytes with 00 or (59.*5C)* blocks. I'll probably take a more detailed look at those fidings and play around with them later this week.

Reply 84 of 377, by mattw

User metadata
Rank Oldbie
Rank
Oldbie

@Lord Nightmare : many many thanks, especially for the u-law code, because something like that has to be used with SC55 for sure, because the specification states SC55 has 6MB of samples, but the ROMs are 3MB. So, I hope SC55 uses the exact same u-law algo.

I believe the scrambling with SC55 is based on bytes, not bits, but I could be wrong. However, with VSC, when I change X bytes, then exactly X bytes are changed in the RAM dump decrypted data and those X bytes are scattered all over the place, which looks like those bytes position are scrambled, not the byte value itself.

bnz99 wrote on 2020-10-06, 06:36:

if you look at the waveroms, you can clearly see repeating patterns and block forms, e.g., several bytes with 00 or (59.*5C)* blocks.

yes, actually I was just looking at the SC55 dump of IC26 (because at least according to MAME "roland_sc55.cpp" it's the 1st segment of "block2" data loaded to the memory) and those double occurrences of 59 or 63 even at the beginning of the file exactly reminded me to the patterns I saw when doing experiments with fake block2 patterns and VSC, because the scrambling causes multiple consecutive occurrences of the same byte to become much more common event.

[EDIT] there is no doubt, VSC on PC is doing byte scrambling on "block2" as one big whole: the size of the block is 1 278 978 and changing few bytes at its beginning caused one of those bytes be "teleported" at position 1 218 044, i.e. almost at the end, of the decrypted block2 data.

Reply 85 of 377, by yawetaG

User metadata
Rank Oldbie
Rank
Oldbie
mattw wrote on 2020-09-21, 01:10:

I didn't expect this - it took me no time to find Demo/Trial version of VSC-88 v2.1a using Google, the file is called: "TVSC8821.EXE" and even more surprising Roland released version of it for Macintosh as well: "vsc88-21-trial.sit". However, it seems "TVSC8821.EXE" is Win9X only, i.e. v2.x contrary to v3.x has no WinNT/XP support, but it has Mac support that no other version has.

Version 2.2 has Windows 2000 & NT support.

mattw wrote on 2020-09-21, 11:08:
[EDIT] in Roland help files, I found what "TVF": […]
Show full quote

[EDIT] in Roland help files, I found what "TVF":

Time Variant Filter. TVF is a low pass filter that is supplied for each voice. Using TVF requires more CPU power

The time variant filter is basically Roland's standard filter implementation found on nearly all of their PCM synths starting with Roland D70 (which actually gets the filter from one of their samplers). On the actual hardware synths they used different chips depending on the synth model, resulting in different filtering characteristics. The version used on the Sound Canvas is rather meek, whereas the version used on the early JV series is more aggressive (and has two output settings that result in different behaviour) - even though both partially use the same chips. The one from the S-series samplers, D70, MV30 and JD990 is capable of outright earsplitting sounds.

I would expect that the VSC implementation does not sound the same as the TVF filter on an actual Sound Canvas, because software back then did not emulate hardware down to the chip level.

May I recommend http://www.donsolaris.com/ for more information on the JV/JD series? It also has information on the compression methods used for the samples.

mattw wrote on 2020-09-23, 03:32:

@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.

Drum machines are easier to emulate because their sounds usually are simpler (ignoring drum synths...). The TR-x0x patches in most PCM romplers are recordings of the real thing. However, they usually fail to capture the analogue aspects of analogue drum machines (i.e. slight random variations in the sound). Some PCM drum machines have stuff like random pitch variation to compensate for that.

mattw wrote on 2020-09-29, 13:05:

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.

On the hardware Sound Canvas, some patches are composed of two samples instead of one. The manual explains this as making the difference between a single and a double tone. The important bit is that in a double these two samples are not unique, but are part of the samples that are defined as "singles". This may explain the discrepancies you find in the number of samples.

On Roland's other PCM synths outside of the Sound Canvas line up (excluding the SC-880) and U110/U220, you can actually edit the individual samples.

BTW, the single letters added to tone names come from the Roland D70/MV30 line-up, and there they have specific meanings:
- "s" is a single sample
- "d" is a detuned sample

Reply 86 of 377, by mattw

User metadata
Rank Oldbie
Rank
Oldbie

It's really great to see more people sharing excellent information on the topic!

yawetaG wrote on 2020-10-06, 15:57:

Version 2.2 has Windows 2000 & NT support.

I didn't know version 2.2 even exists - I was thinking 2.1a is the latest from the VSC 2.x series. So, far VSC 2.1a was the most useful for reverse-engendering to me. Probably 2.2 has the same "good" features that allowed me to get memory dumps, etc. BTW, I can now confirm such version really exists from few Roland READMEs in Japanese, even I was not able to actually find it.

yawetaG wrote on 2020-10-06, 15:57:

...
May I recommend http://www.donsolaris.com/ for more information on the JV/JD series? It also has information on the compression methods used for the samples.

thanks for giving more info on TVF and I am already reading some of the information on that website.

yawetaG wrote on 2020-10-06, 15:57:

...
On the hardware Sound Canvas, some patches are composed of two samples instead of one. The manual explains this as making the difference between a single and a double tone. The important bit is that in a double these two samples are not unique, but are part of the samples that are defined as "singles". This may explain the discrepancies you find in the number of samples.

based on what I already reversed-engineered from VSC soundbank, that is correct, but in reality is even more complicated. So, each "thing" from "list2" I published several posts ago (I still call them "things", because I am not sure what to call them exactly, i.e. instruments, patches, sounds, etc) consists of several fragments or chunks of PCM data, each such chunk has index, and those indexes are used together with "pcm data address map", which format is "index, start address(offset), size" to extract the PCM data corresponding to those chunks.

Let me give 2 examples:

PIANO1
# of chunks: 10
...
TRAIN
# of chunks: 01

So, "train" is made of single "PCM chunk", the index of that chunk is 469 ("d5 01" in hex and little-endian format) and here is how line (index) 469 from "pcm data address map" for "train" in VSC soundbank looks like:

7f 83 6d 10 00 00 0f 1c 00 1c 00 50 3d 04 00 04

that means at address (or offset) 0x106d83 of "block2" (where all PCM data are packed together) with size 0x1C0f (7183) bytes is where "train" is located. (other bytes, not in "bold", I guess are things like loop-start, end, etc - ideas for them are welcomed). BTW, another reason except those "double tones" for which @yawetaG explained, why Roland split things like Piano1 as 10 chunks of PCM data is to be able to easily load and decrypt them on real SC55 hardware with its limited hardware resources.

Reply 87 of 377, by Cloudschatze

User metadata
Rank Oldbie
Rank
Oldbie
mattw wrote on 2020-10-06, 16:55:

(I still call them "things", because I am not sure what to call them exactly, i.e. instruments, patches, sounds, etc)

The exact terminology is unknown and is, regrettably, open to interpretation. I'd mapped-out some of the data concerning the SC-55 program ROM a number of years ago, deducing the following:

  • The hardware SC-55 has 317 known and selectable "Tones," or instruments, each comprised of up to two "Partials" with associated setup/parameter data. At this level, there are also 69 unselectable rhythm tones used in the various drumkits.
  • Each "Partial" references one of 244 individually-named "Original Tones."
  • Each "Original Tone" references up to 16 "Samples," and provides defined split points across the keyboard range.
    (Partial 1 of the "Piano 1," tone for example, references the "PIANO1" original tone, and ten samples.)
  • Each of the 993 defined "Samples" presumably references a raw "Waveform" location (of which I'd estimated there may be ~588), and provides looping and other data parameters.

Reply 88 of 377, by yawetaG

User metadata
Rank Oldbie
Rank
Oldbie
mattw wrote on 2020-10-06, 16:55:
based on what I already reversed-engineered from VSC soundbank, that is correct, but in reality is even more complicated. So, ea […]
Show full quote
yawetaG wrote on 2020-10-06, 15:57:

...
On the hardware Sound Canvas, some patches are composed of two samples instead of one. The manual explains this as making the difference between a single and a double tone. The important bit is that in a double these two samples are not unique, but are part of the samples that are defined as "singles". This may explain the discrepancies you find in the number of samples.

based on what I already reversed-engineered from VSC soundbank, that is correct, but in reality is even more complicated. So, each "thing" from "list2" I published several posts ago (I still call them "things", because I am not sure what to call them exactly, i.e. instruments, patches, sounds, etc) consists of several fragments or chunks of PCM data, each such chunk has index, and those indexes are used together with "pcm data address map", which format is "index, start address(offset), size" to extract the PCM data corresponding to those chunks.

Let me give 2 examples:

PIANO1
# of chunks: 10
...
TRAIN
# of chunks: 01

So, "train" is made of single "PCM chunk", the index of that chunk is 469 ("d5 01" in hex and little-endian format) and here is how line (index) 469 from "pcm data address map" for "train" in VSC soundbank looks like:

7f 83 6d 10 00 00 0f 1c 00 1c 00 50 3d 04 00 04

that means at address (or offset) 0x106d83 of "block2" (where all PCM data are packed together) with size 0x1C0f (7183) bytes is where "train" is located. (other bytes, not in "bold", I guess are things like loop-start, end, etc - ideas for them are welcomed). BTW, another reason except those "double tones" for which @yawetaG explained, why Roland split things like Piano1 as 10 chunks of PCM data is to be able to easily load and decrypt them on real SC55 hardware with its limited hardware resources.

"train" and several of the other "sound effect" tones are short looped fragments on which the filter has no effect.

When you do a filter sweep (closing off the digital low pass filter and then opening it up) on a tone on which the filter does have an effect, with the resonance raised high, you can hear digital artefacting and a certain amount of "stepping" in the result on a real Sound Canvas. The latter may be because on many PCM synths each tone consists of a multi-sample that actually consists of several parts, which aren't always well jointed. On some synths and especially cheaper rompler keyboards you also get this effect over the key range, because a tone uses different parts for different sections of the keyboard.
(On more advanced synths you can build patches out of multiple samples and assign each sample freely to a range of keys)

For the remaining bytes, possibly these determine where the various portions of the sample (attack, decay, release) start and stop.

Cloudschatze wrote on 2020-10-06, 17:35:
The exact terminology is unknown and is, regrettably, open to interpretation. I'd mapped-out some of the data concerning the SC- […]
Show full quote
mattw wrote on 2020-10-06, 16:55:

(I still call them "things", because I am not sure what to call them exactly, i.e. instruments, patches, sounds, etc)

The exact terminology is unknown and is, regrettably, open to interpretation. I'd mapped-out some of the data concerning the SC-55 program ROM a number of years ago, deducing the following:

  • The hardware SC-55 has 317 known and selectable "Tones," or instruments, each comprised of up to two "Partials" with associated setup/parameter data. At this level, there are also 69 unselectable rhythm tones used in the various drumkits.
  • Each "Partial" references one of 244 individually-named "Original Tones."
  • Each "Original Tone" references up to 16 "Samples," and provides defined split points across the keyboard range.
    (Partial 1 of the "Piano 1," tone for example, references the "PIANO1" original tone, and ten samples.)
  • Each of the 993 defined "Samples" presumably references a raw "Waveform" location (of which I'd estimated there may be ~588), and provides looping and other data parameters.

Sound rather like the clusterfuck that is Roland's terminology for the D70's patch structure...utterly confusing for the user.

(D70 has nothing to do with the D50 and other LA synths; it is a descendant of the U110 and U220 PCM synths with the TVF filter added: http://www.vintagesynth.com/roland/d70.php)

Reply 89 of 377, by mattw

User metadata
Rank Oldbie
Rank
Oldbie

@yawetaG
I believe you look at it from point of view how the synth engine works. I look at it from point of view how the Soundbank /Waverom (either SC55 ROM or VSC .dat file) is structured, because that is what I am interested in. I admit I know nothing about how synth engines work.

Cloudschatze wrote on 2020-10-06, 17:35:

[*]Each "Partial" references one of 244 individually-named "Original Tones."
[*]Each "Original Tone" references up to 16 "Samples," and provides defined split points across the keyboard range.

yes, 244 is the same number I am getting - attaching what my current code generates - those are split in 2 lists. what you call "samples" i am calling "chunks" though, because my point of view is purely from the soundbank structure. there are (407 + 721) chunks indexes (not unique) used in those 244 "original tones" definition.

Cloudschatze wrote on 2020-10-06, 17:35:

(Partial 1 of the "Piano 1," tone for example, references the "PIANO1" original tone, and ten samples.)
[*]Each of the 993 defined "Samples" presumably references a raw "Waveform" location (of which I'd estimated there may be ~588), and provides looping and other data parameters.[/list]

each, (in my terminology), "chunk index" references location in the PCM data, i.e. is a "chunk" of the Waverom data. that is proved without any doubt by me - see my posts where I mention "pcm data address map" and its format - I can as well extract every of those "original tones" to playable WAV file - not from SC55 ROM, because there I cannot figure out how the PCM data are encored, but from VSC soundbank where they are encoded in the following way: two 12-bit samples are stored as 3 bytes and you need to unpack them to 4 bytes (two 16-bit samples) in order to play. I mentioned that, but it's the exact same encoding as Yamaha TG100. In hardware SC55 ROM most likely u-law is used as per the code @Lord Nightmare posted (but we will never know for sure unless the encryption is figured out first).

Attachments

  • Filename
    list2_p02.txt
    File size
    2.88 KiB
    Downloads
    64 downloads
    File license
    Public domain
  • Filename
    list2_p01.txt
    File size
    4.27 KiB
    Downloads
    70 downloads
    File license
    Public domain

Reply 90 of 377, by Cloudschatze

User metadata
Rank Oldbie
Rank
Oldbie
mattw wrote on 2020-10-06, 18:27:

I can as well extract every of those "original tones" to playable WAV file ...

So, where what I've described as an "original tone" is a multi-sample, what does that sound like was a WAV file? Presumably ten piano notes, as concerns "PIANO1"?

Reply 91 of 377, by mattw

User metadata
Rank Oldbie
Rank
Oldbie
Cloudschatze wrote on 2020-10-06, 18:58:

So, where what I've described as an "original tone" is a multi-sample, what does that sound like was a WAV file? Presumably ten piano notes, as concerns "PIANO1"?

I guess I got it wrong again. So:

Cloudschatze wrote on 2020-10-06, 17:35:

... provides defined split points across the keyboard range.

yawetaG wrote on 2020-10-06, 17:47:

...a tone uses different parts for different sections of the keyboard.

those 2 statements seem totally consistent, at least to me, and so it's not for example Piano1 consist of 10 PCM pieces, but actually each such piece is different part of the keyboard, correct? So, you mean instead extract Piano1 (and all its 10 defined "pcm chunks" as a single WAV file), I need to extract it to 10 pieces and count each such piece as "original tone" - that's very simple to do if that's the correct way. I am totally confused now, which is what though...

Reply 92 of 377, by Cloudschatze

User metadata
Rank Oldbie
Rank
Oldbie

I'm not sure if this will help, or confuse matters more, but here's a spreadsheet I'd put together concerning the SC-55 v1.21 ROM (with some additional information provided by NewRisingSun).

https://www.symphoniae.com/synth/Roland/SC55/ … OCS/SC_121.xlsx

Reply 93 of 377, by bnz99

User metadata
Rank Newbie
Rank
Newbie

Usually, each sample comes along with a root key and a range around that root key for which the sample is mapped to specific notes. The list of samples then make up the complete keyboard mapping. The range can be expressed in different ways, like lower and upper key or really a range around a note (left and right). Multi-samples are typically used for more natural sounding instruments rather than synthetic ones as they tend to sound strange and artificial when they are played too far away from their root key.

If the chunks are the the same instrument at different pitches, for example spaced at different octaves, you'll need all of them as well as the metadata that maps those ten samples to the keyboard in order to do something useful with them.

Reply 94 of 377, by mattw

User metadata
Rank Oldbie
Rank
Oldbie
Cloudschatze wrote on 2020-10-06, 19:13:

I'm not sure if this will help, or confuse matters more, but here's a spreadsheet I'd put together concerning the SC-55 v1.21 ROM (with some additional information provided by NewRisingSun).

https://www.symphoniae.com/synth/Roland/SC55/ … OCS/SC_121.xlsx

thank you, it helps, I think I will just "convert" from the terminology I made up to what you're using as names in that spreadsheet, because it's not only probably more correct, but historically it's made earlier.

Also, I see in the spreadsheet you figured out some of the bytes I was not able to figure out like "Original Key" and "Sampling Frequency". do you know how to interpret the "Sampling Frequency" value?

And another question: in Piano1 that has 10 samples, how to interpret "Multi-sample Split Points (Note Value)" - is it correct my understanding that 9 split points make 10 intervals and for each such interval assign the corresponding pcm data?

bnz99 wrote on 2020-10-06, 19:17:

a range around that root key

let's make consistent terminology : in @Cloudschatze spreadsheet, "Original Key" is the root key or each "Split Points (Note Value)" defines a root key for that pcm data which are assigned to the split point?

I have a feeling we're making real progress on the whole structure of the Soundbank...

Reply 95 of 377, by mattw

User metadata
Rank Oldbie
Rank
Oldbie

@All

In case it was lost in the discussion, even I gave @vampirefrog a credit here:

Re: About Roland Virtual Sound Canvas 3

you can find his excellent work on Yamaha TG100 here:

https://github.com/vampirefrog/tg100/tree/master/programs

"12to16.c" is directly applicable to "block2" of VSC bank, i.e. how to unpack unencrypted "block2" to playable WAV sounds. BTW, with Yamaha, they use "patches", "instruments" and "samples".

Reply 96 of 377, by Cloudschatze

User metadata
Rank Oldbie
Rank
Oldbie
mattw wrote on 2020-10-06, 19:27:

And another question: in Piano1 that has 10 samples, how to interpret "Multi-sample Split Points (Note Value)" - is it correct my understanding that 9 split points make 10 intervals and for each such interval assign the corresponding pcm data?

Exactly. (The color separation in the spreadsheet should help with that visualization, but doesn't appear to be compatible with every viewer, in case that's an issue.)

In any event, and concerning the "PIANO1" "Original Tone":

Note range 00 - 1F, Sample = 00 00
Note range 20 - 25, Sample = 00 01
Note range 26 - 2C, Sample = 00 02
Note range 2D - 34, Sample = 00 03
Note range 35 - 3A, Sample = 00 04
Note range 3B - 40, Sample = 00 05
Note range 41 - 4A, Sample = 00 06
Note range 4B - 53, Sample = 00 07
Note range 54 - 5B, Sample = 00 08
Note range 5C - 7F, Sample = 00 09

Reply 97 of 377, by bnz99

User metadata
Rank Newbie
Rank
Newbie

let's make consistent terminology : in @Cloudschatze spreadsheet, "Original Key" is the root key or each "Split Points (Note Value)" defines a root key for that pcm data which are assigned to the split point?

Lingo is different depending on vendor and sometimes when something was created. I think in terms on Roland devices, "original key" is actually the correct term. At least i've seem them call it that in Fantom models. "Tone" would be, in my opinion, slightly confusing in Roland's terminology as these are more like sound layers or partials in the Roland devices in know. But really, if you didn't ask about the terminology, I wouldn't geek out too much about it 😉

Reply 98 of 377, by mattw

User metadata
Rank Oldbie
Rank
Oldbie

hmm, I've just noticed that "pcm data address map" of SC55 Soundbank from VSC 3.x contrary to the one from VSC 2.1a is not 16-bytes aligned. that makes it look really odd and I am immediately lost - the same way I am lost with what appears to be the "pcm data address map" from SC55ROM. that's very interesting clue, because "pcm data address map" from VSC 2.1a is very easy to read and follow. So, it seems it's time, even it's very tedious process, to make myself decrypted copies of all VSC 3.x soundbanks:

- decrypt its block2 layer1 encryption with vscdec.c
- then re-encrypt it with layer1 keys of VSC 2.x soundbank
- replace "block2" of VSC 2.x soundbank with the one prepared above
- make RAM dump and get unencrypted "block2" from it

and see how I can automatically parse them, i.e. understand why its "pcm data address map" is unaligned compared to VSC 2.1a Soundbank. Maybe, it's the same "problem" with SC55ROM and what prevents me to understand its "pcm data address map". Also, try to find out, where the offset of "pcm data address map" is stored, similar to how "block2" offset is stored in bytes 0x29 to 0x2a in the header of the bank. after all if "pcm data address map" in VSC 3.x is no longer 16-bytes aligned, I see no other option than the offset where it actually starts be stored somewhere.

[EDIT] solved - just removing the header aligned it... i guess when i looked at VSC 2.1a I did remove the header as well, just forgot about it...

Reply 99 of 377, by mattw

User metadata
Rank Oldbie
Rank
Oldbie

I really don't know with VSC the "pcm data address map" is so obvious:

0x00 0x01 0x02 0x03 0x04 0x05 0x06 0x07 0x08 0x09 0x0a 0x0b 0x0c 0x0d 0x0e 0x0f
-------------------------------------------------------------------------------
0x78 0x00 0x00 0x00 0x00 0x00 0x67 0x35 0x92 0x06 0x00 0x24 0xDC 0x03 0x00 0x04
0x7B 0x7A 0x35 0x00 0x00 0x00 0x2E 0x33 0xE0 0x08 0x00 0x29 0xFA 0x03 0x00 0x04
0x78 0xBB 0x68 0x00 0x00 0x00 0x9F 0x2B 0x3E 0x07 0x00 0x30 0x00 0x04 0x00 0x04
.....
0x7F 0x5F 0x0D 0x12 0x00 0x00 0x0F 0x1C 0x00 0x1C 0x00 0x50 0x3D 0x04 0x00 0x04
0x7F 0x81 0x29 0x12 0x00 0x00 0xEC 0x05 0xE1 0x05 0x00 0x42 0x4B 0x05 0x00 0x04

that the addressing is:

(offset_07 << 0x08) | offset_06 + 0x13 +  {(offset_03 << 16) | (offset_02 << 0x08) | offset_01} = next_index{ (offset_03 << 16) | (offset_02 << 0x08) | offset_01 }

and with SC55ROM, nothing stands up:

0x00 0x01 0x02 0x03 0x04 0x05 0x06 0x07 0x08 0x09 0x0a 0x0b 0x0c 0x0d 0x0e 0x0f
-------------------------------------------------------------------------------
0x54 0x07 0xB9 0x03 0x34 0x35 0x41 0x5C 0x07 0x8F 0x00 0x28 0x03 0xD9 0x03 0xF1
0x52 0x00 0xF3 0x20 0x4D 0x3E 0x6A 0xAE 0x14 0x4C 0x00 0x2A 0x04 0x26 0x03 0xF1
0x4B 0x05 0xC2 0x21 0x44 0xAE 0x4F 0x2A 0x0A 0x3B 0x00 0x2D 0x04 0x00 0x04 0x09
.....
0x7F 0x2B 0x93 0x20 0x08 0xD0 0x09 0x46 0x00 0x5E 0x00 0x40 0x02 0x0A 0x04 0x7D
0x7F 0x2D 0xFC 0xC0 0x04 0x5C 0x05 0x74 0x00 0x2C 0x00 0x4D 0x02 0x66 0x04 0x61

So, without first we figure our how the PCM data are addressed in SC55ROM, it will be kind of impossible to figure out how they are encoded in SC55ROM Waverom.