|BORING BACKGROUND INFO|
|SELECTING A SAMPLE RATE|
|DECODING A VOC-FILE|
|USING TAPER'S INTERNAL SAMPLER|
Clipping! Too loud!
| Model||Frequency range (Hz)|
|THE DECODE REQUESTER|
| Minimum Pulse (T)|
Maximum Pulse (T)
|The length of a pulse must be between these values to be acceptable as a pilot pulse. You may have to decrease this range when your tape contains much noise, although this problem is solved better with the following option.|
|Min Num Pulses||This is the minimum number of consequetive pulses that must have been read to accept the signal as a pilot.|
|Pulse Threshold (%)||This determines how much percent two consequetive pulses may differ to be accepted as continuing wave. It is used to determine the end of the pilot.|
|Minimum pulse (T)|| Before the actual bit-timings have been found, this value is used to
determine the minimum length of one bit. If a read pulse is smaller
than this value, TAPER assumes there is a small distortion in the
bitstream and adds the next pulse to the bit as well.|
When the actual bit-timings have been found, one half-pulse of a '0' will be used instead.
|Threshold '0'/'1' (%)||Before the second bit-timing has been found, this value determines the minimal pulse difference to make a pulse qualify for the other bit-timing.|
|Lossy Detection (?)||Usually, TAPER will use a middle-pulse value to find out if a pulse is a '0' or a '1' bit. If you turn this option on, the absolute bit-timings will be used instead. The signal tolerance will then be lower.|
|Use '1' = 2 * '0' (?)|| If turned off, TAPER will simply use the timing values as it detects
them. Most loaders (and the ROM itself) have a '1' pulse twice as large
as a '0' pulse.|
Try turning this option off if the tape won't decode.
|Single Pulse ('1')|| If a pulse is read that is more than 'this value' times a '1' pulse,
the end of the block has been reached.|
Beware that a lot of tapes have small distortions, so the next option is usually better.
|Joined Pulse ('1')|| As a bit is built from 2 pulses, 2 pulses are read at a time and their
average is used for decoding.|
Usually, due to sample rates, both read pulse lengths are not the same, but the average value is good enough to determine the correct bit. For 20kHz samples, 1.2 is usually a better value.
|Threshold Standard (%)||This determines how close the decoded values (pilot, '0' and '1' bits) must be to be detected as a normal speed (ROM values) block.|
|Drop Partial End (%)|| Sometimes, the decoded block has some bits following it (less than 8).
These are rarely needed, but may be read due to a too high tolerance
Turn this option on if you're not interested in these bits.
|Apply Filter (?)|| You will usually want to turn this option on.|
It filters noise from the VOC, corrects the signal's wave form and fixes distorted bits.
|Direct Recording (?)||If this option is turned on, the VOC file will not be decoded, but rather inserted as a Direct Recording block.|
|Standard Syncs (?)||If turned on, will force all sync pulses to standard values (except for the special blocks from decoding schemes of course).|
|Show Decode Graph (?)|| If turned on, will show a pulse graph of each decoded block and print
some additional info.|
The green lines show the pulses that lead to a 0-bit,
The red lines show the pulses that lead to a 1-bit.
As one bit is composed of 2 pulses, the blue lines show the bit-spread. The left part shows the 0-bits, while the right part shows the 1-bits.
The 0- and 1-parts should be as far apart as possible.
At the bottom, the total number of pulses and bits are reported, plus a value `noise bits' (if the VOC filter was turned on). Noise bits are bits that contain signal distortions and are tried to be corrected while decoding.
|CoolEdit Adjust (?)||Turn this option on only if you want to decode a VOC file that has been created with CoolEdit. It adjusts the used sample rate to suit this sampler.|
|Frequency Shift (?)||Turn this option on only if you want to decode a VOC file that does not decode otherwise. It corrects a possible rounding error caused by READVOC and may correct resampling errors caused by sampler programs if you changed the sample rate.|
|(none)|| Means that the values must all be determined from the VOC file. This
can be used only for ROM saved programs or 'normal' (generic) turbo
|Force ROM Values|| Will force the ROM timing values and decode the VOC with these. This
option implicitely turns the 'Drop Partial End' option on.
|BleepLoad|| You will recognise the BleepLoader by the following things: it always
writes the name of the game on the screen after the BASIC block is
loaded. After the BASIC, there is another CODE block and then the
BleepLoad follows. This consists of small blocks (with sizes around
250 bytes) with a very small pilot tone.|
There is no interleave between the blocks.
While loading, it writes the block number in hex on the screen (like 'LOADING 1F'). If there was an error, you can reload the block with the error.
There are always 2E blocks before the picture and around 8E blocks after it (this may vary for different games of course).
|Alkatraz|| The Alkatraz protection scheme uses almost standard tape encoding.
This is how you recognise that this encoding is used:|
- The 'Program: ' prompt is not displayed when the BASIC block loads. Instead only some 5 letters of the filename are displayed AT 1,1 position; If you look at the BASIC part after the decoding, you will see an 'Alkatraz Protection System' message in it.
- After the BASIC comes a headerless, turbo-loading CODE block;
- Then there's a pause for about 12 seconds, while you hear noise on the tape;
- It then starts loading the screen in some custom very nice fashion, while the border stays black.
The pilot tone for this block is VERY small (around 240 pulses) and is automatically extended to simulate the noise from the tape.
- After the screen comes the rest of the block while a counter with scrolling numbers counts down. Again with a black border.
It is not necessary that the parity bytes are correct (as they are not used).
A lot of SpeedLock protected games have the following text line in the last
BASIC block before the turbo blocks: 'Protected by SPEEDLOCK'.
To check the parity for SpeedLock protected games, select an entire Group of
sub-blocks (Group Start/End entries surround them) and use menu option
'Entry' -> 'Selected block' -> 'Group parity'.
|SpeedLock 1|| This one is the first SpeedLock protection, used in most of the older
It starts with 2 BASIC blocks, the first one is VERY SHORT. Several early SpeedLock 1 games have a single medium length BASIC block.
The loading itself looks like normal highspeed loading (about 150%), but has one distinct give-away: the so-called 'clicking' pilot tone, which means that the pilot is continuously interrupted with a small distortion.
The border colors are the same as normal tape blocks.
It is not necessary that the parity bytes for the turbo blocks are correct (as they are not used). The last byte can be less than 8 bits, so be careful with the 'Drop Partial End' flag.
The data is not encrypted and only 48K programs can be handled by this scheme.
(TAPER v2.03: SpeedLock 1)
Examples: Highway Encounter, Daley Thompson's Decathlon and numerous re-releases.
|SpeedLock 2|| This is the successor of Type 1 and features the same clicking pilot
and a loading speed of around 150%.|
The border colours can be the normal loading colours or red/black for the pilot and blue/black for the data.
The second turbo block is composed of several (small) sub-blocks, which are glued together with an awkward mid-sync signal.
All parity bytes must be correct for a SpeedLock 2 game to load! The last byte may be less than 8 bits.
(TAPER v2.03: SpeedLock 2)
Examples: Enduro Racer and Knight Rider.
|SpeedLock 3|| This type is alomost the same as SpeedLock 2, except you can hear
bubbling sounds (which are not needed in order for this scheme to load)
during the decryption stage. During this stage, the border flashes in
Before the turbo blocks, there is 1 SHORT BASIC and 1 SHORT CODE block.
(TAPER v2.03: SpeedLock 2)
Examples: Leviathan 48K and 128K.
|SpeedLock 4|| You will recognise this protection scheme by its very SHORT BASIC
block and a very LONG CODE block (8Kb).|
After this, the decryption stage follows for about 25 seconds. During this stage, the border flashes either with red/black or multicolour stripes and you can hear bubbling sounds (which are not needed for this scheme to load). The loading speed is 150% again.
After this stage come the two (very encrypted) turbo blocks:
- First block: loading stripes are red/black for the pilot tone and blue/black for the data. This block is very short (some 200-300 bytes);
- Second block: same loading stripes, but the block length is the entire 48K or even more (for 128K games). As in SpeedLock 2, this block is composed of several (small) sub-blocks with an awkward mid-sync signal.
When the loading picture pops on the screen, the border goes black and the loading timer starts its countdown in the format '1m32s10'.
There must be no partial end byte and the parity should be correct. For the first turbo block this is simply the last byte, but for the second turbo block (with the sub-blocks) this is an overall parity byte, which is the last byte of the last block.
(TAPER v2.03: SpeedLock 3 variation 1)
Examples: Athena 48K and 128K and Catch 23.
|SpeedLock 5|| This scheme is equal to SpeedLock 4, except the sound you hear during
the decryption stage is not bubbling, but instead either a clicking
tone or a wave sequence.|
This scheme NEEDS the noise in order to load!
(TAPER v2.03: SpeedLock 3 variation 2)
Examples: Out Run, Ping Pong, Winter Games 1 and 2 and Madballs.
|SpeedLock 6|| This one is VERY similar to SpeedLock 5. The difference is a lower
loading speed, around 127%.|
During the decryption stage, you hear a clicking tone or a wave sequence while the border flashes in multi-colour.
This scheme NEEDS the noise in order to load!
Because of the lower speed, the mid-sync pulses can sometimes not be detected. So, there could be a partial end byte and a wrong parity in the second turbo block while the game will still successfully load!
(TAPER v2.03: didn't exist!)
Examples: Vixen, Super Hang-On.
|SpeedLock 7|| This one is VERY similar to SpeedLock 6. The difference is as follows:
There is only one BIG BASIC block (4Kb).|
There is almost no pause between the BASIC block and the first turbo block; the decryption is much faster and you hear no sounds during this stage.
The loading speed is around 127% again.
(TAPER v2.03: SpeedLock 4)
Examples: Turrican, Myth, Operation Wolf, Firefly, Arkanoid 2 and Tusker.
|Digital Integration|| This scheme was used by the company of the same name. It can be seen
very easily, as the turbo speed blocks (after the single small BASIC
block) have a pilot signal that is composed of 2 parts.|
The first part is fairly long (some 2.5 seconds), while the second part is very short and has a lower pitch.
The turbo blocks are heavily encrypted, so don't worry if the screen looks funny.
|Dinamic Loader|| Some games published by Dinamic had this scheme (although some other
used SpeedLock protection).|
This type can be detected by listening to the tape playing. You will hardly hear anything but a pilot tone. After decoding this type, you'll end up with a couple of hundred (!) extremely short blocks.
|Sinclair User|| This scheme was used for several covertapes that came with the
magazine. It's easy to see:|
- There's no pause between any of the blocks,
- It starts with a small BASIC block of some 300 bytes,
- There are 2 turbo blocks, with flag byte 101. The border colours are green/black for the pilot and magenta/black for the data,
- The first blocks loads the screen, the second block can be over 40Kb (for 128K programs),
- The turbo blocks are crunched.
This scheme implicitely turns `Drop Partial End' on.
|Your Sinclair|| The same as the Sinclair User scheme, but used by Your Sinclair.
The difference is that the blocks are not glued.
|Players|| An excellent loader, often combined with load-a-game or changing
screens while loading.|
It's a generic turbo loader.
This scheme implicitely turns `Drop Partial End' on.
|Paul Owens Protection System|| The first, BASIC, block is just over 3Kb and all other blocks
are turbo. The speed is only slightly faster than normal speed, but the timings are not
symmetric like all other loaders, i.e. a `1' bit pulse is not twice as long as a `0' bit
This BASIC listing will contain the string 'CHEBICHEV'.
This scheme implicitely turns `Drop Partial End' on and `"1" = 2 * "0"' off.
Examples: Rainbow Islands, Red Heat, Batman - The Movie and The Untouchables.
|IF ALL FAILS|
|Q||The decoder splits some blocks when there should be only one block. This usually means you have a lot of blocks and they all have bad parity bytes.|
|A|| The end-of-block detection is set too tight. Increase these
Mind though, that when you increase them too much, the following problem can occur.
|Q||The decoder 'glues' blocks together.|
|A|| The end-of-block detection is set too loose. Decrease these
values slightly. This can easily happen when the sample
rate is 20kHz or lower.|
You can see this after decoding by using the menu option 'View as...' and choose 'Hex Editor'. You will probably be able to see the real blocks, with blocks of 'FF' bytes in between.
|Q||The blocks get recognised as custom speed blocks, while they actually are normal speed blocks.|
|A|| You can increase the 'Threshold Standard' value percentage.
Or, if the entire tape only contains normal speed blocks,
you could use the decoding scheme 'Force ROM timing'.
|Q||The block gets converted wrong (i.e. loading screen is all garbled).|
|A|| There can be many possible answers to this problem. The
quality and sample rate of the VOC file determines how easy
it will be to convert.|
You could try to turn 'Lossy Detection' on, increase the 'Threshold '0'/'1'' or turn 'Use '1' = 2 * '0'' on.
Mind though, that the turbo blocks in SpeedLock 2 through 7 are supposed to be garbled! This is because they are crypted. You could try to set the menu option 'Auto-decrypt' on. If you get a correct screen now, the block was decoded correctly. However, some may still look wrong, because they use a different encryption scheme.
|Q||After decoding, I get a bright red data entry.|
|A|| This means there was a normal (ROM) speed datablock, but
with an incomplete last byte. It is printed in bright red,
as this partial byte will not be saved, unless saving as a
VOC file again.|
Usually, these bits aren't needed anyway, but if you really want to keep them, you must convert the block to custom speed (View entry info -> Edit)
|Q||I have a VOC file that contains echoes and lots of noise. It loads up correctly in an emulator, but TAPER has one or more blocks wrong.|
|A|| As TAPER doesn't know a loader's samplerate (which is not
the same thing as the VOC sample rate), it has to make
assumptions on which bits are distorted.|
This process can occasionally go wrong. Sorry...
You DID pick the correct decoding scheme, right?