• Please review our updated Terms and Rules here

Maximum bitrate for storing information on home-quality cassette tapes?

cj7hawk

Veteran Member
Joined
Jan 25, 2022
Messages
2,224
Location
Perth, Western Australia.
Hi all,

I was just wondering what the top practical speed is for storing information on normal audio cassettes.

I was just trying a 1980s era tape with a mono tape recorder, and found it was relatively reliable past 8 KHz, so that made me wonder just how fast tape saving might have gotten had disk drives not come along?

Many tape schemes used either tonal methods or flux reversal recording in different ways. The Spectrum for example stored a 1's at 1023baud and 0's at 2047baud and a mix produced something generally in between.

But that is unbalanced, and doesn't allow for different tape speeds of reading and writing.

Magstrip data used biphase ( FM ) and could allow hand running, because it reset the bit rate with every but - as long as the speed didn't change more than 50% between bits, it can recover the clock and the data.

So if something like FM was used in software with something like a z80, what is the fastest practical speed for saving and writing data to a tape cassette for moving large amounts of data in the 128K+ era had disks not come down in price?

I'm guessing something as much as 16Kbps using MFM would not be out of the question. Which would load an entire 128K of memory from a cassette in just a touch over a minute and could deal with inter-bit changes to the baud rate as well.

Are there any examples of better use of the cassette's natural bandwidth back in the 80s? ( or using similar technology more recently? )

Thanks
David.
 
https://cargandoleches.speccy.org/inicio.en.html was the winner the last time I checked on this with about 10 times the transfer rate using cassettes and close to 25 times the transfer rate using more reliable technology. There were a number of contests for the Spectrum resulting in higher performing cassette logic. Matching discussion threads would do a better job explaining the how than I can.

MFM would probably require more circuitry in the drive preventing the use of a generic cassette deck.

With slight changes to the design and a dedicated drive, one gets streaming tape (D/CAS) which at its end stored 600 MB and transferred data at 242 KB per second.
 
https://cargandoleches.speccy.org/inicio.en.html was the winner the last time I checked on this with about 10 times the transfer rate using cassettes and close to 25 times the transfer rate using more reliable technology. There were a number of contests for the Spectrum resulting in higher performing cassette logic. Matching discussion threads would do a better job explaining the how than I can.

MFM would probably require more circuitry in the drive preventing the use of a generic cassette deck.

With slight changes to the design and a dedicated drive, one gets streaming tape (D/CAS) which at its end stored 600 MB and transferred data at 242 KB per second.

I'm definitely thinking of normal cheap consumer-grade tapes and the kind of tape recorders that sold for $20 to $30 in the early to mid 80s

And recovering the clock to address timing differences between the written and read tape is likely critical.

Also, software processing is how they all did it, so it's all bit tests and loops. That limits it quite a bit.

But FM avoids DC offsets and gives better timing to zero crossings.

Also, it's not too expensive to read in a signal through an opamp with variable gain to allow for user error in the setup.

After that, I'm wondering what a practical limit would be - given the benchmark at around 1 to 2 kbps is pretty low... I was saving some square wave tones to a cassette recorder, and it was stable with reliable crossings up to around 10 KHz. I never tried higher, but if you address tape stretch and timing recover from the signal, it seems a good practical way to go.

You don't need to modify a tape for MFM. You just need a simple algorithm, but you also need to both be able to encode and decode the bits... And you need a balanced signal to avoid DC drift which would significantly affect the timing. MFM would have more complex code involved than FM which would limit it's speed and it's much harder to recover the clock from...
 
The proven practical limit on the Spectrum using a standard cassette deck and FSK was 11 kbps. No one really bothered testing out other systems to their limits since everything else either had very tiny memory spaces or a standard disk system.

It is possible that a more efficient MFM mechanism was overlooked in the 80s but nearly all the MFM floppy designs had a fairly complicated logic board to catch the bits.
 
The proven practical limit on the Spectrum using a standard cassette deck and FSK was 11 kbps. No one really bothered testing out other systems to their limits since everything else either had very tiny memory spaces or a standard disk system.

It is possible that a more efficient MFM mechanism was overlooked in the 80s but nearly all the MFM floppy designs had a fairly complicated logic board to catch the bits.

I've been working on a digital design to decode FM and MFM with counters. There's certainly an easy way to do it via RLL where you double the bit rate and use symbol encoding/decoding to combine/decode 2 bits to a single bit.

One thing I haven't been able to find yet is how they synchronised MFM - It should be possible with a blank section followed by the first transition, but missing is the determination as to whether the first bit is a 0 or a 1.
 
Do you have a link to this? I'd love to find it -
I linked to it in my previous post. That is the lowest transfer rate that software permits if the FAQ is accurate.

Searching for OTLA may turn up some other discussions of high speed cassette port operation.
 
The PXL2000 was a handheld video camera from 1987 that stored the video on normal cassette tapes. In order to store the large amount of information, it ran the tape at 9x speed (16.875 inches per second)! So, it was feasible and implemented in the 80's to push normal cassette tape to the extreme to improve its bandwidth.
 
Hmm
There were a number of fast forward cassette options for computers as well. http://www.trs-80.org/fastload-cassette-interface/ shows one. Consider the price though. More than a stringy floppy and getting close to the floppy drive.

I didn't ask that question, but it was definitely an answer I liked - thank you - :)

Though primarily, I get the feeling that normal cassettes could have handled up to 8 kbps... And reasonably reliably with good interchangeability between cassettes and records.

As long as the clock is recovered every bit, I think cassettes might have been quite tolerant of issues.

I've noticed that the first thing that drops quickly above 2 KHz is the amplitude of the return signal, so extra amplification would be required. At around 8 KHz, the tone sounds very quiet, and I think data might sound a bit like static, which could be problematic for computer recording that relies on the ear to find the start. The signal did seem to be reliable, but was heavily attenuated on record.

So I wonder if, perhaps, there would be a need to be able to handle a few frequencies so as to make the start tones at least more audible?
 
While the topic is unmodified cassette devices... so a bit off topic.

In the late 70's I modified a cassette recorder (cheap $30 unit).
I removed the electronics and built an interface to directly drive the head and provide an amp for playback.
It was saturation recording driving the the head with a digital signal.
It would reliably do 9600bps without any special encoding. just a bit of logic to help with clocking the UART.

I would say the limiting factor of the cassette deck is the electronics. In fairness the the electronics were intended for audio.
 
While the topic is unmodified cassette devices... so a bit off topic.

In the late 70's I modified a cassette recorder (cheap $30 unit).
I removed the electronics and built an interface to directly drive the head and provide an amp for playback.
It was saturation recording driving the the head with a digital signal.
It would reliably do 9600bps without any special encoding. just a bit of logic to help with clocking the UART.

I would say the limiting factor of the cassette deck is the electronics. In fairness the the electronics were intended for audio.

Perfect - that's very close to the kind of information I was looking for.

Was you using any encoding method on the bits? (eg, FM? ) of just pushing the bits straight out to the tape, so something like RLL 0,9 by default?

If it was RLL 0,9 then I have the feeling you need to record this at a much higher speed to avoid the return to zero, though that's far less of a problem when you are driving the heads directly and it's not capacitively coupled, and even floppy drives would likely allow that, though it is out of spec for them by almost double the datasheet tolerance.

Existing circuitry on a tape can still be run somewhat like this as long as the incoming circuitry can appropriately pick up the input. And if you were successful, then it means the bits can probably be pushed that close. At some point they interfere with each other and would slowly self-erase, but given the audio response of a cassette I would expect that this indicates those kinds of speeds are reasonable and approach 1Kbyte/sec - pretty reasonable. Or a minute to load a 64K file.

I should probably note that many floppy drives, despite a high sector rate, were pretty awful in the 80s.

Maybe it was the controllers and software and the nature of the interlace, but even at 125 Kbps ( single density ) if you have a 3:1 interlace then you're down to 41 Kbps, and then if you switch tracks and wait for sync, and start doing things like confirming that you're on the right track, once you start loading large files it quickly slows down even further... Maybe an effective large-file throughput of around 20kbps That's only twice the effective potential rate of a cassette.

After that, of course, if the disk is fragmented it gets worse, and if you're constantly going back to load a directory structure it's going to slow right down in between access and at times, a cassette system might even be faster.

The Stringy Floppies had similar failings for fragmentation, but if everything was aligned well ( which you would attempt to do by default when storing information ) then with a 2:1 interleave, you got a clear run at 40kbps, so it was possible to load 32K over and over at around 4 seconds a time, and the overrun would set up for the next file read... Mind you if that went up to 64K files, that quickly climbed to around 12 seconds, but it did that by heaving headers that allowed the loader to pull the same file over and over without having to refer back to a directory structure since the directory was often embedded in the sector headers.

So I wonder if that means once you go above a normal speed, do you need to start adding sectors and sector headers and break up the load into blocks or can you do it contiguously? It somewhat depends on how you read the data, and whether you can read it non-contiguously or in sectors and that even brings up other questions like formatting and possible error correction?

Timing loops in software don't cope well with anything like memory paging or error correction unless you compensate for it, so I wonder if it would be better to write a large block in smaller sectors.

Also, I'm curious as to whether the same thought that goes into a disk controller could also be applied to a magnetic tape system with an appropriate slow-down... And wondering whether a disk controller card might also make a good tape interface if suitably designed. It would need to supply a square wave rather than a pulse-train, but that's just an output stage away.

Hmmm. More to think about.

I don't think that, outside of a few amateur ideas, that they did much with this during the 80s. Tape was fast enough for smaller computers up to 64K, and once computers got above this level, disk drives and backwards compatability and ROM based PCs as well as no one wanted to load in a new tape loader just so they can fast-load a tape, prevented the medium from being further explored, and set the tone (I know what I did there) for tape based recordings of the era.
 
I was just looking through the audio forums, and they seem to feel, with relative consistency, that 12KHz is a reasonable expectation even from the poorest of tape systems.

eg: https://arstechnica.com/civis/threads/typical-frequency-range-of-a-cassette-tape.848978/

So if the bandwidth is around 12KHz, and then 8KHz would have very low noise and achieving something like FM at 8kbps or MFM at 16Kbps should be quite practical with a tape system with a relatively simple encoder/decoder - or better still, a software defined encoder/decoder - which would work as long as breaks were left in the recording to allow for decoding and relocation but this would also require an incoming sector buffer to store the original bit pattern if a truly software defined scheme was implemented, though the curious thing abou that is that once you head down that path, it might not be memory friendly, but all kinds of encoding methods could be used. It would require a 2:1 oversampling to easily from from FM to MFM though.

I think the biggest problem with 8-12 KHz speeds would be old people.

1743295870984.png

Given the number of "old" people who bought computers in the 80s, it would have been a disaster -

So I'm going to throw a left-field theory out there that the reason we have slow recording to tapes is because of the prevalence of rock music from the 60s to the 80s, coupled with old people who probably tried higher bit rates, recorded them to tape successfully, then played them back and said, "Nothing was recorded" ! So keps taking the frequency down to the 2KHz maximum of the era ! LOL

OLD PEOPLE... It's your fault.

(Yeah, I hit that exact problem with a benchtop experiment with a wave generator and a tape recorder a few days ago... Though I managed to think 4KHz was reasonable until I pulled out the oscilloscope to better see what was coming from the tape deck ).
 
Many of the tape systems were silent. There were modifications listed to allow one to listen to the recording. http://www.trs-80.org/cassette-gazette/ is a 14 page advertisement explaining how to improve tape reliability.

The mass production of cassettes for music also improved the reliability for data storage. The frequent dropouts may have been acceptable for the intended dictation or interview uses. Music needs better. A millisecond loss of signal wrecks any computer file. Some computers solved the problem by storing an ASCII representation of the file and hoping the human can correct whatever partial errors happened. Generally, to get that to work, it was important that all bits maintain the same length so the system will know how many corrupt bits occurred. The more efficient schemes like that used by the IBM PC or Spectrum make it impossible to know the number of bits that were corrupted so the rest of file will never be recovered.
 
Maybe it was the controllers and software and the nature of the interlace, but even at 125 Kbps ( single density ) if you have a 3:1 [interleave] then you're down to 41 Kbps, and then if you switch tracks and wait for sync, and start doing things like confirming that you're on the right track, once you start loading large files it quickly slows down even further... Maybe an effective large-file throughput of around 20kbps That's only twice the effective potential rate of a cassette.

After that, of course, if the disk is fragmented it gets worse, and if you're constantly going back to load a directory structure it's going to slow right down in between access and at times, a cassette system might even be faster.

Yes, but that's about the filesystem, little to nothing to do with the recording media. There's nothing stopping you from treating a floppy diskette as a sequential series of blocks and, in fact, systems did this all the time, whether it was a Unix system putting a tar file on a raw device or a custom backup program with its own storage format read and written sequentially.

The interleave is added due to limitations of the _host system,_ and is nothing to do with the magnetic storage system itself. If, after reading or writing a sector, the host needs some processing time and is not immediately able to start reading/writing the next sector, without interleave the next sector will start passing the head, leaving the host to get ready and then have to wait until that next sector comes around again. Using, say, a 2:1 interleave this lets the host read/write sector one, let the next sector 9 pass while it's doing preparation, and be ready to read write sector 2 as it comes up, rather than having to wait for sectors 2-16 and 1 pass before sector 2 comes around to be read/written. Cassette tapes would have the same problem except that the solution would be to pause playback, finish the processing, and then start the tape drive and wait for block 2 to come up. This would be even slower, since you'd need longer inter-block spacing to handle the stop/start (which is not immediate).

Also, I'm curious as to whether the same thought that goes into a disk controller could also be applied to a magnetic tape system with an appropriate slow-down... And wondering whether a disk controller card might also make a good tape interface if suitably designed. It would need to supply a square wave rather than a pulse-train, but that's just an output stage away.

A pulse train is just a (non-square) wave, so there's no issue here, so long as your pulses are wide enough that the tape can record them. The solution here would seem to me to be what @jlang did (as did Commodore with the Datasette) and use the cassette head like a diskette drive head, driving it with positive and negative edges.

I was just looking through the audio forums, and they seem to feel, with relative consistency, that 12KHz is a reasonable expectation even from the poorest of tape systems.
This is assuming you go with an audio signal; that's the bandwidth which audio cassette tape systems can handle with reasonable fidelity, but far below the bandwidth of the signal recorded on to the tape.

The reason for this is AC bias. The fluctuating multi-frequency signal recorded on audio tapes has an issue where you can get parts of the signal that are "flat(-ish) spots" that drive the change in magnetic flux very little, as seen in Fig. 4 B in the link above. (Remember, magnetic media doesn't record a signal level, it records a change in the level.)

The way they deal with this is to apply a bias signal, which is a constant high-frequency waveform at or above the minimum amplitude required to get good response on top. as you can see in Fig. 5 below, a "quiet" part of an audio signal at a little less than the amplitude required to get good response is raised in amplitude when combined with the bias signal, producing a usable recording. (This bias signal is filtered out by frequency reproduction limits on playback.)

1743314224644.png 1743314339773.png

So it looks to me as if, if you're willing to go "digital" on tape with a signal designed to have enough changes in flux to avoid loss of sync (e.g., FM or MFM), you should be able to get significantly higher rates than with audio given that the tape itself clearly has to be capable of recording at the standard bias signal frequency. The true limit would probably be the erasure frequency, which is designed to be high enough that it cannot properly magnetise the tape in one direction or the other.

The standard bias frequency for cassette tapes varies based on the quality of the recorder and the tape formulation, but ranges from about 41 kHz for the Sony TC-55 (apparently very low) to 105 kHz for a Nakamichi Dragon (one of the best consumer decks ever made) to 150 kHz for a Studer A710 (a high-end professional recorder used mainly in recording studios).

I may well be missing something here, but it would be interesting to modify a decent consumer cassette deck for straight digital recording and playback and see if you could do, say, 60 kHz MFM on it.
 
Digital cassette drives for storage were common during the 70s--embroidery machines and CNC PLC made extensive use. High-speed search was not uncommon. Saturation recording was used (probably NRZI), so no need for bias or even amplifier linearity. If you have a two-track head, you can use the second to record a clock track.

I had a Techtran dual cassette (one R/O, the other R/W) that could even do offline copy.


NCR and others also had such drives. Here are some NCR cassettes rated at 800 bpi:


What was the top speed of the little Pereos microcassette drive?
 
@cj7hawk "Was you using any encoding method on the bits? (eg, FM? ) of just pushing the bits straight out to the tape, so something like RLL 0,9 by default?"

There was no encoding. I used the bitstream directly from the UART. Used tristate buffers to drive the head through current limiting resistors.
A couple of op-amps for read. comparator for zero crossing with hysteresis. Read/Write was controlled by enabling the write buffers.
I used the read edges to re-sync the UART clock to adapt to speed variation. (poor mans digital PLL)

If I were to try this today I would use MFM or PE and a micro to decode it...
 
@cj7hawk "Also, I'm curious as to whether the same thought that goes into a disk controller could also be applied to a magnetic tape system with an appropriate slow-down... And wondering whether a disk controller card might also make a good tape interface if suitably designed. It would need to supply a square wave rather than a pulse-train, but that's just an output stage away. "

You could use a common disk controller chip but it's not a good fit. The controller chip is looking for sector headers to start a write operation. That's not needed for linear tape recording.
It actually gets in the way. You just want to start writing without a (sector) header. A USART would be a better fit.
 
@cj7hawk "Also, I'm curious as to whether the same thought that goes into a disk controller could also be applied to a magnetic tape system with an appropriate slow-down... And wondering whether a disk controller card might also make a good tape interface if suitably designed. It would need to supply a square wave rather than a pulse-train, but that's just an output stage away. "

You could use a common disk controller chip but it's not a good fit. The controller chip is looking for sector headers to start a write operation. That's not needed for linear tape recording.
It actually gets in the way. You just want to start writing without a (sector) header. A USART would be a better fit.
One probably wants a sector header if the tape could be rewound or forwarded under computer control. There needs to be something on the tape to make sure the correct spot of the tape is what gets read.
 
Back
Top