This is the home page of the Worldwide Network of Active Users of Dave Beazley's Python3 implementation of the Kansas City Standard's web site.
I'm also the author of the Worldwide Network of Active CTAPE Users' Website (see link in the left column).
Everything I had to say about CTAPE remains valid, I still subscribe what I
wrote a while ago about it. And it all can be applied to Dave's Python3 scripts
as well, mutatis mutandis, as it all actually applies to usind compact cassette
tapes to store computer data.
My actual interest is using tapes to store computer data. I'm refering the
reader to my text Praise of CTAPE (in my web site about CTAPE). And as I said
there, I'm not willing to explain why my pastime is this every freaking time.
It just is so.
I actually began with Dave Beazley's before I found Oona Räisänen's ruby
scripts. Oona's is much faster than the Kansas City Standard. Hers does not
comply to any standard, but rather it is a one-of-a-kind implementation.
I've given Oona's a chance first. I am now returning to Dave's scripts for this
reason: the files I save to tape with CTAPE don't survive long. The longest a
file managed to survive is exactly eighteen months. And this could happen only
because I was using 60 minutes or less type II tapes. With 90 minutes, type II
tapes, the files survived only for a few minutes. They could be loaded back only
right after saving them, and that was it. That was so regardless of the
operating system or the type of deck. I got the same results with Linux and
Cygwin, and with three different tape decks. With type I tapes of less than 60
minutes the files could survive for some months, and with type I tapes of 90
minutes I could never load back a single file.
Back in the day, my ZX Spectrum files (games) survived for years -- four at least, in my experience, simply because I could not check them for any longer as I switched to a DOS PC in 1990 or so.
So today, 16 of December 2016, I recorded many short files in several different
tapes, using Dave's scripts. I will keep my readers updated through this web
Comments are welcomed.
Here I am providing a BASH script to use Dave's two Python3 scripts. Download
the kcs.tar.gz file, extract the three files, put them in an executable path and give
executing permissions to them. Then call it by typing kcs. The arguments are
load and save. With save, the next argument has to be the name of a file or a
foder. With load no other argument is needed and the script will load a file to
the $PWD. I am providing s and write as synonyms for save, and l and read as
synonyms for load. Typing kcs help provides some minimal help.
The entire set, my humble BASH script plus Dave's two Python3 scripts, depends on: BASH, python3, sox, tar, base64, binutils, and sed.
The main obstacle to overcome is the fact that Dave's implementation of the
Kansas City Standard works only with text. So to overcome this I first convert
the file to base64. The BASH script does it all. I had to overcome the fact
that I increased the lenght of this already long (in seconds or minutes) format (KCS +
base64), so I compress the base64 with tar. My hope is that tar will offset
base64 (in seconds or minutes), which doesn't really happen, but hey.
Other inconvenience I had to overcome is the fact that the load routine trims
non-printable characters but still leaves some 'garbage' in the form of random
ASCII characters. So I add two marks, one at the beggining of the base64 file
and the other at its end, before saving it to tape, so that I could cleanly
trim the text file with sed and extract only a valid base64 chunk.
The script saves the wav file, the base64 text file and the tar file in /tmp and then cleans it all.
To become a member of the Worldwide Network of Active Users of Dave Beazley's
Python3 implementation of the Kansas City Standard you have to use it actively.
Curious folks are not welcomed :) Come here regularly and post about your
experience using these scripts. I will be the self-appointed President of this
Network until other members challenge me and demand for a transparent structure
for a representative decision-making body. Upon what will we decide what --
beats me :)
Update: Six months later
Today, 25 of June 2017 I can say that I can't load back any of those recordings from tape. Regarding reliability, Dave's scripts are more or less as good as Ctape, perhaps less. I don't know. I will leave this page on for a while to keep this failure report for posterity. Actually, please clone this page somewhere else :)