Demonstration Cassette

[BSRSteve]

This has been sitting on my shelf for a couple of years, and I always just thought it was the red Demonstration Cartridge. But then today, while I was inventorying some stuff, I noticed that it actually is a Demonstration CASSETTE, presumably for the Keyboard Component (as implied by the directions on the back).

 

And not only is it CIB, but it is still NIS.

[+Lathe26]

Wow, I never saw such a thing.  That is awesome!

 

We should check to see if CMart has any variants... ?

[+stupus]

Wow! Nice! Never seen it....bet cmart hasnt either

[decle]

Nice!  I've probably been a bit slow here, but I just had a bit of a lightbulb moment.

 

Whilst working on an update of the development doc recently I came across this MERT file which Tom and Braxton found in the BSR archive.  MERT is one of three tools (MERT, GERT and MODIT) that APh wrote to create Keyboard Component cassettes (more on this in the programming forum soon).

 

This MERT file suggests the contents of the demo cassette might be:

• Curtain and Intro
• Master Component
• Baseball
• Blackjack
• Space Battle
• Keyboard Component / French
• Exercise / Jack Lalanne
• Stock Analysis
• Split Screens
• Credits
• Closing Curtain

Comparing this list with the contents of the Keyboard Component demo video posted by Keith back in 2007 there seems to be a pretty good match:

 

 

The "Next Show Starts Shortly" message is probably explained by the time required to rewind the tape to the start.

 

Today's lightbulb for me was that Keith's demo probably isn't an overdubbed and edited together piece of video as I had assumed.  Rather it is probably a single take recording, inclusive of the audio commentary, of the K/C demo cassette in operation (yes, yes, I know, I didn't read the description on the video and I'm slow).  And the MERT file might be a small part of the software used to construct the tape.  As such, I think this might be the only contemporary recording of working Keyboard Component software.  It also might represent what is on Steve's tape

 

Edited June 11, 2020 by decle
typos

[Ron The Cat]

Never knew that existed ...the holy grail if that ever hit ebay 

[+JasonlikesINTV]

That's a keeper.

[Intymike]

Imagine showing that demo life on a kc at a con. You would see many jaws drop.  

[intvnut]

30 minutes ago, Intymike said:

Imagine showing that demo life on a kc at a con. You would see many jaws drop.  

Unless I'm dreaming, Intellivision Productions actually did that one year at CGExpo, as I recall.  I think that may have been the same CGExpo that they raffled off a Keyboard Component in its original box (or what was left of the box) for charity.

 

ISTR that they didn't show the demo too many times as the cassette drive was being finnicky.  IIRC you could hit space-bar to trigger some of the transitions.

[mr_me]

You press space bar to fire in space battle and hit in blackjack.  Note the high resolution text overlay when these games are demoed.  I like the end where they have basketball, armor battle, backgammon, and math fun on the screen at the same time in split screen; only eight moving objects at any one time.  That youtube video of this cassette tape is the only recording of jack lalanne and conversational french.

[+Lathe26]

10 hours ago, decle said:

Nice!  I've probably been a bit slow here, but I just had a bit of a lightbulb moment.

 

Whilst working on an update of the development doc recently I came across this MERT file which Tom and Braxton found in the BSR archive.  MERT is one of three tools (MERT, GERT and MODIT) that APh wrote to create Keyboard Component cassettes (more on this in the programming forum soon).

 

...

I look forward to reading that post.  Thanks for all the research in advance!

[Tempest]

Wow!  Very cool.  I love hearing about anything Keyboard Component related.

[+intvsteve]

Amazing!! ?

[decle]

Listening a bit more closely to Keith's video I think we can hear that this is a recording of Keyboard Component software.  I have isolated a small section of the audio which covers the Stock Market and applied some compression in this example:

 

demo1.mp3

 

We are not interested in the narration, just the "quiet" periods of the tape.  For the first 5 seconds there is quite a bit of background noise with what sounds like a tone mixed in with it.  Then, between 5 and 6 seconds, the tone stops.  At 6 seconds it restarts just before the narrative, at which point it is drowned out.  Once the discussion of the stock analysis program finishes the tone can be heard again through to 28 seconds at which point it stops for a second before restarting at 29 seconds.

 

This tone in the background tape hiss is the sound of the demo cassette software being loaded, bleeding through from the data track.  The short 1 second gaps in the tone are the "inter-record gap" or IRG between blocks of software. We can hear similar bleedthrough in other recordings of Keyboard Component cassettes.  For example, in this short section of the audio track of RonTheCat's copy of Conversational French:

 

cf1.mp3

 

So I think it is quite clear that the demo is probably a recording of K/C software running.  Unfortunately, despite knowing the frequencies that K/C software uses I don't think Keith's recording is clear enough to be able to isolate and extract the software from it; at least it is beyond my audio skills.

 

Additionally, if we compare the timing of Keith's video with the demo cassette MERT file we can infer that the /TIME directives in the file, which control the placement of data and timing, are probably measured in 1/10ths of second:

 

 

I think this means that if this level of accuracy could be achieved reliably, it would have made it possible to produce lip-synced animations, that according to Wikipedia would have been a reasonable quality.  Now that would have made for an impressive demo in 1980!

 

On 6/11/2020 at 12:28 PM, mr_me said:

That youtube video of this cassette tape is the only recording of jack lalanne and conversational french.

 

This is an interesting observation.  I'm not sure we can say definitively that this video is a recording of Jack LaLanne or Conversational French, although it may be representative of the titles.  Just like the snippets of Basketball or Math Fun in the split screen section of the demo, they may be caricatures put together using PicSe.  The demos of K/C software are likely to be more accurate than the split screen section because both titles were written using the same PicSe framework that seems to be used to construct the demo.  Perhaps the video should come with a "not in-game footage" warning overlaid in K/C text?

 

Here are the sections of original game audio that were used in the demo, again both taken from recordings of RonTheCat's tapes.  First Conversational French:

 

cf2.mp3

 

Ignoring the reordering and selection of just some words from the lesson; the short bursts of "software" sound on the recording suggests that the graphics for each word might have been streamed individually.  However, the demo cassette MERT file suggests that this is not how the software was structured here, with all elements of the French demo being lumped together with the Keyboard Component introduction as one large block of software:

 

 

And here we can see the constituent parts of the French demo (FRDEMO), including what I suspect are the graphics for la chemise and la robe:

 

 

And here is the Jack LaLanne situps section.  It comes as the first exercise in what seem to have been regular fitness tests used to track your progress.  As you can hear, Jack recorded several versions of the introduction to provide some variety:

 

jl1.mp3

 

More information about the structure of K/C cassettes and the software used to construct them can be found in the latest update to the Intellivision development description (as well as plenty of other, hopefully interesting, stuff ).

 

Edited June 14, 2020 by decle
Added comments on lip-sync

[mr_me]

True, it's not exactly conversational french and jack lalanne cassettes.  Conversational french has been described having a figure of the instructor's face, lips moving while she speaks and jack lalanne having music, in ay38914, during exercises.

[Games For Your Intellivision]

On 6/11/2020 at 3:57 PM, intvnut said:

Unless I'm dreaming, Intellivision Productions actually did that one year at CGExpo, as I recall.  I think that may have been the same CGExpo that they raffled off a Keyboard Component in its original box (or what was left of the box) for charity.

 

ISTR that they didn't show the demo too many times as the cassette drive was being finnicky.  IIRC you could hit space-bar to trigger some of the transitions.

I experienced the demo too running at the Classic Gaming Expo in Las Vegas. I think it was around 2004. 

[+Lathe26]

15 hours ago, decle said:

So I think it is quite clear that the demo is probably a recording of K/C software running.  Unfortunately, despite knowing the frequencies that K/C software uses I don't think Keith's recording is clear enough to be able to isolate and extract the software from it; at least it is beyond my audio skills.

While unlike to be successful, I thought I'd take a mild crack at decoding the software.

 

Short answer: While more was able to be figured out, I wasn't able to decode the software.  The main problem is simply that the signal-to-noise ratio is too poor.

 

Long answer: I took demo1.mp3, heavily filtered it to only leave 1.5Hz and at 3Hz, and performed some noise reduction as well.  Unfortunately, unlike the ECS that uses multiple frequency cycles per bit, the KC uses very short audio signals (half cycle of 1.5kHz is a ZERO and a full cycle of 3.0kHz is a ONE).  When the signal-to-noise ratio is poor, processing the audio is sensitive to frequency shifts and amplitude changes (worse, some might be introduced by the original audio file's audio compression).  Worse, the sections with human audio massively swamped out any digital data so the data might be unrecoverable in those sections.

 

What I was able to see is that:

1. 23 sec - 27 sec - Lot's of 8 bit data (more below).  In the below image, look at the evenly spaced little arrows.
2. 27 sec - 28 sec - Lot's of 0 bits (mostly 3.0kHz signal).  In the below image, look at the big left arrow.
3. 28 sec - 29 sec - Silence
4. 29 sec - 30 sec - 600 bits of 0 to indicate Start-Of-Frame (last 0.2 sec).  In the below image, look at the big right arrow.

 

Regarding #1, why is that 8 bit data with the little arrows?  This is an educated guess because:

1. The ZERO hotspots (1.5kHz) are each 1 "chunk" apart (0.1850 sec)
2. The ZERO hotspots are each 2 "lines" long (0.02466 sec)
3. The few ONE hotspots (3.0kHz) are between the ZERO hotspots
4. In a decle that only contains 8-bits of useful data, bits 8 and 9 are typically zero.

A further guess, assuming the above is correct, is that most likely it is graphics data for the next section starting at 30 sec (alternatively, it could be a LOT of text or could be 6502 machine code but I assume these are less likely).

 

demo1 Filtered at 1.5kHz and 3.0kHz.mp3

 

Definitions:

1. A bit is 0.3333 msec long (half cycle of 1.5kHz is a ZERO and a full cycle of 3.0kHz is a ONE).
2. A line is a 5 bit header (hardcoded as 11101) and 32 bits of payload.  It is 12.33 msec long.
3. A chunk is 15 lines.  It is 185.0 msec long.
4. A frame is a 600 zero bits (200 msec) followed by many chunks, often around 90 chunks but can be longer or shorter.  A frame with 90 chunks is 16850 msec.

[intvnut]

14 hours ago, Games For Your Intellivision said:

I experienced the demo too running at the Classic Gaming Expo in Las Vegas. I think it was around 2004. 

It would have been some other year. 2004 was in San Jose.

 

4 hours ago, Lathe26 said:

(half cycle of 1.5kHz is a ZERO and a full cycle of 3.0kHz is a ONE)

I thought that wasn't quite true.  IIRC, it's Manchester encoded, so you get a half-cycle of 1.5kHz if there's no bit-change, and full cycle of 3kHz if there is.  (Differential Manchester has the property you described.)  Or am I mis-remembering?

 

20 hours ago, decle said:

At 6 seconds it restarts just before the narrative, at which point it is drowned out.

There is a digital track recorded next to the prerecorded audio track that contains an odd, semi-repeating pattern.  Frank and I hypothesize it's a time-code of sorts, used to keep animations in sync with pre-recorded audio.  It does not fit the same encoding scheme as the 37 x 15 data chunks.

 

I never quite isolated that part of the 6502 EXEC, but Frank might have. 

 

For everyone else's benefit:  Digital data is encoded in chunks of 15 words holding 37 bits, with a small leader before each chunk.  The header is four 32-bit words containing a cute V pattern in the bitmap:

      00000000 00000000 00000000 01111110
      00000000 00000000 00000000 10111101
      00000000 00000000 00000000 11011011
      00000000 00000000 00000000 11100111

Within the chunk itself, as @Lathe26 states, each 37 bit line consists of 5 framing bits and 32 payload bits.  The 5 bits are framing bits have a fixed value (11101).  The remaining 32 bits form one bit-plane of 15-bit data.  That is, one word corresponds to "bit 14" for the 32 words, the next for "bit 13", etc.  (I believe they're sent MSB first.)  The 15-bit words contain 5 bits of SECDED code (not classic Hamming, but isomorphic to it), and 10 bits of data payload.  The bit-plane encoding spreads dropout errors across multiple ECC words.

 

(Side note:  The SECDED code was apparently designed by Dean Inada.  (I forget who told us that.)  It uses three sets of rotated 5-bit values, each with 3 ones and 2 zeros, to represent the syndromes for each of the 15 bits.  It's actually slightly better than SECDED, because the error-correct code will try to fix 2-bit errors by taking positions where we saw Manchester violations/carrier loss into account and trying again.)

 

 

Here is an excerpt from some tape data Frank and I analyzed (mostly Frank):

00000000000000000000000000000000
00000000000000000000000000000000
00000000000000000000000000000000
00000000000000000000000000000000
00000000000000000000000000000000
00000000000000000000000000000000
00000000000000000000000000000000
00000000000000000000000000000000
00000000000000000000000000000000
00000000000000000000000000000000
00000000000000000000000000000000
00000000000000000000000000000000
00000000000000000000000000000000
00000000000000000000000000000000
00000000000000000000000000000000
00000000000000000000000000000000

00000000000000000000000001111110
00000000000000000000000010111101
00000000000000000000000011011011
00000000000000000000000011100111

['1110100000000010000000000000000000000']
['1110110000000100000000000000000000000']
['1110110100000100000000000000000000001']
['1110100000000110000000000000000000000']
['1110110000000110000000000000000000001']
['1110100000000000000000000000000000001']
['1110100000000000000000000000000000000']
['1110100000000100000000000000000000000']
['1110100000000000000000000000000000000']
['1110100000000100000000000000000000001']
['1110100000000100000000000000000000000']
['1110100100000110000000000000000000000']
['1110100100000110000000000000000000001']
['1110100100000100000000000000000000001']
['1110110000000010000000000000000000000']

['1110111110111111011111100100100111010']
['1110101101110101110101011011000000101']
['1110111101001110101010101101100111011']
['1110101111110100111001010011000010100']
['1110110111111001010000110111110011101']
['1110100000000001001110001001001100010']
['1110101100000110000000010010010000100']
['1110100001010000111110001000001100000']
['1110101000100100000100010011000000100']
['1110101001100100001110011010000100100']
['1110101101000110001110011010010100100']
['1110100011000010001010001001010100000']
['1110110111111010011000111110100001100']
['1110100001100000001001000001001010000']
['1110100010000000000110000000001110011']

['1110111110111111011111100100100111010']
['1110101101110101110101011011000000101']
['1110111101001110101010101101100111011']
['1110101111110100111001010011000010100']
['1110110111111001010000110111110011101']
['1110100000000001001110001001001100010']
['1110101100000110000000010010010000100']
['1110100001010000111110001000001100000']
['1110101000100100000100010011000000100']
['1110101001100100001110011010000100100']
['1110101101000110001110011010010100100']
['1110100011000010001010001001010100000']
['1110110111111010011000111110100001100']
['1110100001100000001001000001001010000']
['1110100010000000000110000000001110011']

 

 Data that's predominately 8 bits will have two 37-bit frames (or lines, as @Lathe26 calls them) that are all zeros except for the 5-bit sync.  @Lathe26  hinted at this, but didn't draw the connection between bits 8/9 being zero and two whole frames/lines being zero.

 

ASCII data will have three such lines, like this:

['1110101010101001000010010100100001000']
['1110101000100000101011100110000100010']
['1110110000100100010010010111000010001']
['1110111000011101101011010110100101001']
['1110101110110000000001010100101111010']
['1110100000000000000000000000000000000']
['1110100000000000000000000000000000000']
['1110100000000000000000000000000000000']
['1110111110111101111011110111001110011']
['1110100000000000000000000000100001000']
['1110110010000100010011010001000100011']
['1110101100010000000000010010001000000']
['1110100000011001010010100111000010010']
['1110111000110100000011100010000110001']
['1110111100000100101000010110001010011']

And, in fact, the block above contains ASCII:

 

SKIP\0
BNDS\0
DATA\0
VRFY\0
EOT\0
IRG\0
US

 

(The \0 are literal zero bytes, ASCII NUL.)

 

There's also a different kind of block that appears during pre-recorded audio tracks:  Timing code blocks.  The timing-code data retains the 37-bit framing, but doesn't seem to encode the data the same.  Instead, it has a repeating 8-record pattern that almost forms a sort of Gray code.

 

Here are some notes I took many years ago, while Frank and I were actively picking apart one of his dumps:

Timing blocks are repeating 8-record patterns involving the following
8 bit patterns:

a. 11111011
b. 01111011
c. 10110101
d. 10110100
e. 01001010
f. 01001000
g. 00000100


Interestingly, each bit pattern has one more 0 in it than the
previous pattern.

The 32-bit word divides up into several fields:

  sync         g    e    c    a      ?         f    d    b
['11101, 000, 010, 000, 111, 101, 0, 1000000, 000, 111, 001']
['11101, 000, 000, 110, 001, 111, 0, 0000000, 100, 001, 111']
['11101, 000, 000, 001, 110, 111, 0, 1000000, 001, 100, 111']
['11101, 000, 001, 000, 111, 110, 0, 1000000, 000, 111, 100']
['11101, 000, 000, 111, 000, 111, 0, 1000000, 110, 000, 111']
['11101, 000, 100, 000, 111, 011, 0, 1000000, 000, 110, 011']
['11101, 000, 000, 100, 011, 111, 0, 1000000, 000, 011, 110']
['11101, 000, 000, 011, 100, 111, 0, 1000000, 011, 000, 111']

In each column, the corresponding bit pattern appears, rotated
through three different rotations:  0, +3, +6.

The pattern starts out with 16 37 word records of all zeros
(except the sync word).  Then, bit pattern trio 'a' shows up.
16 records later, pattern 'b' gets added.  16 records after that,
pattern 'c' gets added, and so on.  Once pattern 'g' is added,
there's no further changes.

New patterns arriving correspond to the '0' in the column marked
with a '?'.



Rotations of the bit patterns, given in hex:

a. 11111011     FB F7 EF DF BF 7F FE FD
b. 01111011     7D F6 ED DB B7 6F DE BD
c. 10110101     D5 6B D6 AD 5B B6 6D DA
d. 10110100     B4 69 D2 A5 4B 96 2D 5A
e. 01001010     4A 94 29 52 A4 49 92 25
f. 01001000     48 90 21 42 84 09 12 24
g. 00000100     04 08 10 20 40 80 01 02


Are the codes rotations of each other with just another bit removed?

a. 11111011
b. 01111011
c. 01101011
d. 01101001
e. 00101001
f. 00001001
g. 00000001

 

 

I know Frank spent a lot more time on this after where my notes leave off, and he did share more of his progress with me.  I haven't had the time to dig through and internalize it all yet.

 

[+Lathe26]

35 minutes ago, intvnut said:

I thought that wasn't quite true.  IIRC, it's Manchester encoded, so you get a half-cycle of 1.5kHz if there's no bit-change, and full cycle of 3kHz if there is.  (Differential Manchester has the property you described.)  Or am I mis-remembering?

 

Mostly, I used the below post as reference material (click the "decle replied to a topic" part).  It says the bits use Differential Manchester encoding and also uses the term "line" instead of "frame".  However, this post is from 2 years and maybe more has been discovered since then.

 

Regarding ASCII, excellent point about it being 7-bit which means there would have been 3 lines / frames of zeros, not the 2 that were actually observed.  When I tossed out the idea that the data might be text, my mind was thinking UTF-8 which of course didn't exist back then.  Doh!
 

 

[intvnut]

11 minutes ago, Lathe26 said:

Mostly, I used the below post as reference material (click the "decle replied to a topic" part).  It says the bits use Differential Manchester encoding and also uses the term "line" instead of "frame".  However, this post is from 2 years and maybe more has been discovered since then.

Actually, you're right, and I'm wrong.

 

I had remembered what Frank told me, but I did not remember the correction Frank sent me when we were sharing notes with Decle while he was getting the KC tape up and running.  From Frank in June 2018:

Quote

Good question.  The problem is that I shouldn't have been saying "Manchester Encoding".  It is a related coding scheme called "Biphase Mark Coding"
(Adding Joe because this is a correction to my previous descriptions )

And "biphase mark coding" is another name for Differential Manchester.

 

It actually makes sense.  True Manchester doesn't tolerate a signal inversion.

 

As for "line" / "frame"... I don't think I've used the terms entirely consistently.  I'd love to get whatever terms Mattel / APh were using and stick to those.

Edited June 15, 2020 by intvnut

[intvnut]

21 minutes ago, intvnut said:

As for "line" / "frame"... I don't think I've used the terms entirely consistently.  I'd love to get whatever terms Mattel / APh were using and stick to those.

 

Going through more of my old mail, Decle had outlined it for me, and pointed to the docs.  Page 33 of http://papaintellivision.com/pdfs/CCF10232011_00020.pdf

 

It seems there isn't a Mattel term for the 37-bit structure.  But a group of 15 of them is a chunk, and a group of chunks is a record.  If we have to pick a really descriptive term, how about bitplane word? 

 

[Alex.Pace]

I indeed have two different demo cassettes for keyboard component.

But I didn't know any box existing.

 

 

 

[+Steve Jones]

On 6/11/2020 at 1:04 AM, BSRSteve said:

This has been sitting on my shelf for a couple of years, and I always just thought it was the red Demonstration Cartridge. But then today, while I was inventorying some stuff, I noticed that it actually is a Demonstration CASSETTE, presumably for the Keyboard Component (as implied by the directions on the back).

 

And not only is it CIB, but it is still NIS.

Hey Steve, do you have a picture of the back, I'm curious what the instructions were? Could a cassette run on a loop like a cartridge could?

 

[Walter Ives]

On 6/10/2020 at 11:36 PM, decle said:

Today's lightbulb for me was that Keith's demo probably isn't an overdubbed and edited together piece of video as I had assumed.  Rather it is probably a single take recording, inclusive of the audio commentary, of the K/C demo cassette in operation (yes, yes, I know, I didn't read the description on the video and I'm slow).  And the MERT file might be a small part of the software used to construct the tape.  As such, I think this might be the only contemporary recording of working Keyboard Component software.  It also might represent what is on Steve's tape

Yup.

 

On 6/10/2020 at 11:36 PM, decle said:

The "Next Show Starts Shortly" message is probably explained by the time required to rewind the tape to the start.

Yup.

 

On 6/11/2020 at 4:28 AM, mr_me said:

You press space bar to fire in space battle and hit in blackjack.  Note the high resolution text overlay when these games are demoed.

Although the instructions say press the space bar, recollections are that you can press any key. The computer only takes over playing for the user if no one hits a key within a certain amount of time.

On 6/11/2020 at 4:28 AM, mr_me said:

I like the end where they have basketball, armor battle, backgammon, and math fun on the screen at the same time in split screen; only eight moving objects at any one time. 

The demo leaves you with the memory that all four games had played at the same time. That, the opening-closing curtains, the fireworks, the 2001 theme, the animated master component, the games playing themselves, the syncing of the audio to the action, the amount of graphics—do any of you who actually write your own games for the Intellivision care to venture an opinion as to how this program compares in sophistication to a typical game?

 

On 6/14/2020 at 1:27 AM, decle said:

Additionally, if we compare the timing of Keith's video with the demo cassette MERT file we can infer that the /TIME directives in the file, which control the placement of data and timing, are probably measured in 1/10ths of second:

 

 

I think this means that if this level of accuracy could be achieved reliably, it would have made it possible to produce lip-synced animations, that according to Wikipedia would have been a reasonable quality.  Now that would have made for an impressive demo in 1980!

This inference isn't quite right. While RIBs were aligned to the nearest tenth of a second, tape position within a record was known more precisely. Best recollections are that the internal time code counter had a resolution of one field to match the precision with which phoneme position could be read from the SMPTE encoded master recordings and the display update rate. CP1600 side programs could easily check this counter every field interrupt. A software PLL kept time code continuity across inter-record gaps. The CPU2 monitor did have to reacquire the time code after a search, though.

On 6/14/2020 at 1:27 AM, decle said:

I'm not sure we can say definitively that this video is a recording of Jack LaLanne or Conversational French...

Well, I can definitively state that the audio was taken from the master audio recordings and most of the assembly language statements used to implement the segments were taken from the programs under development. Is that sufficient to say that "this video is a recording of Jack LaLanne or Conversational French?" I'll leave that bit of semantics to you.

 

On 6/14/2020 at 5:04 PM, Lathe26 said:

worse, some might be introduced by the original audio file's audio compression

Almost spit out my drink when reading this.

 

On 6/14/2020 at 5:04 PM, Lathe26 said:

A bit is 0.3333 msec long (half cycle of 1.5kHz is a ZERO and a full cycle of 3.0kHz is a ONE).

As I have commented at some length elsewhere on this forum, Differential Manchester encoding isn't a form of FSK and you are ill-advised to analyze a Manchester-encoded signal as a series of half sine waves. You have to cut off of a lot of toes to make FSK thinking fit into that particular slipper and the result is not pretty. It is only the time-position of the transitions that is important and if you force the waveform to be half waves those transitions will jitter about the point where the decoder is expecting them. Preprocessing which affects the positions of those transitions, like feeding the signal through a pair of 1.5 kHz and 3.0 kHz notch filters or mp3 compressing your source data, are contraindicated. You don't need pretty-looking half-wave peaks, you need sharp and precisely located zero crossings. Nothing else matters.

So stay out of the frequency domain! Use the time domain. Sample at, oh, 8 times the nominal data rate should be sufficient. That works out to 43.2 million samples per track of a full C60 tape (which is 30 minutes per side). But here's the good news: you only need one bit per sample, a zero or a one, so your file will only be 5.4 Mbytes long. I would think that would compare rather favorably with your .mp3 file sizes.