amstrad file format on tapes. How its done.

[gabriel0]

Hello.
I'm intrested how looks like file format on the tapes. What it contains, and why exactly this frequences it uses. Why it have this lenght and all I can find out. For example heading>timing>file name> data> checksum etc.

And how amstrad reading this files. What it needs to be properly readed like signal strength, frequency, deviation % etc.

[ralferoo]

Hello.
I'm intrested how looks like file format on the tapes. What it contains, and why exactly this frequences it uses. Why it have this lenght and all I can find out. For example heading>timing>file name> data> checksum etc.

The first part is all answered here: https://www.cpcwiki.eu/imgs/5/5d/S968se08.pdf (this is part of SOFT968)

And how amstrad reading this files. What it needs to be properly readed like signal strength, frequency, deviation % etc.

This is harder to answer as there's no clear answer to all of this. The important thing for reading isn't so much the frequency, it's the *timing* between each pulse. The pilot tone consists of a long run of 1 bits (each transition takes twice as long as a 0 bit) followed by a 0 bit. It's the timing gathered during the pilot tone that determines the expected timing during reading.

Both a 0 and a 1 bit consist of two transitions, which provides a lot of resilience to varying volumes (which will change the relative lengths of the high and low values after it goes through a voltage threshold diode). If the pair of transitions is longer than 1.5x the average pilot tone transition length, it's considered a 1 bit, otherwise a 0 bit. There's extra checks for very short or very long pulses, but it's not documented anywhere. If you care about that, you need to read the firmware disassembly, which you can find here: http://cpctech.cpc-live.com/docs/os.asm

[gabriel0]

Great answer! Thanks.

Few days ago i fixed some recordings that was completly unreadable by any emulator (picture 1). This one was recorded by stereo tape head, maybe that was the reason why my wav files looks like this, but it doesnt matter.
Anything that you need to do is put file to the audacity, and select bass-treble option, then set bass to -30dB and thats all. Almost everything works like new. (picture 2). With really bad record i make it twice, and gain a little.

And by few tests, i see that java emulator is the most noise-resistant software. Any other doesn't read files as good as java.

Is there any other known method to fix files like this? Im curious.

[ralferoo]

It's not quite the answer you were asking for, but I suspect the effect here is the residual effect of recording over something that was very loud such that the erase head was unable to get the bias back to zero.

With the standard tape signal, the overall bias is zero, plus or minus a transition, so you shouldn't be seeing the amplitude varying so much between pulses. I'm not at all surprised the tape circuit couldn't load this, as it relies on high and low edges being on different sides of the voltage threshold. I'm amazed any emulator tries to analyse it to figure it out.

The resulting waveform is a lot better, but not perfect. Your success would depend on the volume you played it at.

The difficulty with automatically recovering this type of original signal is that some of the pulses are smaller than the overall bias shift to the next peak, so it's hard to say with any certainty what the correct restoration is. You can guess with better than random chances by taking into account the transition lengths either side, but I doubt there's a specialised filter for this.

[ralferoo]

If this recording is particularly important to you, and you like programming, I suggest writing your own processing tool. You could assign a confidence level to every bit, and try permutations of questionable bits to see if what produces a matching CRC.


You could also extract a lot of the data at the bit level, and just try to guess using your own knowledge of the data what the missing data is, but depending where the ability to parse the data dropped out, if you confuse too many bits, the data will get skewed so later data won't necessarily line up on the byte boundaries you expect.

[GeoffB17]

Not too long ago, I was trying to do some data recovery from a tape.   Eventually we were successful.

This was not for an Amstrad though, the tape was from an Epson HX-20, the tape was a micro-cassette.   However, I suspect there are some similarities with the process.

As noted above, the data on the tape is a audio representation of a stream of bits, and the 0 (zero) bits are represented by one frequency, and the 1 (one) bits by another frequency, usually double the first frequency.   In my case, the two frequencies were 1k and 2k.   The file may comprise a number of blocks, there will be a header block and maybe an end block, and blocks may be repeated.  Each block is numbered.  There was a lead-in stream of bits all the same.

I had a piece of software called HXTAPE, this was written in PHP, and it was supposed to read the data in the .WAV file of the original recording.   It did work, however, it was very tempramental regarding the volume level of the recording, and you needed the .WAV to be a specific format, mono, 8 bit, 11k.   In the end, the recoding we had was too faint to allow processing, and the solution ended up being various manipulations of the recording using Audacity until the input software on the HX-20 would recognise and accept the input.

Remember that the input software will be a reverse version of the software that has created the data, so it OUGHT to be much more clever at processing the data in than anything you might write, you just need to manipulate the recording to help it.

Someone who was helping the project in Australia made an account of what he was doing re Audacity on:

http://www.pjspot.com/hx-20/   (might be https.. - try that as well)

See if anything there is helpful.

The HXTAPE software DOES work, if you have a good recording of the file.   It will convert the recording to a text version that can be read/printed.   AND, it can convert the .txt back into a .WAV that can then be LOADED.   BUT, this is using the file format for the HX, which I assume is different to that used by the Amstrad - but you have the details for that?

Is this any help to you?

Geoff

[lmimmfn]

Dont know if it helps :
https://youtu.be/MAIsOIwgJWA