TAPE DECODING USING TAPER


[TAPER!]
Written by M. van der Heide, Martin Kopanske and Tomaz Kac
Copyright 1997-1999 ThunderWare Research Center


BORING BACKGROUND INFO

While reading this document, you will see that I refer to 'T-states'. A 'T-state' is the counting value as used by the Z80 processor itself and is the time length of 1 clock pulse. As the Z80 in a ZX Spectrum runs at 3.5 MHz, 1 T-state has a duration of 1/3,500,000 seconds.

A 'pulse' is one half sine wave (1) and a 'joined pulse' is one full sine wave (2).
It looks like this:
[A piece of sample]

First of all, let's see how a tape block is organised:
  1. A block starts with a pilot signal. This 'tells' the loading routine that a new block is starting. The Spectrum ROM needs this pilot tone to be more than 1 second in duration.
  2. After the pilot come 2 sync pulses, which are significantly smaller than a pilot pulse. This marks the end of the pilot.
  3. Then comes the datablock. 1 bit of data is composed of 2 equal pulses. The length of the pulses determines whether it's a '0' or a '1' bit. Usually, a '1' bit pulse will be twice as long as a '0' bit pulse. The amplitude of each pulse is not important, as the loading routines are 'edge-triggered' rather than 'level-triggered'. The datablock itself is composed of the following parts:
    • The first byte is the flag byte. The ROM uses this to make the difference between a 'header' block and a 'data' block.
    • The last byte is the parity byte. This is an 8-bit XOR of all previous bytes, including the flag byte. While loading the data, this parity is calculated again and matched with this last byte. If they match, loading was successful, otherwise you get the dreaded 'Tape Loading Error'.
    • The rest is the actual data, which is stored in memory.
  4. A block is always ended in one of two ways:
    • a pause
    • the next pilot

SELECTING A SAMPLE RATE

The used sample rate has a huge impact. The pulses used to encode the data on the tape are very short. Therefor, the sampling routine in the Spectrum ROM uses a sample rate of 60 kHz. This is more than you will need, but will of course give the best results.
You'll be best off using the "normal" sample rates, i.e. 11025Hz, 22050Hz, 33075Hz or 44100Hz.

To give you a quick idea, let me tell you this:
The ROM saves a '0' bit as 2 pulses of 855 T each. As 1 T = 1/3,500 ms., this results in 0.244 ms. (or 0.000244 s.) for a pulse! That's not a whole lot! And over 70% of the games had some sort of turbo loader, where the pulses for each bit are even shorter.....
If you use a sample rate of 20 kHz, each sample represents 175 T. Compared to 855 T, you will see that it makes quite a difference if the saved data is 1 sample off. And that's for normal speed.
If you use a sample rate of 44.1 kHz, each sample represents around 79 T. The program TAP2VOC (which comes with the registered version of Z80) uses a sample rate as low as 4098 Hz. Each sample is now 854 T.
See what happens if you are only as much as 1 sample off!

You will have the best chances if you use a sample rate of 44.1 kHz (CD quality). This will result in quite a large VOC file, but you will need it only once. TAPER can then process the VOC file and create tape files of (usually) some 50 Kb.


DECODING A VOC-FILE

This document can be used for Z80Em 'raw sample tape' files and Ramsoft's 'Compressed Square Wave' (.CSW) as well.
A VOC file must be 8-bit mono, noncompressed. GoldWave extensions are supported as well, as long as these files are also 8-bit mono, noncompressed. Any sample rate may be used in both reading and writing of VOC files. There is no need to 'cleanup' a VOC file first, as the decoding routines do a very good job on echo and noise correction.
Usually, the best results are found when sampling with READVOC or READSB (which come with the registered version of Z80), but there is no need to use them. Any 8-bit mono noncompressed VOC file will be accepted.


USING TAPER'S INTERNAL SAMPLER

Since v2.04, TAPER has its own sampler built-in, which can be used to sample physical tapes, to be decoded directly from within TAPER.
I personally use my original SlipStream Spectrum tape deck (1983). It appears that 'bad' tape decks give the best results, so bring out your mono deck or your walkman!
Since TAPER has been designed to decode any part of a special loader, you can sample per block at a time or sample a full program in one go.

The first requester lets you set the software mixer (if your soundcard has one) to get the best possible sound signal. The mixer settings can be saved and are automatically reloaded when you use the sampler again.
It looks like this:

To setup your tape, simply play it and look at the oscilloscope window. The window above is 'seeing' a pilot pulse by the way. The sound volume is a bit on the low side, although it will do. Other views you can get are:
[Clipping!]
Clipping! Too loud!
[Perfect]
Perfect...
Make sure that the tops of the waves fit in the window. A little clipping doesn't hurt.
Try to keep the loudness setting (often referred to as input gain) to x2 max. If the tape has much noise, it's often better to use a lower volume, as not to amplify the noise too much. In that case, lower the treble slider too, to eliminate the high frequencies.
It's generally best to keep the bass level turned down, either around the center or fully withdrawn.

After this requester, the read sample rate is asked. Please use as high a sample rate as your card supports to get the best results. TAPER lets you sample up to 60kHz, for really bad tapes. Usually you will want to stick at 44kHz though. Since TAPER decodes in 2 stages to be able to eliminate all noise spikes and suppress echoes in the signal, the next stage will be recording a sample of the tape. You can stop the recorder at any time by pressing a key. TAPER will then proceed as usual, popping up the VOC Decode Requester and decoding the sample. After a decode, you get a question whether decoding was successful, with the options 'Ok', 'Retry' (re-decode) 'Save' (save the intermediate file) and 'Drop' (if all fails and you need to re-sample the tape).
Then you are asked whether you wish to continue to sample more tape or stop.

The recorded sample is stored in the directory you set up as temporary directory in your environment (usually C:\TMP, C:\TEMP or C:\WIN95\TEMP) and is removed after decoding. Make sure there's enough room on the drive where this directory resides! If writing to your harddisk takes too long, TAPER will report a DMA overrun. If this happens, try setting up a large RAM-disk (e.g. 8Mb) and put your temporary directory there.

Notice that not all SoundBlaster (compatible) models can handle all frequencies. The following table lists the official frequency ranges. Clones can sometimes handle different speeds.

Model

 Frequency range (Hz)
SoundBlaster 2.x 4000-15151
SoundBlaster Pro 4000-22727
SoundBlaster 16 4000-45454
SoundBlaster (AWE)32/64 5000-45454


THE DECODE REQUESTER

When you open a VOC file or decode a block from within TAPER's sampler, a requester will pop up where you can adjust the values used by the decoding routines.
Notice that TAPER hardly ever needs any setting to be changed, apart from the Decoding Scheme or Drop Partial End Byte. As TAPER is a full tape handling program, you can see the results directly.

You may wonder why there are so many variables to decoding. This has several reasons. First of all, the quality of the analogue sound signal is worse for older tapes. This is caused by tape wear-off and is exactly why this program may become important for you! Both the signal strength and the signal/noise ratio determine how easy it will be to determine what is what on the tape.

PILOT DETECTION
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.

BIT DETECTION
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.

END DETECTION
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.

OTHER
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 (end detection).
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.


ENCODING SCHEMES

The following schemes are currently supported.


(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 speed programs.

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 games.
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 multi-colour.
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 pulse.
This scheme implicitely turns `Drop Partial End' on and `"1" = 2 * "0"' off.
Examples: Rainbow Islands, Ret Head, Batman - The Movie, Cabal and The Untouchables.


IF ALL FAILS

If decoding doesn't work, consider the following options. Also check the following:
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 values slightly.
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?