Re: [cosmacelf] Re: Cassette to MP3 Converter
- asciiexpress.net is very cool. You can select any of a bunch of apple programs and stream them into the cassette port of your apple from your phone.
On 2013-07-13, at 7:12 PM, "Egan Ford" <datajerk@...> wrote:
> True, MP3 is lossy. But, that may not matter when you are trying to
> record or reproduce two tones that are frequency shift keyed to
> designate encode a sequence of 1s and 0s.
The tones are not relevant, at least that is the case for the Apple
II. All that is measured is the number of cycles between zero
crossings. The default for the Apple II is 1000 Hz for a 0 and 2000
Hz for a 1. It's up to the programmer to count the cycles to
determine 0 or 1 (and there is always a + or - to consider).
> So, my take on it is that while MP3 offers no huge advantage, it
> should be OK for saving and loading data. That said, I have not tried
> it, and it would be an interesting experiment to see how it might work
> or not work.
I've download and used MP3s that work just fine with the Apple II,
OTOH the ones that I have created have been hit or miss (probably some
setting). I speculate that the lossy compression may alter the
waveform and skip some of the zero crossings. Depending on how
tolerant the programmer was with ranges for 0 and 1 may determine if
they work. The 1000 Hz/2000 Hz range is fairly tolerant to issues
with different tape players, volume, tape stretch, etc... so I agree
is might work.
For my asciiexpress.net project I created my own audio code using 6000
Hz/12000 Hz to up the default 1333 bps to 8000 bps (I also threw in
compression to get 2x more on average). On some machines I can push
the native rate to 9600 bps, but it does not work on all machines--I
think have reached the tolerances of the HW design. MP3 for this
higher frequency download code hasn't worked out. Between data
compression and using higher frequency the AIFF/WAV files are smaller
as well further reducing any advantage of MP3 size.
I think another issue I may have encountered with MP3 was the player
and how the player did the D2A. It's been about 2 years since I
explored MP3 as an option, but I recall getting different results with
different players. AIFF/WAV have universally worked. I didn't take
very good notes, I was just trying to get results.
Lastly, I wonder if taking an original tape with all of its analog
glory and doing tape to MP3 may work better. I wonder if that is how
most of the MP3s that have worked for me were created. I create my
own files as "perfect" waveforms using a tool I wrote to convert
binary code to audio. That audio when converted to MP3 was
problematic. Again it could just be my tight 8000-9600 bps
requirements. And again, poor note taking.
- --- In email@example.com, "joshbensadon" <joshbensadon@...> wrote:
> I've already read "Beneath Apple DOS". Very good book on the floppy disk software, but falls a little short in the ordering of the 5/3 nibbilizer.And _Beneath Apple DOS_ is flat-out wrong when they claim that there are clock bits between the bits of the nibble. The whole point of using GCR is that it is self-clocking, so it doesn't need to throw away half the bandwidth on clock bits the way that normal single-density (FM) encoding does. That's why Apple gets 13 or 16 256-byte sectors per track where competing systems using single density only got 10 256-byte sectors.
The 4+4 nibblization of the address mark contents is FM, a degenerate case of GCR.
Normal double-density (MFM) encoding is even more efficient that Apple's GCR, for a given channel bandwidth, but requires more hardware than the Apple design, and more precise discrimination of the time between flux changes. To be any good, MFM requires a phase-locked-loop for recovery. The state machine of the Apple floppy controller includes a crude state machine, but not good enough for reliable MFM.
For many years, hard drives usually used (1,7) or (2,7) RLL, which is a form of GCR that is even more efficient than MFM, but requires an even better data separator. Now most hard drives use even more complex coding than that.