8

I am digitizing about 40 tapes with programs for the ZX Spectrum. I am somewhat puzzled by the waveform after digitization. The signal of most cassettes is meander-shaped. meander-shaped meander-shaped meander-shaped One of the cassettes can be downloaded from DropBox.

Some cassettes have a sinusoidal signal. This is an example of a cassette with a bad record. This cassette has an unstable amplitude. sine wave sine wave This cassette can be downloaded from DropBox

Sometimes there are records with "dancing" short pulses. short pulses

Questions: 1. What shape should the pulses be for successfully decoding programs recorded on these tapes?

  1. What programs can help in decoding or preparing audio files for processing?

  2. Any hacks for successful processing of tapes.

P.S. After some experiments with adjusting the signal level and the tape recorder head, I came to the conclusion that this is important for some audio tapes. And returning to the topic - the waveform must be sinusoidal.

Demonstration of the same piece of tape as an example (this files can be downloaded from Dropbox.):

Before adjust the tape recorder head enter image description here

...after adjust the tape recorder head enter image description here

  • 1
    Are these commercial tapes, or 'home' (AKA pirated duplicate) recordings? Have you tried adjusting head azimuth on the weak recordings? What do the clipped 'meander' waveforms look like if you reduce the playback volume? – Bruce Abbott Nov 17 at 10:09
  • These are commercial pirate tapes. Covers - dropbox.com/sh/t6uqlmwctsrhhi1/AABd-g8GODhJpNRmHQrDuIlia?dl=0 I do not plan to adjusting head azimuth until I digitize all the tapes, then I plan to return to those tapes that have problems. I can not yet reduce the playback volume. To do this, I need to disassemble the tape recorder. – A. Rumlin Nov 17 at 12:31
  • 1
    The 'sinusoidal' tape with unstable amplitude sounds like an analog copy recorded through the mic input (or perhaps even with a mic) with ALC (automatic level control) turned on. This explains the varying amplitude ('breathing') poor bandwidth and noise in the gaps. ie. a typical amateur pirate copy. Might be readable if the amplitude is increased until clipping. – Bruce Abbott Nov 18 at 3:08
  • 1
    If by "decoding" you mean reconstructing the data stored on the tape (rather than being able to read the tape on original or reproduction hardware), then the important characteristic to look for when decoding is the time delay between zero-crossings (where the signal crosses the red horizontal line in your pictures). Alternatively, it may work better to measure the time delay between points where the curve has maximum slope versus minimum slope but this requires more math and may only help with particularly bad recordings. lvd's answer lists the expected time delays you need to fit data to. – Ken Gober Nov 18 at 14:47
7

Check this Spectrum tape interface:

Pulses

A 'pulse' here is either a mark or a space, so 2 pulses makes a complete square wave cycle.

Pilot tone: before each block is a sequence of 8063 (header) or 3223 (data) pulses, each of length 2168 T-states.

Sync pulses: the pilot tone is followed by two sync pulses of 667 and 735 T-states resp.

A '0' bit is encoded as 2 pulses of 855 T-states each.

A '1' bit is encoded as 2 pulses of 1710 T-states each (ie. twice the length of a '0')

The initial polarity of the signal does not matter - everything in the ROM loader is edge-triggered rather than level-triggered.

  • 1
    With the potential caveat: tape input is achieved through the Z80 in a busy loop, constantly polling a 1-bit conversion of the input wave. So a commercial title can do pretty much anything it wants as to bit encoding and baud rate. – Tommy Nov 17 at 21:31
6

Those variable amplitudes looks like electronics problem like failing caps somewhere along the way (recording/playback) or unshielded too long cables or partial remagnetization or even HW bug (some recorders like ELTA have a bug in writing head circuitry that corrupted tapes a bit each time it was played ...)

the correct output should be a rectangular signal with 2 levels of amplitude.

I do not know any tools for tapes but audio people are using AUDACITY

However writing own SW recognizing pulses and correcting the signal should be easy to do...

Here is captured GIF from mine emulator executing:

SAVE "xxx" CODE 0,16384

SAVE capture

On the left is border and on the right is Oscillogram of the SOUND output going to Soundcard...

[Edit1]

I finally had some time/mood for this. I made an win32 app for filtering the wav files in manner I described in my comments. Here it is:

  • My Win32 ZX_emu 1.56 + tape wav filter app

    both apps are win32 standalone no need to install anything. Read the readme.txt inside zip to know how to use it ... I included also full source code for the filtering app (Borland/Embarcadero BDS 2006 Turbo C++)

    The filter sum all channels into mono and find local min/max peaks and center it around 0 and also rescale to uniform amplitude ... +/- some noise detection/handling. The filter itself is in

    riff_filter_tape.h 
    

    source file in case you want to tweak it ...

I applied it on your GORR30_BallBreaker_A.wav here screenshot so you see the signal change after filtering:

filter preview

Your original wav does not load into my emulator. It does not go pass the first file header (no sync and no error). After filtering It got pass the file header:

header

but error while code:

error

so loader code is not correctly loaded (due to too much corruption of the tape):

code

So try to adjust the tape recorder head (with screw driver) first until you hear more clear sound, then play with volume ... digitize apply filter and try to load

Heh FUXOFT :) he had nice games, brings up memories

  • 1
    PS the last image does not look demagnetized to me its more likely just a problem with higher frequency not passing correctly through the audio path so it has smaller amplitude... so either wrong cap or even not good metalic layer material for that bandwith or even not strong enough writing head as higher frequency needs more energy to magnetize – Spektre Nov 17 at 10:16
  • 1
    What an emulator saves as a digital waveform is irrelevant for comparing with what a real (cheap and nasty) tape recorder saved on to real (cheap and nasty) tape - which is what the original spectrum decoder was designed to handle! – alephzero Nov 17 at 15:11
  • 1
    @alephzero You missed my point I just wanted to show there is no nasty PWM technique used by native BASIC SAVE commands only simple FM modulation with 2 frequencies on data and 3th on sync (start) so amplitude of signal is irelevant ... and not some nasty encoding technique – Spektre Nov 17 at 16:06
  • 1
    @Spektre There are many utilities for converting MP3 to WAV, like ffmpeg. There is a fundamental difference in uploading and downloading files of different sizes to a file hosting service. In WAV - 1Gb, In MP3 - 150Mb. – A. Rumlin Nov 17 at 16:37
  • 1
    @A.Rumlin had some time to play with this today. It took me while to implement loading from wavs into my emulator but it finally works (till now it uses tap file and audio input but your recording is bad for going through DAC/ADC again). After sharpening the pulses the result is much better (hearable and also loading sripes apear as should) but still not good enough for sucesfull load so I need to test the centering of signal (center the peaks around zero and then amplify cut off ...) will get back with results but have no clue when as this week is full already... – Spektre Nov 18 at 18:22

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.