The use of audio cassettes for storing data for home computers was a great example of repurposing an existing invention. Cassettes were sold in a variety of capacities, and labelled with their audio capacity, e.g. a C60 cassette would hold 60 minutes of music.

Cassettes sold for use with computers tended to have a far smaller capacity, typically 15 minutes or less. But while floppy disks were labelled by capacity in bytes, data cassettes were still labelled according to their length (in time). One reason for this is that different computers used different formats, so there was no universal figure to quote.

The Kansas City standard (or Computer Users' Tape Standard) of the 1970s used a 300 baud data rate. After wrapping every 8 bits with a start bit and two stop bits, each byte uses 36.7ms on the tape, making for a raw capacity of ~27.2 bytes per second, or ~1.6 kilobytes per minute. A C15 cassette would therefore have a capacity of just under 24 kilobytes per side. Arranging data into blocks, or the addition of a file name or CRC checks in more advanced formats would reduce this.

A shortcoming of the Kansas City standard was the low data rate, which meant long program load times, and so most home computers used their own, higher capacity formats instead.

I'd like to know how much data the user of a typical microcomputer of the 1980s could expect to store on their cassettes, for comparison with the more clearly stated capacity of floppy disks. As there are too many different formats to ask about in general, I'll narrow the question down to the highest capacity achieved by a commercially released home computer, to give a high-water mark to compare with. Answers in terms of "X kilobytes on a C15 cassette", or "X kilobits per second" would both be acceptable.

So my (rephrased) question is: What was the highest capacity format used by a home computer to store data on an audio cassette?

  • 1
    Agree with @Wilson: very broad question. the number of possible formats is simply too big. Only looking at Sharp desktop and pocket computers I know of at least 4 formats... And that is only on the computers sold in Europe...
    – UncleBod
    Feb 25 '19 at 14:33
  • 1
    @Kaz, Back in the 1970s, I used a printing terminal that replaced an ASR 33 Teletype. It had a dot matrix print head, and it had a cassette drive in place of the paper tape reader and punch. It accepted only special "data cassettes" (basically, an audio cassette with a notch cut out of the top, computerhistory.org/revolution/memory-storage/8/258/1039 ). I never knew what format it used, but it's reasonable to think that it might have been something that ordinary audio tape circuitry could not have handled. Feb 26 '19 at 17:27
  • 1
    I had a quick look into the Coleco Adam, in case anybody is interested. It has a custom tape drive that runs around ten times as fast as a regular one, and it uses that to push 1.4kb/sec. Ordinary tape media, but with a slightly shifted hole to identify it as a Coleco tape. But that still ends up being only about 256kb/tape, with an anemic data rate if the thing were played at a normal speed. So it kind of depends on how you define capacity (and, indeed, how you define 'audio cassette'), but I don't think that looks like a winner.
    – Tommy
    Feb 27 '19 at 22:04
  • 3
    An experiment using QAM modulation on audio cassettes: "The highest raw bitrate I was ever likely to get at low error rates was maybe 32kbps." 32 kbps comes to 21.6MB per 90-minute audio cassette. redfrontdoor.org/blog/?p=795 Feb 28 '19 at 23:01
  • 1
    A lot of the shorter cassettes claimed to have better tape suited to more demanding data usage (lower drop-out and longer life). Of course that could have been marketing crap. The best and most reliable tapes I found were metal tapes. I used these successfully on a modified Nascom 2 at speeds up to 4800 baud (the Nascom 2 's default speeds were 300 & 1200 Kansas). As well as the metal tapes I used a hifi cassette deck.
    – Tim Ring
    May 28 '19 at 10:45

As other answers note, the data rate varied considerably between machines. I'll give two concrete examples from popular machines - the BBC Micro and the Commodore 64.

Acorn adopted the 300-baud "Kansas City" or "CUTS" format for their early machines, and adapted this for higher performance with the BBC Micro. The basic baud rate is 1200, stored using ordinary TTY-modem style 1200/2400Hz FSK, but there is a lot of byte and block level framing which dilutes this in practice.

The standard block size is 256 bytes, plus 24-33 bytes of header and trailing CRC (depending on length of filename), each byte taking 11 bit times (8N2 serial framing). This totals 3080 bits per frame with a 1-character filename, taking 2.5667 seconds on the tape. Add 1.3 seconds of sync tone to allow stopping and restarting the tape motor between blocks.

A long file might thus approach 256 bytes per 3.8667 seconds throughput, or 66.2 bytes per second, in the standard format on the BBC Micro. It was possible to use longer blocks to speed up bulk loading directly into memory, but these files would then not work with the standard byte-by-byte file reading routines; probably some commercial games used this trick to speed up loading and reduce tape manufacturing costs.

At this speed a C30 tape (15 mins per side) could hold a little under 60KB per side.

The C64 had a standard format supported by the KERNAL ROM, and additionally many "fastloader" formats supported by first loading a tiny program in the standard format. Let's start with the standard format, which was designed for robustness rather than speed - its lack of the latter naturally inspired the many fastloader formats.

Instead of FSK, the C64 uses square-wave pulses of three different lengths (352, 512, 672 µs). Each byte consists of 9 bits stored as either a short then medium, or a medium then short - so the total length of each bit is constant. This is followed by a 10th marker bit which includes a long pulse and usually a medium pulse. Thus the total length of each byte is 672+9*352+10*512 = 8960µs, or 111.6 bytes per second raw.

However, like the BBC Micro there is also overall framing which dilutes this somewhat. Most notably, every file is stored on the tape twice in four blocks (HEADER, HEADER REPEAT, DATA, DATA REPEAT). Unlike the BBC Micro however, the data block is continuous (except for SEQ files) and not broken up into smaller blocks. So for large files the data rate for calculating C64 tape capacity approaches half the raw data rate, so about 55 bytes per second. However you could technically use a tape of half that length, and only lose the backup copy provided afterwards.

At this speed a C30 tape could hold about 48KB per side.

C64 fastloaders generally adapted the standard format at the bit level by dropping one of the two pulses needed to store each bit - so either one short or one medium pulse made one bit, and the overall bitrate would be somewhere between the two. Then they would make the pulses themselves shorter and remove some of the less essential robustness features of the standard encoding. There is usually not even an explicit marker between bytes!

An average bitrate of 360µs or 2778bps was typical for fastloaders, though some went significantly faster than this. The overall speed of a large C64 Fastloader file would thus be about 347 bytes per second.

At this speed a C30 tape could hold about 300KB per side, and would be practically as fast as the (rather sluggish by any standards) 1541 floppy drive.


The SAM Coupé had a ZX Spectrum compatible tape data format with programmable save speed and automatic load speed detection. According to the Technical Reference Manual:-

Speed 112 is spectrum speed, 35 is much faster. Faster speeds are less reliable - but 3*spectrum speed should be feasible with many recorders.

The Spectrum saves at ~1500bd average. 3 times that equates to 4500bd average, or 563 bytes/second. So, ignoring the lead-in, header, sync and checksum bits - a C15 tape would theoretically be able to store 15*60*563 = ~500kB on average.


Update: Well, with the question being edited to ask for kilobytes per second,

So my question is: What was the highest capacity format used on an audio cassette, in terms of kilobytes per second?

the whole answer becomes rather simple (*1):

Divide the baud rate by the average number of bits a format used per data byte to get an average KiB/s value.

Thus, it again comes down to the Baud number (see all the way down).

Original answer:

Cassettes used with computers tended to have a far smaller capacity, typically 15 minutes or less. But they were still labelled according to their length, not their data capacity. One reason for this is that different computers used different formats, despite an attempt in the 1970s to create a universal standard.

No, it wasn't. These cassettes featured nothing computer specific. They are simply music cassettes (*2), thus made to run in the same devices (cassette recorders) at the same speed, 4.7625 cm/s (or 1.875 inch/s), thus ~2.85 meter equals one minute, or 42.75m for a C15.

That standard, the Kansas City standard (and the related Computer Users' Tape Standard)

CUTS is Kansas City (see this Question/Answer) - the naming just depends on what association was intended (or avoided). Kansas City if association with Byte magazine was OK, CUTS if not - or in the case of Processor Technology, because they defined it under that name. For more information see this Question/Answer.

used a 300 baud data rate. After wrapping every 8 bits with a start bit and two stop bits, each byte takes 36.7ms of tape, making for a raw capacity of ~27.2 bytes per second, or ~1.6 kilobytes per minute.

Part of the failure of the Kansas City

You wanted to state that CUTS wasn't a failure, as it had been adopted by many manufacturers and sold with millions of computers, right?

So my question is: How much data could these other formats fit on a 15-minute cassette?

Since there in an almost infinite number of formats and use cases, it would be way too broad to answer this. But there's a simple way to get close for machines you're interested in:

  • Step 1: Multiply the baud rate (as its bit/second) of the format in question by 900 (eliminating time and reducing it to the medium in question) to get a gross capacity in bits.

  • Step 2: Divide that by the number of bits this format records per byte (like 10 for many) and you'll get the gross capacity in bytes.

  • Step 3: Subtract the overhead and you'll get the net storage capacity in bytes.

Step 3 may be the most difficult, as block structure and length may depend a lot on what is stored. One large file or many smaller, each with their own headers. Similarly, how much space a user will leave between files to find them later on..

Writing one large block with next to no header will result in almost the gross capacity, while a recording like those used by Commodores, with small blocks, long headers and double recording (for program storage), will yield way less than 50% - with more than one program per tape easily as low as 20%. Since a tape can also store data as well as programs, and data may even be formatted in its own way, it's a pure guessing game.

All of this makes it almost impossible to give even a close number without exact specification of the existing/intended usage.

Following on from that, Which cassette format could store the most data on a C15 cassette?

Look for the one with the least bits per byte and the least overhead. In any case it'll be less than the gross capacity calculated in step 2. In some cases maybe 10% less, in others more than 50%. Your guess is as good as mine.

Bottom line, for a rough comparison, the baud rate will do the job - everything else is application specific.

With that in mind a baud rate table like this can be made:

It might be noteworthy, that depending on recorder and tape material the theoretical maximum when using real cassette material and existing heads is somewhere between 20,000 and 35,000 Bd. But that would need encoding techniques way past 1980s micros.

(Microcomputer) tapes aren't a blocked random access media like disks (or mainframe tapes) - they are in themselves random :))

*1 - Which in turn makes it somewhat ridiculous.

*2 - Except eventually being sold at a higher price per minute :))

  • 1
    Comments are not for extended discussion; this conversation has been moved to chat.
    – Chenmunka
    Feb 26 '19 at 18:05
  • Amstrad CPC supported the user's choice of 1,000 or 2,000 baud. Feb 27 '19 at 19:54
  • "These cassettes featured nothing computer specific" - not quite. They often were leaderless or had very short leaders so you could safely start recording immediately
    – scruss
    Aug 8 '19 at 12:54
  • @scruss the same feature could be found on tapes made for music. Beside that a missing leader tape increases stress on the magnetic tape, it's also mandatory for tape production. Doing without would require some machinery I've never seen (back then). Over the years the leader tape got shortened with every machine generation for cost and time saving reasons. It wasn't a thing dedicated computer tapes. They were produced on the same machines and leader tape length was always set according to the length the machine needed to grab the leader tape and slice it with the magnetic tape - on both ends.
    – Raffzahn
    Aug 8 '19 at 15:40
  • having repaired many a duff computer tape, I can assure you that some of them had no leader at all. Oxide tape straight into the retaining pin in the hub.
    – scruss
    Aug 8 '19 at 21:02

The Nascom II reached 2400 bps with synchronous keying of 2400Hz and 1200Hz and had discrete logic for recovering data. It was very robust and even damaged tapes with audible flutter and loudness variations were often properly read.

I do remember that at the end of the cassette storage era (and beyond) people built cassette interfaces and/or decoding software that put remarkable data rates (approaching IDSN modem data rates) on stereo tape decks with the caveat that you needed to replay them on the same device because identical head alignment was crucial (holds for best analog audio similarly of course). But those devices/software were not standard equipment in any manner and so likely did not exist in numbers exceeding a few hundred.


Back in the days I owned a ZX spectrum clone (still working today). My favorite game was the Elite and after the screen it loaded "large" ~35KByte file containing the game and it loaded in ~5 min That gives The MG cassette loading speed:

35*1024 / 5*60 = ~119.4666 Byte/s

counting just the useful data (no parity bits or CRC ands stuff so just useful data transfer rate).

Back in the days we usually used 90min audio tapes giving approximate capacity of:

119.4666 * 90 * 60 = 645120 Byte = 630 KByte

This matches my experience as latter on when I was transferring my old tapes onto floppies (5.25" DS DD formated to ~420 KByte) single 90min MG tape used cca 1.5 floppies to store the same amount of data...

Of coarse there where turbo loaders and comprimation loaders out there improving the total MG capacity even further.


In 1977 I had a portable cassette recorder with an RS-232 interface that supported 9600 baud. So the capacity depended on the length of the tape. I only needed 64k so that was not an issue with a 30 min tape. It was error-free and I used it (prior to modems) to transport MC6800 code from University ( Prof Compilers was contracted to do the work) then back to Work at Bristol Aerospace Ltd. to burn into UV erasable EPROMs. They never failed. It was downloaded from compiled code on a PDP11? then uploaded to an MOT Exorcisor.

Other times I monitored half duplex data on both Rx Tx using diodes with 3K to ground in a Diode OR arrangement, knowing the threshold for RS-232 was the same as TLL = 1.3V, I didn't need bipolar levels. This helped me monitor my SCADA designs with up to 1 hr data logging and test results between a couple HP9825's that interfaced to smart HP terminals. But the HP9825's had high-speed cartridge drives in 1978 for supporting the autosave of program parameters for instant POR reset recovery. My first HP Basic computers for my 2nd SCADA project in 1978. It was the first time I used DMA and mapped the keyboard into a custom pushbutton SCADA remote control console with real-time ADC and digital feedback.

  • did the portable cassette recorder use both sides of a standard audio tape? Sustained 9600 baud is hard to do reliably, but could be doable reading/writing on the same drive.
    – scruss
    Mar 3 '19 at 20:48
  • I don't recall the details 43 years ago on the cassette or heads type. but I never used both sides of the tape. I suspect it was high quality tape and MFM over 40kHz bias recording. The MFM like Floppies and early HDD's reduces the BW of the signal spectrum ut I never measured it Mar 3 '19 at 20:54

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.