SQ80 ROM extraction issues

[tulamide]

Now onto the problems with the other ROMs.

Yesterday I spent some hours on this and I’ve come to the conclusion, very reluctantly, that either the spreadsheet is messed up for ROMs 2-4 or the file contents don’t match the spreadsheet (more likely).

Here’s what I did:

I checked my method of csv extraction from the spreadsheet by re-extracting the ROM 1 files and got the same results as you, so I know the csv files for the other ROMs should be ok. Plus, your tool extracted the expected number of waveforms from each ROM, as per the spreadsheet, and the file sizes were correct, even though some extractions contained 2 or 3 three complete “waveforms”. So your tool and my csv files are not guilty.

The contents of the files were certainly not as expected! ROM 2 contained sounds that should not even be in ROM 2. So I assumed the file names for the ROMs were misleading me. So I used each csv file for all the ROM images 2-4 and none of them produced the range of expected sounds. I base this on the obvious sounds; one-shots and the Attack sounds, such as “bowing” and percussion. The single cycle sounds were not possible to identify clearly of course. Also the loop points chosen for some vocal sounds were not good, which is very unlikely for a commercial product. I was able to find better loop points myself!

As an example I found the 2 bowing sounds in ROM 3 image, not in ROM 2. I did this by manually extracting the obvious sounds from the whole ROM images, and also comparing with those AIFF files (these seem to be accurate BTW).

Also I wondered if the first wave in the extracted files was always correct and maybe it was my interpretation of the WSR value that was wrong, but even this isn’t the case. The first waveform, where there are 2 or more included, was wrong too, and that one is taken from the base address.

My suspicion is that the spreadsheet was obtained by reading the OS ROM (which is where the index values and names etc must reside) but the ROM images have not been made correctly. I plan to look more closely at ROM 1 today (jeez I hope that one is ok!).

Just ask if you need any more info about this…

Cheers

Spogg

I've had a look into this as well. I did the calculations of the first 3 waveforms from ROM#2 (According to the spread sheet) by hand, and this is the strange result (that the extractor also read):

Code: Select all

bowing.1
start 0
length 16384

plunk
start 10240
length 2048

plick
start 12288
length 4096

plunk and plick are consecutive, but the numbers indicate that both are part of the bowing.1 waveform, which to me makes no sense. (Didn't check, but theoretically bowing.1, when played, should sound like 3 sounds in one waveform)

But where exactly did things go wrong? For example, bowing.1 has an index of $52. In the first spread sheet, the wave "bowing" uses $52 (=bowing.1) for the first few keyzones. And that does make sense. This is really weird. How long is bowing.1 in the aiff files?

[Spogg]

I have to out right now but I've attached the AIFF files with their conversion to WAVs, and also put all the WAVS into one folder with all visible.

Cheers

Spogg

[tulamide]

Oh, I think I know, what's going on!

The other ROMs (#2-#4) behave differently to ROM#1. I had a look at the original ROM#2. I can see that there are 8 waveforms and that 7 of them are one-shots. Unfortunately, some of the start points (due to the length of prior one-shots) can't be expressed in page values. But the ROMs can only be accessed page-wise.

To get around this issue, they stuffed waveforms together up to the next accessible page number. To let the DOC know, where those waveforms end (for example the first 3 where accessed as one waveform), they added a Zero byte directly in the ROM!

ROM#2:
The first waveform is absolutely a bowing sound, but it isn't 16484 samples long. It's length is 8128 samples. Then follow a series (!!) of stop-bytes, and the next waveform begins. The second one starts at 8192 (not 10240, as stated in the spread sheet), and is 4032 samples long (not 2048, as stated). Again following a series of stop-bytes. The third one starts at 12288 (which matches the spread sheet again), and is 4032 samples long (just as the second one, and not 4096, as stated), followed by a series of stop-bytes that go up to sample 16383. 16384 is a page number, and a new waveform starts there.

Obviously they use the stop-bytes as pad-bytes (they don't belong to any wavefrom) and used the stop/reset mechanism right in the ROM to distinguish those waveforms that were accessed as just one. But why are there such wrong start and length values? I'm going wild here, and it might be a coincidence, but both values from waveform 2 and 3 point to the crucial 8192 (which is a non-page value) if you subtract the length value from the start value. It is quite possible that the values are used differently to the ESQ1.

The bad news is, that the extractor can't be used for this. The good news is that this behaviour is in some way consistent and therefore can be automated. If ROM#3 and ROM#4 behave similar, I can build another extractor especially for these 3 ROMs.

[Spogg]

Mon Dieu you are so impressively clever!

I did see those stop bits but I was rapidly coming to the conclusion that the images were wrong and those zero values were a symptom.
Also I can now see why none of my csv files for ROMS 2-4 worked.

There’s another twist in the tale here.
When you mentioned that the first waveform in ROM 2 is definitely a bowing sound I thought OMG and felt a little sick. When I re-checked, the first sound in what I thought was ROM 2 is a definite “chiff” sound. I made an assumption that the ROM numbers went in sequence with the file name numbers. Turns out this was wrong. This is a table of the filenames Vs. ROM image number:

2202 ROM #1

2203 ROM #3

2204 ROM #2

2205 ROM #4

I never learn seem to learn that lesson about making assumptions.

Of course your explanation was counter to mine and, if I understand you, it’s the spreadsheet that’s misleading and, hopefully, the images are correct. Which is a good thing maybe.

I’m now wondering how you can make an extractor tool if the WSR values given are misleading for ROMS 2-4. A lot of waveforms don’t have those stop bits from what I could see, especially in ROM 4. And just looking at them it’s not easy to see where one stops and the next one begins.

We shall see….

Cheers

Spogg

[Spogg]

Progress!

Here the files I extracted:

viewtopic.php?f=3&t=12471&p=43215#p43215

Cheers

Spogg