[RippingGuide] Sid-Mon (R. V. Vliet, 1988)

Discussion about Amiga / C64 / Demoscene music and the ExoticA music archive. Favourite music, new rips, musicians, demo sounds, audio software. It's all welcome here.

Moderators: XtC, BuZz

Post Reply
JaeMa
Posts: 3
Joined: Tue Apr 22, 2003 6:18 am

[RippingGuide] Sid-Mon (R. V. Vliet, 1988)

Post by JaeMa »

So, this is my first attempt to lay open one of my module ripping methods for a certrain module format. If the admin decides to open up an extra subforum for this, I hope this thread can be moved properly.

Please feel free to discuss these methods in order to improve them and fix bugs. Also post your own methods for yet undiscussed formats!

My (our) aim is to provide information for people who are creating or want to improve XFR clients or other pieces of software. If you improve the method or fix a bug while implementing it as an XFR client or in another piece of software, please mention it here!


The reason for posting a method for Sid-Mon (version 1) is that the actual XFR client shows this:
"some different kinds are partially supported, no size calculation, player can be patched to work if it does not work"

Here we've got size calculation but no possible patch (can somebody post the method used in the client and what this patch does / why it's needed). And as far as I remember, it worked well for all modules which can be found at Exotica.

General [RippingGuide] conventions (feel free to request changes/additions):
- X always is a placeholder for the memory address which is tested for being a module start address
- byte[x], word[x], long[x] respectively stand for "byte/word/long located at address x (motorola format)
- every forumula is enclosed by "(" and ")"
- for detection and sizecalc difficulties these "descriptions" are used (in correct order): "very easy", "easy", "tricky", "difficult", "hard", "mindbombing"

Code: Select all

FORMAT
------

Name ........... Sid-Mon
Inventor ....... R. V. Vliet
Year ........... 1988
Method Version . 1.00
Method by....... JaeMa
Detection ...... easy
Sizecalc ....... difficult
Examples ....... http://exotica.fix.no/tunes/formats/index.html#sid


DETECTION + SIZECALC
--------------------

VARs

SP:word // Pointer to Sampleheaders
SN:word // Number of Samples
SO:word // Sampledata Offset
SL:word // Sampledata Length
NP:word // Name Pointer
ML:word // Module Length
IN:word // Number of Instruments (Synth)
IP:word // Pointer to Instrumentheaders
HS:word // HighSmp
IO:bool // Instruments Only (no Samples)

STEPS

1. Word[X] must be $41fa, word[X+$06] must be $ffd4

2. Now we calculate some addresses where useful info is stored
2.1. Set NP to (X+$02+word[X+$02])
2.2. Set IP to (NP+long[NP-$1c])
2.3. Set IN to ((NP+long[NP-$18]-IP)
2.3.1. IN must be a multiple of $20, then divide IN by $20
2.4. Set SP to (NP+long[NP-$04]);

3. At IP we've got IN instrument headers, $20 bytes each, and each header is holding one byte at offset $03 which holds the waveform number used for that instrument. If it's higher than $0f then instrument is a sample, else it is a synth instrument. Go through each instrument header and calculate the highest waveform number. If it's higher than $0f samples are used. Set SN (number of samples) to (value-$0f).

4. Due to different versions of the Sid-Mod player code it's possible that SP (calculated in step 2.4) holds the value (NP+$01), i.e. long[NP-$04] is set to $00000001. In that case, we'll have to calculate SP in a different manner and calculating the sampledata length then is very simple. If it's not the case, go on with step 6!
4.1. Set SP to (NP-$06+long[NP-$08])
4.2. Set SL to (long[NP-$0c]-long[NP$10]), SL must be lower than or equal to $2000
4.3. Set ML to (SP+SL+$02-X), now you've got the module length and module address, so you can save the module and STOP HERE.

5. Perform antoher check: long[SP] must be a multiple of $20 and smaller than or equal to $2000. long[SP] is the size of the sample headers, each header is $20 bytes large and a maximum of $100 headers are allowed!

6. For each header (HP = pointer to acutally checked header) perform the following steps steps. First HP is (SP+$04), each header $20 bytes.
6.1. long[hp+$00] must be smaller than long[hp+$04] if long[hp+$08] is not set to zero, else skip header checking. long [hp+$04] = sampledata end, long [hp+$08] sampledata size
6.2. long[hp+$04] and long[hp+$08] must be smaller than $01000000 else skip header checking
6.3. while scanning the sample headers, set SL (sampledata length) to the highest long[HP+$08] you find. Don't do this if the actual header is invalid (steps 6.1 or 6.2 result in header checking break)
6.4. if the checking is skipped due to an invalid sample header, remember the header number where this happened (starting at zero) and set SN to that number and continue with step 7!
6.5. after completing the checking of all headers, set SN to (long[SP]/$20)

7. Now set ML (module length) to (SL+$04+SN*$20+SP-X). Now you've got the start address (X) and module length, so save it!


DETECTION ACCURACY
------------------

We've got these checks:
1. 4 bytes compared to fixed values (step 1)
2. 5/8 byte compared to zero (step 2.3.1)
3. 5/8 byte compared to zero (step 5)
4. 2+3/8 bytes (sum of 8 bytes) compared to zero (step 4.2)
SUM => 7 + 5/8 bytes "scanned", 4 of them for non-zero values

All SID1 modules found on Exotica were identified!


SIZECALC ACCURACY (comparison on Exotica modules)
-----------------

Quite interesting. In most cases the newly "ripped" files are smaller than the original file. I used DeliPlayer to quickly check if I find any differences and did one check by doing a .wav output on SID1.Brainwave and SID1.Brainwave.newrip (high size difference, so I took this example) and found no single different byte in the output stream. So I would say that the size of a SID1 module is calculated more exact than in the ripper that was used to rip the too-high-sized modules.

For example the tunes:
SID1.Concept-TD_Intro
SID1.Spirit
are equal but have different filesizes only. My ripping methods calculates the same size for both files (as they hold the same module this is the logical result)

The same is for:
SID1.Brainwave
SID1.The_Trashcan_Theme

On the other hand, we've got some modules where the newly "ripped" file is larger than the original, namely:
SID1.Anarchy (4 bytes)
SID1.News-On-Tour1 (2 bytes)
SID1.TRSI-Cracktro (2566(!) bytes)

For TRSI-Cracktro (found on the game Bad Vibes) I re-ripped the music from the cracktro and then hewviewed it. One sample is missing in the Exotica archived module, I thought. Okay, I played and recorded the music with DeliPlayer and used an audio manipulation Program to obtain the differences. And there are differences, but not in the form of the sample I thought which was missing.

The only difference appears in a synth instrument, maybe the reason for this is at WHICH point of time the module is ripped, as the waveforms are manipulated while playing the module.

But however, it is sampledata which is missing, and even if it's not used, a complete rip should contain every sample which is included in the module, however it is played or not IMHO.


NOTES
-----

Due to some hacked modules which I've found I discarded some additional checks which I did implement in older versions. I'm sorry that I can't tell you which checks these were, as this ripping method is two years old, and I can't remeber for some steps, why they are done. This must be seen as a Pascal=>Plaintext conversion.

Post Reply