jremington:
After looking at the signal for a few more minutes, it seems clear that the clock signal is about 4166 Hz and the data are Manchester encoded.Arbitrarily assigning a L->H transition as a "1", a very long sequence of 1/0 preamble is followed by a 11 start and then the data, so the first few bits including the "11" sequence are as shown below. Of course the inverse assumption leads to a "00" start followed by inverted data bits.
The lower track is a 4166 Hz square wave generated by Audacity, aligned so that the bits may be read off directly from the signal transitions occurring on the falling edge of the clock.
There is an Arduino Manchester library at GitHub - mchr3k/arduino-libs-manchester but it is pretty specific for transmitting and receiving short messages by radio and does not appear to be very well written. If you want to decode the data, I would suggest to start with one of the two decoding options presented by Atmel at http://www.atmel.com/images/atmel-9164-manchester-coding-basics_application-note.pdf
I agree with your supposition that the manual description is not valid. The actual data stream does not fit the description.
Based on your work it appears the byte rate is about 500 bytes/sec. If the aim is to just replace the cassette, not decode the stream, the UNO should be able to handle it. The byte boundaries do not even need to be identified, just store the bit stream and replicate it at the chosen frequency.
How long was the preamble? Do you think the preamble needs to be a fixed length, or 'just enough' to sync?
The manual description explicitly states the the phase is irrelevant? I would want to inspect the actual hardware too see if it matches the description. If the hardware is only detecting zero crossings the phase could be inferred by the preamble. If the preamble is 10100101 but 01011010 is detected then the decode() could impose the correction before the data is returned.
Good work @jremington!
Chuck.