Megalextoria
Retro computing and gaming, sci-fi books, tv and movies and other geeky stuff.

Home » Digital Archaeology » Computer Arcana » Apple » Apple II » Data on Cassette?
Show: Today's Messages :: Show Polls :: Message Navigator
E-mail to friend 
Switch to threaded view of this topic Create a new topic Submit Reply
Data on Cassette? [message #388868] Wed, 20 November 2019 18:10 Go to next message
Anonymous
Karma:
Originally posted by: Prof. Justin

Many moons ago people saved their data to compact cassettes.

using minimodem on macOS I'm trying to recreate this just to see how
much I can save on a C60 cassette. I'm aware of the kansas city
standard - I'm not using that because I can't find anything modern that
will support it.

minimodem is for HAM radio, but I have had good luck recording data at
2400 baud. I wondr if I can go faster.

cat file.txt | minimodem -t 2400 -f file.txt.wav or flac

produces a sound file that i record to tape. Then I play back the tape
and capture the audio via a line-in or aux cable to another wav.

minimodem -r 2400 -f file.txt.wav > out.txt

gives me what should be my original file. sometimes it works,
sometimes it doesn't. I think the connection between the player and
receiving machine is making too much noise.

Has anyone tried this? Offer any advice? Thanks!

I used the following commsnd to encode a file "small.txt" at 2400 baud.
The wav is 450k, the original file is a 1k ASCII file.

cat small.txt | minimodem -t 2400 -f small.txt.wav

filebin.net/0qwjd56iela5fb3n
Re: Data on Cassette? [message #388871 is a reply to message #388868] Wed, 20 November 2019 22:55 Go to previous messageGo to next message
Anonymous
Karma:
Originally posted by: Frank M.

maybe try a reel-to-reel for higher fidelity?
Re: Data on Cassette? [message #388878 is a reply to message #388868] Thu, 21 November 2019 09:36 Go to previous messageGo to next message
David Schmidt is currently offline  David Schmidt
Messages: 993
Registered: October 2012
Karma: 0
Senior Member
On 11/20/19 6:10 PM, Prof. Justin wrote:
> Many moons ago people saved their data to compact cassettes.
> [...]
> Has anyone tried this?  Offer any advice?  Thanks!

Possibly related, some resources you may want to explore - some recent
forays into audio transcoding:

https://github.com/datajerk/c2t
https://knzl.at/poor-mans-adt/
Re: Data on Cassette? [message #388879 is a reply to message #388871] Thu, 21 November 2019 16:40 Go to previous messageGo to next message
Anonymous
Karma:
Originally posted by: Prof. Justin

On 2019-11-21 03:55:14 +0000, Frank M. said:

> maybe try a reel-to-reel for higher fidelity?

I disagree. Modern type II cassettes are far better than those old
reels. Interesting suggestion though.

Right now I think my problem is the cable from the player to the
computer. To save time i'm using CDs to make sure there's no audio
quality problem. Plus its faster, I don't have to record at 1x speed.
Re: Data on Cassette? [message #388885 is a reply to message #388879] Fri, 22 November 2019 02:25 Go to previous messageGo to next message
Michael J. Mahon is currently offline  Michael J. Mahon
Messages: 1767
Registered: October 2012
Karma: 0
Senior Member
Prof. Justin <alt.ei-04dws6g@yopmail.com> wrote:
> On 2019-11-21 03:55:14 +0000, Frank M. said:
>
>> maybe try a reel-to-reel for higher fidelity?
>
> I disagree. Modern type II cassettes are far better than those old
> reels. Interesting suggestion though.
>
> Right now I think my problem is the cable from the player to the
> computer. To save time i'm using CDs to make sure there's no audio
> quality problem. Plus its faster, I don't have to record at 1x speed.
>
>

There are several likely “distortions” attributable to tape decks,
particularly inexpensive tape decks (which most cassette decks are).

The most troublesome is flutter, resulting from rapid variations in tape
transport speed. Modem signaling is not designed to tolerate frequency
shifts.

A variant of flutter is wow, or slower variations in tape transport speed.
Again, not well tolerated by modem signaling.

Finally, amplitude fluctuations can result from inconstant head-to-tape
contact or tape guiding errors. It can also be caused by variations in
oxide thickness in substandard cassettes, though that is probably not
applicable to your case. Such variations are often tolerated by low baud
rate modem coding, but higher rates are more susceptible to error.

It’s worth pointing out that the magnitude of these distortions can double
if the same deck is used for both recording and playback.

Using CDRs will eliminate all of these error sources.

In all audio cabling it’s important to avoid noise inducing ground loops.
This is actually an advantage of inexpensive battery-powered cassette
decks.

--
-michael - NadaNet 3.1 and AppleCrate II: http://michaeljmahon.com
Re: Data on Cassette? [message #388887 is a reply to message #388879] Fri, 22 November 2019 10:59 Go to previous messageGo to next message
Anonymous
Karma:
Originally posted by: Frank M.

On Thursday, November 21, 2019 at 1:40:24 PM UTC-8, Prof. Justin wrote:
> On 2019-11-21 03:55:14 +0000, Frank M. said:
>
>> maybe try a reel-to-reel for higher fidelity?
>
> I disagree. Modern type II cassettes are far better than those old
> reels. Interesting suggestion though.
>
> Right now I think my problem is the cable from the player to the
> computer. To save time i'm using CDs to make sure there's no audio
> quality problem. Plus its faster, I don't have to record at 1x speed.


Your post set off a bit of research and now I finally know why my 25 year old mix tapes sound so crummy (90s neon tdk type 1 cassette tapes).

you can also use a phone or ipad to play the audio... (linked from c2t github)
http://asciiexpress.net/gameserver/
http://asciiexpress.net/diskserver/

also a great way to bootstrap a machine with no serial card (ADT also has similar functionality).

f
Re: Data on Cassette? [message #388972 is a reply to message #388885] Wed, 27 November 2019 09:42 Go to previous messageGo to next message
Anonymous
Karma:
Originally posted by: Prof. Justin

On 2019-11-22 07:25:12 +0000, Michael J. Mahon said:

> Prof. Justin <alt.ei-04dws6g@yopmail.com> wrote:
>> On 2019-11-21 03:55:14 +0000, Frank M. said:
>>
>>> maybe try a reel-to-reel for higher fidelity?
>>
>> I disagree. Modern type II cassettes are far better than those old
>> reels. Interesting suggestion though.
>>
>> Right now I think my problem is the cable from the player to the
>> computer. To save time i'm using CDs to make sure there's no audio
>> quality problem. Plus its faster, I don't have to record at 1x speed.
>>
>>
>
> There are several likely “distortions” attributable to tape decks,
> particularly inexpensive tape decks (which most cassette decks are).
>
> The most troublesome is flutter, resulting from rapid variations in tape
> transport speed. Modem signaling is not designed to tolerate frequency
> shifts.
>
> A variant of flutter is wow, or slower variations in tape transport speed.
> Again, not well tolerated by modem signaling.
>
> Finally, amplitude fluctuations can result from inconstant head-to-tape
> contact or tape guiding errors. It can also be caused by variations in
> oxide thickness in substandard cassettes, though that is probably not
> applicable to your case. Such variations are often tolerated by low baud
> rate modem coding, but higher rates are more susceptible to error.
>
> It’s worth pointing out that the magnitude of these distortions can double
> if the same deck is used for both recording and playback.
>
> Using CDRs will eliminate all of these error sources.
>
> In all audio cabling it’s important to avoid noise inducing ground loops.
> This is actually an advantage of inexpensive battery-powered cassette
> decks.

I actually have it working at 2400 baud on normal type I cassettes.
I tried using a Sony CFD-S70 - it has an AUX-IN and seems loud enough
to be a direct drive rather than belts that turn to mush. ALso, good
results with a Radio Shack CTR-102 - same deal, direct drive and AUX-IN.
The problem I have now is consistency; and lack of free time to experiment!
Re: Data on Cassette? [message #388973 is a reply to message #388878] Wed, 27 November 2019 09:44 Go to previous messageGo to next message
Anonymous
Karma:
Originally posted by: Prof. Justin

On 2019-11-21 14:36:36 +0000, David Schmidt said:

> On 11/20/19 6:10 PM, Prof. Justin wrote:
>> Many moons ago people saved their data to compact cassettes.
>> [...]
>> Has anyone tried this?  Offer any advice?  Thanks!
>
> Possibly related, some resources you may want to explore - some recent
> forays into audio transcoding:
>
> https://github.com/datajerk/c2t
> https://knzl.at/poor-mans-adt/

Fascinating!

I might be able to steal an idea from that.
Re: Data on Cassette? [message #388987 is a reply to message #388972] Wed, 27 November 2019 17:30 Go to previous messageGo to next message
Michael J. Mahon is currently offline  Michael J. Mahon
Messages: 1767
Registered: October 2012
Karma: 0
Senior Member
Prof. Justin <alt.ei-04dws6g@yopmail.com> wrote:
> On 2019-11-22 07:25:12 +0000, Michael J. Mahon said:
>
>> Prof. Justin <alt.ei-04dws6g@yopmail.com> wrote:
>>> On 2019-11-21 03:55:14 +0000, Frank M. said:
>>>
>>>> maybe try a reel-to-reel for higher fidelity?
>>>
>>> I disagree. Modern type II cassettes are far better than those old
>>> reels. Interesting suggestion though.
>>>
>>> Right now I think my problem is the cable from the player to the
>>> computer. To save time i'm using CDs to make sure there's no audio
>>> quality problem. Plus its faster, I don't have to record at 1x speed.
>>>
>>>
>>
>> There are several likely “distortions” attributable to tape decks,
>> particularly inexpensive tape decks (which most cassette decks are).
>>
>> The most troublesome is flutter, resulting from rapid variations in tape
>> transport speed. Modem signaling is not designed to tolerate frequency
>> shifts.
>>
>> A variant of flutter is wow, or slower variations in tape transport speed.
>> Again, not well tolerated by modem signaling.
>>
>> Finally, amplitude fluctuations can result from inconstant head-to-tape
>> contact or tape guiding errors. It can also be caused by variations in
>> oxide thickness in substandard cassettes, though that is probably not
>> applicable to your case. Such variations are often tolerated by low baud
>> rate modem coding, but higher rates are more susceptible to error.
>>
>> It’s worth pointing out that the magnitude of these distortions can double
>> if the same deck is used for both recording and playback.
>>
>> Using CDRs will eliminate all of these error sources.
>>
>> In all audio cabling it’s important to avoid noise inducing ground loops.
>> This is actually an advantage of inexpensive battery-powered cassette
>> decks.
>
> I actually have it working at 2400 baud on normal type I cassettes.
> I tried using a Sony CFD-S70 - it has an AUX-IN and seems loud enough
> to be a direct drive rather than belts that turn to mush. ALso, good
> results with a Radio Shack CTR-102 - same deal, direct drive and AUX-IN.
> The problem I have now is consistency; and lack of free time to experiment!
>
>

Way to go!

I saw a demonstration of an interactive system in 1966-1967 that used a
tape-recorded modem session in lieu of an actual modem connection, since
the actual host system was unavailable.

I think it was running at 2400 or 4800 baud. The tape recorder used was a
Teac reel-to-reel, probably at 7.5 ips.

--
-michael - NadaNet 3.1 and AppleCrate II: http://michaeljmahon.com
Re: Data on Cassette? [message #389004 is a reply to message #388871] Fri, 29 November 2019 10:56 Go to previous messageGo to next message
Anonymous
Karma:
Originally posted by: Don Schrank

On Wednesday, November 20, 2019 at 9:55:15 PM UTC-6, Frank M. wrote:
> maybe try a reel-to-reel for higher fidelity?

I, for one, would love to see that in action. A B&H reel2reel attached to a black apple ][+ would make a great video.
Re: Data on Cassette? [message #389005 is a reply to message #388987] Fri, 29 November 2019 12:42 Go to previous messageGo to next message
Anonymous
Karma:
Originally posted by: Prof. Justin

On 2019-11-27 22:30:04 +0000, Michael J. Mahon said:

> Prof. Justin <alt.ei-04dws6g@yopmail.com> wrote:
>> On 2019-11-22 07:25:12 +0000, Michael J. Mahon said:
>>
>>> Prof. Justin <alt.ei-04dws6g@yopmail.com> wrote:
>>>> On 2019-11-21 03:55:14 +0000, Frank M. said:
>>>>
>>>> > maybe try a reel-to-reel for higher fidelity?
>>>>
>>>> I disagree. Modern type II cassettes are far better than those old
>>>> reels. Interesting suggestion though.
>>>>
>>>> Right now I think my problem is the cable from the player to the
>>>> computer. To save time i'm using CDs to make sure there's no audio
>>>> quality problem. Plus its faster, I don't have to record at 1x speed.
>>>>
>>>>
>>>
>>> There are several likely “distortions” attributable to tape decks,
>>> particularly inexpensive tape decks (which most cassette decks are).
>>>
>>> The most troublesome is flutter, resulting from rapid variations in tape
>>> transport speed. Modem signaling is not designed to tolerate frequency
>>> shifts.
>>>
>>> A variant of flutter is wow, or slower variations in tape transport speed.
>>> Again, not well tolerated by modem signaling.
>>>
>>> Finally, amplitude fluctuations can result from inconstant head-to-tape
>>> contact or tape guiding errors. It can also be caused by variations in
>>> oxide thickness in substandard cassettes, though that is probably not
>>> applicable to your case. Such variations are often tolerated by low baud
>>> rate modem coding, but higher rates are more susceptible to error.
>>>
>>> It’s worth pointing out that the magnitude of these distortions can double
>>> if the same deck is used for both recording and playback.
>>>
>>> Using CDRs will eliminate all of these error sources.
>>>
>>> In all audio cabling it’s important to avoid noise inducing ground loops.
>>> This is actually an advantage of inexpensive battery-powered cassette
>>> decks.
>>
>> I actually have it working at 2400 baud on normal type I cassettes.
>> I tried using a Sony CFD-S70 - it has an AUX-IN and seems loud enough
>> to be a direct drive rather than belts that turn to mush. ALso, good
>> results with a Radio Shack CTR-102 - same deal, direct drive and AUX-IN.
>> The problem I have now is consistency; and lack of free time to experiment!
>>
>>
>
> Way to go!
>
> I saw a demonstration of an interactive system in 1966-1967 that used a
> tape-recorded modem session in lieu of an actual modem connection, since
> the actual host system was unavailable.
>
> I think it was running at 2400 or 4800 baud. The tape recorder used was a
> Teac reel-to-reel, probably at 7.5 ips.


1200 baud is the limit without error correction. I think that's
another major problem.

I just tried it with a 64k jpg, didn't work.

But this time I'm encoding to base64 first, I should have done that in
the first place but I tried to take a shortcut.

% base64 square.jpg > square.jpg.b64
% cat square.jpg.b64 | minimodem -t 1200 -f square1200.b64.wav

Is this works, I'll try UUE and then YENC.

I'm using the RadioShack CTR-102 and a NOW Maxell Professional C30
(15m/side) type I casette. I wanted a small time cassette so the tape
itself would be thicker. I'll let you know the results, but I'm
working - on Black Friday.

Here's the file I'm encoding and the resulting WAV

https://filebin.net/6uu7zynffshlub1a

The more I think about it, thie more I think it won't work without
error correction. What I'm doing is more for HAM radio and
broadcasting over 2m bands. I think. The highest they go is 1200 baud.
Re: Data on Cassette? [message #389006 is a reply to message #389004] Fri, 29 November 2019 12:42 Go to previous messageGo to next message
Anonymous
Karma:
Originally posted by: Prof. Justin

On 2019-11-29 15:56:20 +0000, Don Schrank said:

> On Wednesday, November 20, 2019 at 9:55:15 PM UTC-6, Frank M. wrote:
>> maybe try a reel-to-reel for higher fidelity?
>
> I, for one, would love to see that in action. A B&H reel2reel attached
> to a black apple ][+ would make a great video.

I'll put that on my STD list!
Re: Data on Cassette? [message #389009 is a reply to message #389005] Fri, 29 November 2019 18:00 Go to previous messageGo to next message
Michael J. Mahon is currently offline  Michael J. Mahon
Messages: 1767
Registered: October 2012
Karma: 0
Senior Member
Prof. Justin <alt.ei-04dws6g@yopmail.com> wrote:
> On 2019-11-27 22:30:04 +0000, Michael J. Mahon said:
>
>> Prof. Justin <alt.ei-04dws6g@yopmail.com> wrote:
>>> On 2019-11-22 07:25:12 +0000, Michael J. Mahon said:
>>>
>>>> Prof. Justin <alt.ei-04dws6g@yopmail.com> wrote:
>>>> > On 2019-11-21 03:55:14 +0000, Frank M. said:
>>>> >
>>>> >> maybe try a reel-to-reel for higher fidelity?
>>>> >
>>>> > I disagree. Modern type II cassettes are far better than those old
>>>> > reels. Interesting suggestion though.
>>>> >
>>>> > Right now I think my problem is the cable from the player to the
>>>> > computer. To save time i'm using CDs to make sure there's no audio
>>>> > quality problem. Plus its faster, I don't have to record at 1x speed.
>>>> >
>>>> >
>>>>
>>>> There are several likely “distortions” attributable to tape decks,
>>>> particularly inexpensive tape decks (which most cassette decks are).
>>>>
>>>> The most troublesome is flutter, resulting from rapid variations in tape
>>>> transport speed. Modem signaling is not designed to tolerate frequency
>>>> shifts.
>>>>
>>>> A variant of flutter is wow, or slower variations in tape transport speed.
>>>> Again, not well tolerated by modem signaling.
>>>>
>>>> Finally, amplitude fluctuations can result from inconstant head-to-tape
>>>> contact or tape guiding errors. It can also be caused by variations in
>>>> oxide thickness in substandard cassettes, though that is probably not
>>>> applicable to your case. Such variations are often tolerated by low baud
>>>> rate modem coding, but higher rates are more susceptible to error.
>>>>
>>>> It’s worth pointing out that the magnitude of these distortions can double
>>>> if the same deck is used for both recording and playback.
>>>>
>>>> Using CDRs will eliminate all of these error sources.
>>>>
>>>> In all audio cabling it’s important to avoid noise inducing ground loops.
>>>> This is actually an advantage of inexpensive battery-powered cassette
>>>> decks.
>>>
>>> I actually have it working at 2400 baud on normal type I cassettes.
>>> I tried using a Sony CFD-S70 - it has an AUX-IN and seems loud enough
>>> to be a direct drive rather than belts that turn to mush. ALso, good
>>> results with a Radio Shack CTR-102 - same deal, direct drive and AUX-IN.
>>> The problem I have now is consistency; and lack of free time to experiment!
>>>
>>>
>>
>> Way to go!
>>
>> I saw a demonstration of an interactive system in 1966-1967 that used a
>> tape-recorded modem session in lieu of an actual modem connection, since
>> the actual host system was unavailable.
>>
>> I think it was running at 2400 or 4800 baud. The tape recorder used was a
>> Teac reel-to-reel, probably at 7.5 ips.
>
>
> 1200 baud is the limit without error correction. I think that's
> another major problem.

Since ordinary copper phone lines were used quite successfully at up to
9600 baud without the digital equalization of later modems, and good tape
recordings easily surpass the audio quality of phone lines, I think it’s
safe to say that 1200 baud is not the limit.

Of course, error correction is always good to have, but was always a
property of higher-level software, not the base modem signaling.

> I just tried it with a 64k jpg, didn't work.
>
> But this time I'm encoding to base64 first, I should have done that in
> the first place but I tried to take a shortcut.

Modems and transmission media deal with 8-bit bytes, so no conversion to
lower density codes is necessary. The original motivation for 6- or 7-bit
encodings of 8-bit data had to do with prevailing datacomm standards, not
with the underlying medium.

> % base64 square.jpg > square.jpg.b64
> % cat square.jpg.b64 | minimodem -t 1200 -f square1200.b64.wav
>
> Is this works, I'll try UUE and then YENC.
>
> I'm using the RadioShack CTR-102 and a NOW Maxell Professional C30
> (15m/side) type I casette. I wanted a small time cassette so the tape
> itself would be thicker. I'll let you know the results, but I'm
> working - on Black Friday.

I think you’ll find that no cassette tape is thicker than C60 tape.

> Here's the file I'm encoding and the resulting WAV
>
> https://filebin.net/6uu7zynffshlub1a
>
> The more I think about it, thie more I think it won't work without
> error correction. What I'm doing is more for HAM radio and
> broadcasting over 2m bands. I think. The highest they go is 1200 baud.

Any transmission medium is susceptible to errors. Therefore error detection
is always a good idea. Error correction is enabled by error detection, and
can range from fine-grained automatic correction to coarse-grained manual
correction.

In the context of older microcomputers, packet-level protocol retry or even
file-level manual retry was pretty standard. ;-)

For example, NadaNet uses packet-level error detection to trigger
protocol-level retry.

When no real-time interaction is available, as with recorded data, forward
error correction is required, requiring encoding redundancy sufficient to
achieve the desired overall reliability in the presence of the expected
error rate.

--
-michael - NadaNet 3.1 and AppleCrate II: http://michaeljmahon.com
Re: Data on Cassette? [message #389028 is a reply to message #389009] Mon, 02 December 2019 12:10 Go to previous messageGo to next message
Anonymous
Karma:
Originally posted by: Prof. Justin

On 2019-11-29 23:00:32 +0000, Michael J. Mahon said:

> Prof. Justin <alt.ei-04dws6g@yopmail.com> wrote:
>> On 2019-11-27 22:30:04 +0000, Michael J. Mahon said:
>>
>>> Prof. Justin <alt.ei-04dws6g@yopmail.com> wrote:
>>>> On 2019-11-22 07:25:12 +0000, Michael J. Mahon said:
>>>>
>>>> > Prof. Justin <alt.ei-04dws6g@yopmail.com> wrote:
>>>> >> On 2019-11-21 03:55:14 +0000, Frank M. said:
>>>> >>
>>>> >>> maybe try a reel-to-reel for higher fidelity?
>>>> >>
>>>> >> I disagree. Modern type II cassettes are far better than those old
>>>> >> reels. Interesting suggestion though.
>>>> >>
>>>> >> Right now I think my problem is the cable from the player to the
>>>> >> computer. To save time i'm using CDs to make sure there's no audio
>>>> >> quality problem. Plus its faster, I don't have to record at 1x speed.
>>>> >>
>>>> >>
>>>> >
>>>> > There are several likely “distortions” attributable to tape decks,
>>>> > particularly inexpensive tape decks (which most cassette decks are).
>>>> >
>>>> > The most troublesome is flutter, resulting from rapid variations in tape
>>>> > transport speed. Modem signaling is not designed to tolerate frequency
>>>> > shifts.
>>>> >
>>>> > A variant of flutter is wow, or slower variations in tape transport speed.
>>>> > Again, not well tolerated by modem signaling.
>>>> >
>>>> > Finally, amplitude fluctuations can result from inconstant head-to-tape
>>>> > contact or tape guiding errors. It can also be caused by variations in
>>>> > oxide thickness in substandard cassettes, though that is probably not
>>>> > applicable to your case. Such variations are often tolerated by low baud
>>>> > rate modem coding, but higher rates are more susceptible to error.
>>>> >
>>>> > It’s worth pointing out that the magnitude of these distortions can double
>>>> > if the same deck is used for both recording and playback.
>>>> >
>>>> > Using CDRs will eliminate all of these error sources.
>>>> >
>>>> > In all audio cabling it’s important to avoid noise inducing ground loops.
>>>> > This is actually an advantage of inexpensive battery-powered cassette
>>>> > decks.
>>>>
>>>> I actually have it working at 2400 baud on normal type I cassettes.
>>>> I tried using a Sony CFD-S70 - it has an AUX-IN and seems loud enough
>>>> to be a direct drive rather than belts that turn to mush. ALso, good
>>>> results with a Radio Shack CTR-102 - same deal, direct drive and AUX-IN.
>>>> The problem I have now is consistency; and lack of free time to experiment!
>>>>
>>>>
>>>
>>> Way to go!
>>>
>>> I saw a demonstration of an interactive system in 1966-1967 that used a
>>> tape-recorded modem session in lieu of an actual modem connection, since
>>> the actual host system was unavailable.
>>>
>>> I think it was running at 2400 or 4800 baud. The tape recorder used was a
>>> Teac reel-to-reel, probably at 7.5 ips.
>>
>>
>> 1200 baud is the limit without error correction. I think that's
>> another major problem.
>
> Since ordinary copper phone lines were used quite successfully at up to
> 9600 baud without the digital equalization of later modems, and good tape
> recordings easily surpass the audio quality of phone lines, I think it’s
> safe to say that 1200 baud is not the limit.
>
> Of course, error correction is always good to have, but was always a
> property of higher-level software, not the base modem signaling.


Good points. Something strange is happening then. Maybe I have potato
quality cables.


>
>> I just tried it with a 64k jpg, didn't work.
>>
>> But this time I'm encoding to base64 first, I should have done that in
>> the first place but I tried to take a shortcut.
>
> Modems and transmission media deal with 8-bit bytes, so no conversion to
> lower density codes is necessary. The original motivation for 6- or 7-bit
> encodings of 8-bit data had to do with prevailing datacomm standards, not
> with the underlying medium.

All the other videos on youtube using minimodem convert to ascii.

>
>> % base64 square.jpg > square.jpg.b64
>> % cat square.jpg.b64 | minimodem -t 1200 -f square1200.b64.wav
>>
>> Is this works, I'll try UUE and then YENC.
>>
>> I'm using the RadioShack CTR-102 and a NOW Maxell Professional C30
>> (15m/side) type I casette. I wanted a small time cassette so the tape
>> itself would be thicker. I'll let you know the results, but I'm
>> working - on Black Friday.
>
> I think you’ll find that no cassette tape is thicker than C60 tape.

I found that out about an hour after I ordered it off eBay. Ha!

>
>> Here's the file I'm encoding and the resulting WAV
>>
>> https://filebin.net/6uu7zynffshlub1a
>>
>> The more I think about it, thie more I think it won't work without
>> error correction. What I'm doing is more for HAM radio and
>> broadcasting over 2m bands. I think. The highest they go is 1200 baud.
>
> Any transmission medium is susceptible to errors. Therefore error detection
> is always a good idea. Error correction is enabled by error detection, and
> can range from fine-grained automatic correction to coarse-grained manual
> correction.
>
> In the context of older microcomputers, packet-level protocol retry or even
> file-level manual retry was pretty standard. ;-)
>
> For example, NadaNet uses packet-level error detection to trigger
> protocol-level retry.
>
> When no real-time interaction is available, as with recorded data, forward
> error correction is required, requiring encoding redundancy sufficient to
> achieve the desired overall reliability in the presence of the expected
> error rate.

I might throw in the towell. If I'm not too pooped tonight I'll take
another stab. But, I'm going to make sure all my cables don't move
around when I'm capturing from the tape.
I'm also going to put a 200Hz tone at the beginning so I don't get that
volume increase. I think there's somerthing weird going there. Its as
if the receiver is trying to compensate.
Re: Data on Cassette? [message #389029 is a reply to message #388887] Mon, 02 December 2019 12:11 Go to previous messageGo to next message
Anonymous
Karma:
Originally posted by: Prof. Justin

On 2019-11-22 15:59:52 +0000, Frank M. said:

> On Thursday, November 21, 2019 at 1:40:24 PM UTC-8, Prof. Justin wrote:
>> On 2019-11-21 03:55:14 +0000, Frank M. said:
>>
>>> maybe try a reel-to-reel for higher fidelity?
>>
>> I disagree. Modern type II cassettes are far better than those old
>> reels. Interesting suggestion though.
>>
>> Right now I think my problem is the cable from the player to the
>> computer. To save time i'm using CDs to make sure there's no audio
>> quality problem. Plus its faster, I don't have to record at 1x speed.
>
>
> Your post set off a bit of research and now I finally know why my 25
> year old mix tapes sound so crummy (90s neon tdk type 1 cassette tapes).
>
> you can also use a phone or ipad to play the audio... (linked from c2t github)
> http://asciiexpress.net/gameserver/
> http://asciiexpress.net/diskserver/
>
> also a great way to bootstrap a machine with no serial card (ADT also
> has similar functionality).
>
> f

Interesting, but I'm not sure that will apply to me since I'm using
modern equipment. I'll save the links though, I might be able to get
an idea or two!
Re: Data on Cassette? [message #389032 is a reply to message #389028] Mon, 02 December 2019 19:04 Go to previous messageGo to next message
Michael J. Mahon is currently offline  Michael J. Mahon
Messages: 1767
Registered: October 2012
Karma: 0
Senior Member
Prof. Justin <alt.ei-04dws6g@yopmail.com> wrote:

<snip history>

>>>
>>>
>>> 1200 baud is the limit without error correction. I think that's
>>> another major problem.
>>
>> Since ordinary copper phone lines were used quite successfully at up to
>> 9600 baud without the digital equalization of later modems, and good tape
>> recordings easily surpass the audio quality of phone lines, I think it’s
>> safe to say that 1200 baud is not the limit.
>>
>> Of course, error correction is always good to have, but was always a
>> property of higher-level software, not the base modem signaling.
>
>
> Good points. Something strange is happening then. Maybe I have potato
> quality cables.

You can find out if you’re picking up noise from the computer to the tape
drive by playing back some recorded silence. Noise pickup in the other
direction is a bit tricky, since the tape drive is connected to a modem.
But you can at least verify that the cable is OK by plugging it into a
PC/Mac audio card six input. It should sound just as it does if you play it
back into an audio amplifier. If you record it using the sound card, you
can view the recorded waveform to verify the presence or absence of hum,
distortion, or even high-frequency noise (as from a switching power supply
or CFL light).

>>
>>> I just tried it with a 64k jpg, didn't work.
>>>
>>> But this time I'm encoding to base64 first, I should have done that in
>>> the first place but I tried to take a shortcut.
>>
>> Modems and transmission media deal with 8-bit bytes, so no conversion to
>> lower density codes is necessary. The original motivation for 6- or 7-bit
>> encodings of 8-bit data had to do with prevailing datacomm standards, not
>> with the underlying medium.
>
> All the other videos on youtube using minimodem convert to ascii.

That is required for text-based store-and-forward communication and email.
Since you are not going through any non-8-bit safe network, it’s not
required.

Computer networks typically use signaling incorporating control characters
that are acted upon rather than preserved, so if the data is presumed to be
text, control characters may disappear and high bits may not be preserved.

>>
>>> % base64 square.jpg > square.jpg.b64
>>> % cat square.jpg.b64 | minimodem -t 1200 -f square1200.b64.wav
>>>
>>> Is this works, I'll try UUE and then YENC.
>>>
>>> I'm using the RadioShack CTR-102 and a NOW Maxell Professional C30
>>> (15m/side) type I casette. I wanted a small time cassette so the tape
>>> itself would be thicker. I'll let you know the results, but I'm
>>> working - on Black Friday.
>>
>> I think you’ll find that no cassette tape is thicker than C60 tape.
>
> I found that out about an hour after I ordered it off eBay. Ha!
>
>>
>>> Here's the file I'm encoding and the resulting WAV
>>>
>>> https://filebin.net/6uu7zynffshlub1a
>>>
>>> The more I think about it, thie more I think it won't work without
>>> error correction. What I'm doing is more for HAM radio and
>>> broadcasting over 2m bands. I think. The highest they go is 1200 baud.
>>
>> Any transmission medium is susceptible to errors. Therefore error detection
>> is always a good idea. Error correction is enabled by error detection, and
>> can range from fine-grained automatic correction to coarse-grained manual
>> correction.
>>
>> In the context of older microcomputers, packet-level protocol retry or even
>> file-level manual retry was pretty standard. ;-)
>>
>> For example, NadaNet uses packet-level error detection to trigger
>> protocol-level retry.
>>
>> When no real-time interaction is available, as with recorded data, forward
>> error correction is required, requiring encoding redundancy sufficient to
>> achieve the desired overall reliability in the presence of the expected
>> error rate.
>
> I might throw in the towell. If I'm not too pooped tonight I'll take
> another stab. But, I'm going to make sure all my cables don't move
> around when I'm capturing from the tape.
> I'm also going to put a 200Hz tone at the beginning so I don't get that
> volume increase. I think there's somerthing weird going there. Its as
> if the receiver is trying to compensate.

Good idea. Most battery-powered cassette decks incorporate “auto-level”
recording, which can mess up what we’re intended to be fixed recording
levels.

You may want to reconsider the use of modem signal encoding. Woz’s cassette
encoding is quite efficient and reliable, and uses pulse-duration
modulation.

The data is recovered by measuring the time between zero crossings, making
it relatively insensitive to signal amplitude, and with a 2:1 ratio between
“0” and “1” encoding, it’s pretty tolerant of speed variations. And with
an effective bit rate of about 1333 bps, it’s reasonably fast.

--
-michael - NadaNet 3.1 and AppleCrate II: http://michaeljmahon.com
Re: Data on Cassette? [message #389033 is a reply to message #389029] Mon, 02 December 2019 19:04 Go to previous messageGo to next message
Michael J. Mahon is currently offline  Michael J. Mahon
Messages: 1767
Registered: October 2012
Karma: 0
Senior Member
Prof. Justin <alt.ei-04dws6g@yopmail.com> wrote:
> On 2019-11-22 15:59:52 +0000, Frank M. said:
>
>> On Thursday, November 21, 2019 at 1:40:24 PM UTC-8, Prof. Justin wrote:
>>> On 2019-11-21 03:55:14 +0000, Frank M. said:
>>>
>>>> maybe try a reel-to-reel for higher fidelity?
>>>
>>> I disagree. Modern type II cassettes are far better than those old
>>> reels. Interesting suggestion though.
>>>
>>> Right now I think my problem is the cable from the player to the
>>> computer. To save time i'm using CDs to make sure there's no audio
>>> quality problem. Plus its faster, I don't have to record at 1x speed.
>>
>>
>> Your post set off a bit of research and now I finally know why my 25
>> year old mix tapes sound so crummy (90s neon tdk type 1 cassette tapes).
>>
>> you can also use a phone or ipad to play the audio... (linked from c2t github)
>> http://asciiexpress.net/gameserver/
>> http://asciiexpress.net/diskserver/
>>
>> also a great way to bootstrap a machine with no serial card (ADT also
>> has similar functionality).
>>
>> f
>
> Interesting, but I'm not sure that will apply to me since I'm using
> modern equipment. I'll save the links though, I might be able to get
> an idea or two!

The ideas used in c2t are an evolution of Woz’s cassette encoding but
exploiting directly generated signals rather than tape storage.

Data storage on audio tape is the antithesis of modern equipment. ;-)

--
-michael - NadaNet 3.1 and AppleCrate II: http://michaeljmahon.com
Re: Data on Cassette? [message #389037 is a reply to message #389032] Tue, 03 December 2019 11:53 Go to previous messageGo to next message
Anonymous
Karma:
Originally posted by: Prof. Justin

On 2019-12-03 00:04:20 +0000, Michael J. Mahon said:

> Prof. Justin <alt.ei-04dws6g@yopmail.com> wrote:
>
> <snip history>
>
>>>>
>>>>
>>>> 1200 baud is the limit without error correction. I think that's
>>>> another major problem.
>>>
>>> Since ordinary copper phone lines were used quite successfully at up to
>>> 9600 baud without the digital equalization of later modems, and good tape
>>> recordings easily surpass the audio quality of phone lines, I think it’s
>>> safe to say that 1200 baud is not the limit.
>>>
>>> Of course, error correction is always good to have, but was always a
>>> property of higher-level software, not the base modem signaling.
>>
>>
>> Good points. Something strange is happening then. Maybe I have potato
>> quality cables.
>
> You can find out if you’re picking up noise from the computer to the tape
> drive by playing back some recorded silence. Noise pickup in the other
> direction is a bit tricky, since the tape drive is connected to a modem.
> But you can at least verify that the cable is OK by plugging it into a
> PC/Mac audio card six input. It should sound just as it does if you play it
> back into an audio amplifier. If you record it using the sound card, you
> can view the recorded waveform to verify the presence or absence of hum,
> distortion, or even high-frequency noise (as from a switching power supply
> or CFL light).
>
>>>
>>>> I just tried it with a 64k jpg, didn't work.
>>>>
>>>> But this time I'm encoding to base64 first, I should have done that in
>>>> the first place but I tried to take a shortcut.
>>>
>>> Modems and transmission media deal with 8-bit bytes, so no conversion to
>>> lower density codes is necessary. The original motivation for 6- or 7-bit
>>> encodings of 8-bit data had to do with prevailing datacomm standards, not
>>> with the underlying medium.
>>
>> All the other videos on youtube using minimodem convert to ascii.
>
> That is required for text-based store-and-forward communication and email.
> Since you are not going through any non-8-bit safe network, it’s not
> required.
>
> Computer networks typically use signaling incorporating control characters
> that are acted upon rather than preserved, so if the data is presumed to be
> text, control characters may disappear and high bits may not be preserved.
>
>>>
>>>> % base64 square.jpg > square.jpg.b64
>>>> % cat square.jpg.b64 | minimodem -t 1200 -f square1200.b64.wav
>>>>
>>>> Is this works, I'll try UUE and then YENC.
>>>>
>>>> I'm using the RadioShack CTR-102 and a NOW Maxell Professional C30
>>>> (15m/side) type I casette. I wanted a small time cassette so the tape
>>>> itself would be thicker. I'll let you know the results, but I'm
>>>> working - on Black Friday.
>>>
>>> I think you’ll find that no cassette tape is thicker than C60 tape.
>>
>> I found that out about an hour after I ordered it off eBay. Ha!
>>
>>>
>>>> Here's the file I'm encoding and the resulting WAV
>>>>
>>>> https://filebin.net/6uu7zynffshlub1a
>>>>
>>>> The more I think about it, thie more I think it won't work without
>>>> error correction. What I'm doing is more for HAM radio and
>>>> broadcasting over 2m bands. I think. The highest they go is 1200 baud.
>>>
>>> Any transmission medium is susceptible to errors. Therefore error detection
>>> is always a good idea. Error correction is enabled by error detection, and
>>> can range from fine-grained automatic correction to coarse-grained manual
>>> correction.
>>>
>>> In the context of older microcomputers, packet-level protocol retry or even
>>> file-level manual retry was pretty standard. ;-)
>>>
>>> For example, NadaNet uses packet-level error detection to trigger
>>> protocol-level retry.
>>>
>>> When no real-time interaction is available, as with recorded data, forward
>>> error correction is required, requiring encoding redundancy sufficient to
>>> achieve the desired overall reliability in the presence of the expected
>>> error rate.
>>
>> I might throw in the towell. If I'm not too pooped tonight I'll take
>> another stab. But, I'm going to make sure all my cables don't move
>> around when I'm capturing from the tape.
>> I'm also going to put a 200Hz tone at the beginning so I don't get that
>> volume increase. I think there's somerthing weird going there. Its as
>> if the receiver is trying to compensate.
>
> Good idea. Most battery-powered cassette decks incorporate “auto-level”
> recording, which can mess up what we’re intended to be fixed recording
> levels.
>
> You may want to reconsider the use of modem signal encoding. Woz’s cassette
> encoding is quite efficient and reliable, and uses pulse-duration
> modulation.
>
> The data is recovered by measuring the time between zero crossings, making
> it relatively insensitive to signal amplitude, and with a 2:1 ratio between
> “0” and “1” encoding, it’s pretty tolerant of speed variations. And with
> an effective bit rate of about 1333 bps, it’s reasonably fast.

Yes, but is there a MacOS implementation?

I like the modem version bnecause it's a standard. I have the whole
process perfect, I just need to refine it.
Last night I discovered I was using a damaged RCA to 2.5mm cable. If i
so much as nudged the table everything was sitting on there was
distortion. All this time and it was something simple. Once I
discovered that I went to bed. The replacement cable works perfectly.
Re: Data on Cassette? [message #389048 is a reply to message #389032] Wed, 04 December 2019 09:37 Go to previous messageGo to next message
Anonymous
Karma:
Originally posted by: Prof. Justin

On 2019-12-03 00:04:20 +0000, Michael J. Mahon said:

>>
>
> Good idea. Most battery-powered cassette decks incorporate “auto-level”
> recording, which can mess up what we’re intended to be fixed recording
> levels.
>
> You may want to reconsider the use of modem signal encoding. Woz’s cassette
> encoding is quite efficient and reliable, and uses pulse-duration
> modulation.
>
> The data is recovered by measuring the time between zero crossings, making
> it relatively insensitive to signal amplitude, and with a 2:1 ratio between
> “0” and “1” encoding, it’s pretty tolerant of speed variations. And with
> an effective bit rate of about 1333 bps, it’s reasonably fast.


Hold on, I made a breakthrough. I think I'm thinking too musical.

Amplitude. Capturing from the tape isn't "hot" enough. The first time
I tried it - I got a whole lotta shit. Then using Audacity's amplify
effect - it worked perfectly with a 26k JPG file. Then I went to bed.
That's why my results are so inconsistent. I have four different
cassette players, each one with a volume control that gets knocked
around in my backpack. I need to crank up the incoming signal to the
computer. I'm too paranoid about distortion - but I'm not trying to
capture music. The shitty cable that I threw out previously was also a
problem, but by eliminating one problem at a time I might actually get
somewhere. This is kinda fun actually.
2400 baud might actually be possible.

Here's my temporary setup - that's one of the shoebox cassette players
I'm using. I have two others with analog AUX & MIC inputs. The arrow
is the USB-C capture device.

https://imgur.com/M1w9kRO

Here's my process:
use minimodem to create the initial WAV/FLAC file.
Audacity to add 6 secs of 500Hs tone at the beginning
Record via AUX onto cassette.
Record cassette out onto another WAV/FLAC file.
Use minimodem to receive or decode the data from the WAV/FLAC file.

Here's both files - before and after Audacity's amplification.
https://imgur.com/WE9MVQJ

Original file captured from cassette:
https://filebin.net/wchwa5vzjp7x47rr

Original after amplification effect:
https://filebin.net/5vfmbqwm23gr29ih

and the original original made with minimodem:
https://filebin.net/72clke4jf9gvrbur
interesting how this version compresses so well - it doesn't have the
inherent noise from the analog source.
Re: Data on Cassette? [message #389238 is a reply to message #389009] Thu, 12 December 2019 01:17 Go to previous message
Anonymous
Karma:
Originally posted by: Prof. Justin

On 2019-11-29 23:00:32 +0000, Michael J. Mahon said:Any transmission
medium is susceptible to errors. Therefore error detection
> is always a good idea. Error correction is enabled by error detection, and
> can range from fine-grained automatic correction to coarse-grained manual
> correction.
>
> In the context of older microcomputers, packet-level protocol retry or even
> file-level manual retry was pretty standard. ;-)
>
> For example, NadaNet uses packet-level error detection to trigger
> protocol-level retry.
>
> When no real-time interaction is available, as with recorded data, forward
> error correction is required, requiring encoding redundancy sufficient to
> achieve the desired overall reliability in the presence of the expected
> error rate.

I got it working at 2400 baud. I'm going to try 4800.
When capturing from the tape to WAV/FLAC I needed to adjust the volume
or level.
I recorded a 212k jpg at 1200 baud in 14:50

% md5 cap.jpg
MD5 (cap.jpg) = aeb62e3e85ad4e6be4ff882790c9a504

% md5 IMG_0897.JPG
MD5 (IMG_0897.JPG) = aeb62e3e85ad4e6be4ff882790c9a504
  Switch to threaded view of this topic Create a new topic Submit Reply
Previous Topic: The Prisoner
Next Topic: WOZ images
Goto Forum:
  

-=] Back to Top [=-
[ Syndicate this forum (XML) ] [ RSS ] [ PDF ]

Current Time: Thu Mar 28 13:17:37 EDT 2024

Total time taken to generate the page: 0.03943 seconds