I'll fix this soon by reverting to the Perl version.

from ctape.

Oona, thanks for your reply. And thanks a lot for ctape, an awesome piece of software. I've been looking for something like this for months. I even bought a tape recorder to make my personal, small collection of tapes, just as I had 25 (and more) years ago.
I finally got ctape, the ruby version, to work. However, it works only when it wants to. I had to do the recording at a ridiculously low volume. I do my tests on three different computers, running Ubuntu and Mint, and ctape only works on one of them -- and, as I said, unpredictably.
I'm saving and loading a small file, which occupies a minute or so, to get accustomed with ctape. When I direct the output to a file on the hard disk, with:
./tape-read.rb > file.txt
I don't have a clue if the file is loading or not. If the file were ten, thirty or forty-five minutes long, it would be frustrating to find out whether the loading was successful or not after those ten, thirty, or whatever, minutes. A great feature would be a display on the screen: "loading started" or something like that.
I can't wait for the new, Perl version.
Congratulations on all of your achievements.
Regards,

Gabriel
(Spain)

from ctape.

UPDATE

My computer now communicates flawlessly with the tape recorder/player. I got a tape recorder/player with the little wheel to adjust the tone. This was the key to make it work. I still have to juggle a little to find the right combination of volume and tone though. But the issue was solved. Now the computer sends correctly the signal to the tape recorder, and the tape player in turn sends correctly the signal back to the computer.
I'm using the ruby version of the scripts.

After saving and loading tens of files, I noticed that some of them had a minor corruption. When loading .tar files from tape, for example, Archive Manager can extract the files, but displays an error message. Soon I noticed that .txt files were corrupted too, although they loaded without any error message showing. Almost the same with .jpgs. It turns out that most of the times (but not always) the resulting file which is on tape is exactly one byte shorter than the original. More precisely, it is the very last byte which is left out.

There is an interesting exception. Base64 files never get corrupted. At first I used base64 to encode binaries, .jpgs, tarballs, etc., just to have a way of monitoring the loading process, as text can be shown on stdout as the file loads. It turns out that base64 files never lose the last byte, nor do they get corrupted in any other way for that matter. All base64 files end with the "=" character; I wonder if that has anything to do with it.

from ctape.