Jump to content
  • entries
    28
  • comments
    28
  • views
    21,057

Restoring program cassettes: CS1er vs. Classic99


OLD CS1

557 views

drawer_ti99.png.cf44a1658c0d2912812cd32d59b32e0c.pngI got hold of a neat little GGI Gear CT2DG tape-to-MP3 recorder, purchased from a fellow AtariAger, to see how it might replace my setup of a real tape deck and USB audio capture device.  The name is a misnomer as it shows up to Windows as a generic USB audio device, which means you can use your favorite audio capture software and are not relegated to a compressed capture.

 

I used my master tape of Laser Strike for TI BASIC as the test subject*, Audacity v2.3.2 to capture the input, and CS1er v0.96b to convert and @Tursi's Classic99 v399.050 to import the captured audio.

 

The volume control on the CT2DG controls the on-board monitor (headphone jack,) as well as the volume of the captured audio.  I turned this up to maximum without any perceptible distortion, though you can see the clipping of the start of the sync header.  Audacity's recording level was set to 3 -- this is important as a higher setting would have caused much greater clipping at the sync.  Audacity faithfully captured the audio, including leader noise and the initial volume spike of the sync stream.

 

audacity_laserstrike_capture.png.caeb47821bc66cebfb438eca417f20cb.png

Leader noise, sync with volume spike, and start of data as captured.

 

audacity_laserstrike_capture_detail.png.e1311fac21403c2584ed258a76498d82.png

Tail of sync and start of data at 14.19 to 14.23 seconds. A nice clean and consistent capture.

 

Once captured, I used the leader noise in the first ten seconds or so of the recording to train the noise reduction filter, then ran that against the entire capture.  Then the limiter was applied to the volume spike at the beginning of the sync.  I then amplified the capture by -2dB, raising the peak to around .85 on the scale.  The capture was exported to a 16-bit WAV.

 

CS1er requires a mono 8-bit WAV for input, so I converted with this command:

ffmpeg -i laserstrike.wav -c:a pcm_u8 -ac 1 -y laserstrike_mono8bit.wav

Running the resulting file in CS1er resulted in a long string of errors and rejected records.  I went back and tried the raw capture as well as the capture with noise reduction but no volume manipulation, to no avail.  Classic99 refused to pull any data from the 16-bit stereo exports.

 

Although the Classic99 manual only states the requirement of a 16kHz or higher WAV file, with no apparent restrictions on sample width or channels, I finally focused on the 8-bit samples to see what Classic99 would make of them.  Contrary to before when Classic99 would not read the 16-bit stereo WAVs, it processed the 8-bit mono WAVs perfectly.  This included the initial raw capture with no manipulations.

 

For this exercise, Classic99 wins the day.  In the past I could have spent immeasurable time with CS1er, or even Tape994A, to try get a good read.  I am happy to have another tool in my belt, weapon in my arsenal, arrow in my quiver, to help with future conversions.  As well, the GGI Gear CT2DG has proven itself to be a compact contender to the space-consuming tape deck setup.  While this restoration was on a much cleaner source than many others I have taken on, the process bodes well as a first-approach option.

 

* Recorded on a genuine TI Program Recorder from an authentic TI-99/4A console onto a Maxell CP15 "Personal Computer Cassette."

 

The primary tested WAV files, manipulated and raw, are attached below.  The Audacity project is too large to include.

Laserstrike CS1 Restore Test.zip

8 Comments


Recommended Comments

Huh... surprised by this. CS1er is supposed to do signal analysis (or was that only Tape994A?)

 

Classic99 resamples whatever you feed it down to 16khz, 8-bit. It is supposed to be able to do that with 16khz - 48khz, mono or stereo, and data in any of 8 bit unsigned, 8 bit signed, 16 bit signed, 32 bit float signed, or 64 bit float signed (because I actually /found/ downloads of TI tapes in this format). It deletes the negative side of the waveform then applies a crude auto-gain to get the levels about where I expected them. The CRU code is only concerned with the zero crossings, so deleting the negative side probably helps there.

 

Stereo didn't get much testing since I didn't have any stereo samples... the path I chose to take is strange. It looks like I was assuming one channel would be dominant, and only take the left or right channel, depending on which is louder.

 

The resampling is also very crude - just nearest neighbor, so it's possible that introduced too much noise to the higher frequency waves.

 

Good data anyway! Something I'll think about next time I'm in there.

 

 

  • Thanks 1
Link to comment

Sorry if this is self explanatory, but I've searched the forum on how to do this and didn't see anything.

 

Does cl99 support cs1 or cs2, reading an audio file or Saving one?

I looked under options and didn't find anything regarding enabling, and I didn't see anything like I do with setting disks. Meaning, setting a WAV file to cs1 or cs2 or something similar.

Can someone enlighten me on this simple thing. Thank you in advance

Edited by GDMike
Link to comment
3 hours ago, GDMike said:

Sorry if this is self explanatory, but I've searched the forum on how to do this and didn't see anything.

 

Does cl99 support cs1 or cs2, reading an audio file or Saving one?

I looked under options and didn't find anything regarding enabling, and I didn't see anything like I do with setting disks. Meaning, setting a WAV file to cs1 or cs2 or something similar.

Can someone enlighten me on this simple thing. Thank you in advance

It is in the Classic99 documentation.  The CS1 settings are under the Disk menu, and only reading from CS1 is supported.

  • Like 1
Link to comment

Thx. I guess I got a bad dl..no help docs when I went to the first thing that came to mind..I'll redownload.. but yeah, too bad it doesn't do a full cassette run. It's ok. I was just tinkering anyway..thx

Link to comment

As an FYI CS1er had a rare and possibly last ever update in November 2021, now v0.97b. Might be worth checking the new detection engine. I'd be interested to see how it goes. 

www.cs1er.com

  • Thanks 1
Link to comment

Just tested with the files supplied by @OLD CS1 here and the new version of CS1er (0.97b) read the file with no errors using default settings. It just worked on first try with no need to debug at all. Thanks for supplying the files to test.

Link to comment
9 hours ago, pokeystuff said:

Just tested with the files supplied by @OLD CS1 here and the new version of CS1er (0.97b) read the file with no errors using default settings. It just worked on first try with no need to debug at all. Thanks for supplying the files to test.

Do me a favor and try these files.  I was unable to get usable data from these files using the default settings.

 

Sampling of original tape:Hickory, Dickory, Dock.wav

CS1er output of good file: Hickory, Dickory, Dock(digitized).wav

 

I then took the same original tape same file, applied noise reduction based upon the noise on tape between the leader and the sync marker.  It looks like it missed a few records as it read 152 out of 156 records, and every record shows a bad checksum. Hickory, Dickory, Dock(noise reduced).wav

 

A few years ago I was able to get a good import of this particular tape, but damn if I cannot recall what all I did to get it.

Link to comment

I was able to get it read by doing some adjustments to the Tuning Settings and I also did an EQ in Audacity of your original file (Hickory, Dickory, Dock.wav).

I typically filter using the following EQ first.

image.thumb.png.f4786ecbd5c5b590d285e0fba9008ea7.png

 

Then after some viewing the monitor in CS1er to see where the bits were being recognised reliably. Adjusting the Forward and Time Threshold settings to match the frequency of your file better. Also since there wasn't a lot of dynamic range.. reduced the tolerance.

image.png.b6ee23d36caf67ae12753a65fbbe0f1a.png

This was still causing a lot of errors, I noticed that this was because the wave was unbalanced (again observing CS1er Monitor, red lines occasionally splitting a bit in half). Making it impossible to get the Time Threshold perfect, since there will always be enough bits that are irregular compared to the other swing of the sound wave. Put another way, each side of the sound wave (each sweep) was different, so a 1 may look like a 0 on the other side of the wave. Luckily CS1er has the DC Offset function to move the mid position of the recognition, effectively removing some frequency from one side to the other. Lowering this was reducing the error rate and at -17 it finally could read the entire file with no need for debugging - which can be a rabbit hole and only really for quite corrupt files.

 

Find attached a FIAD, Text and WAV (square wave) version of the output from CS1er. 

 

Hickory.zip

Edited by pokeystuff
  • Like 1
Link to comment
Guest
Add a comment...

×   Pasted as rich text.   Paste as plain text instead

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.

Loading...
  • Recently Browsing   0 members

    • No registered users viewing this page.
×
×
  • Create New...