DC.exe "problem"...

[Rink]

Hi there,

Sorry to start yet another topic. I was hoping someone a bit more knowledgeable about the dc.exe tool could help me out with this. I've recently built myself a nice little iPhone <-> Dragon cable and have written an app (in its most basic form right now) to use the phone as a tape drive.

(I was going to blog/post about all of this later)

Loading from tape works great; and so does recording in a way: the recording function isn't fully complete so I've used the voice memos app on the phone to test the cable. I can save data/BASIC to the phone and my Dragon 32 will happily load it back in. BUT dc.exe can't convert it (I get the block checksum errors).

By comparing the waveform in Audacity to wavs I've downloaded , I've noticed it doesn't look quite the same as the others. Some of this is to be expected; by matching the iPhone's expected mic impedance and attenuating the signal (slightly more than should be necessary) to ensure the signal doesn't clip, the recording is certainly "quieter" than the ones in the archive. However, my initial test cable had less attenuation and dc.exe still didn't like the recording.

The other possible source of the issue might be that Voice Memos records a .m4a file and I've had to convert that to Mp3 and *then* to wav (although if I reload that new wav through my tape drive program, the actual Dragon 32 accepts it perfectly).

If anyone wants to take a look at the wav and can maybe work out what dc.exe doesn't like, that'd be amazing.

Cheers guys.

[Alastair]

The other possible source of the issue might be that Voice Memos records a .m4a file and I've had to convert that to Mp3 and *then* to wav (although if I reload that new wav through my tape drive program, the actual Dragon 32 accepts it perfectly).

This is the cause of the problem as MP3s use a lossy compression algorithm (M4A may also use lossy compression). Thus, though it may sound right to the human ear, the data contained within will become corrupted.

[sixxie]

Well if a real Dragon can still load it, that must mean it's at least "good enough".

It's prompted me to find a couple of bugs in XRoar though as I tried to feed the WAV through tape rewriting. However, with padding turned off, and not rewriting, this WAV loads into XRoar too.

Can't speak for DC though.

[Sarah]

I haven't looked at your file, sorry, however Dragon Convert (DC.EXE) usually is more picky than a real Dragon; it uses a pretty simple technique to trace the waveforms in order to determine their wavelengths. It requires 8-bit samples (preferably mono) and can be susceptible to noise; the cleaner the waveform is, the better it should work.

It operates like this (see code below) looking for a rising edge until the waveform reaches a specific height, then a falling edge reaching a corresponding value in the opposite direction and finally confirming that the wave rises again towards the middle of the scale (approaching 0x80).

Code: Select all

void trace_sinewave(void)
{
	wavelength = 0;

	/* Trace rising edge. */
	while (get_char() <= (0x80 + sensitivity))
		wavelength++;

	/* Trace falling edge. */
	while (get_char() >= (0x80 - sensitivity))
		wavelength++;

	/* Trace 2nd rising edge. */
	while (get_char() <= 0x68)
		wavelength++;
}

unsigned char get_bit(void)
{
	trace_sinewave();
	return(wavelength < average);
}

I'm sure there's scope for improving the algorithm used, perhaps to provide more confidence in the shape of the wave being traced, although a more complex technique isn't always going to be more reliable. There's effectively a trade-off between eliminating false-positives and being forgiving during interpretation of the data; at the time, I found by experimentation that the above worked sufficiently well for converting the majority of my software library to CAS files.

[Rink]

Great info there, Sarah, thank you very much. I'll finish my app (making sure it records an 8-bit wav) and take it from there. Eventually I'd like the app to accept and output .cas files so your post is really helpful.

Alastair - yep, I was quite surprised that the Dragon accepted the data recorded by Voice Memos. I don't know whether the memos are held as wavs anconcerteded to aac during an iTunes sync, but in any case, I didn't expect the file I uploaded (which would by that point have been through at least two conversions) to work.

[Alastair]

Rink, I'm stunned that a real Dragon loads a post mp3 sound file, I never thought it would work though I still wouldn't recommend it. As Sarah points out, DC has less tolerance than a real Dragon so it's perhaps no surprise that DC fails in this instance.

[sixxie]

In case it helps, all the Dragon ROM does while loading is to measure the time the signal is above zero and below zero (the only input it has is a comparator fed to a PIA pin). It determines the phase of the signal while it's syncing to leader.

[Rink]

Hahah, yes. I guess my original question should probably have been "why does this work on a Dragon" and not "why doesn't it work with dc.exe"

Hoping to get the proper wav saving done this week so we'll see what happens.

[Rink]

Hello again ,

Rather than start a new forum post, I thought I'd just tack this on here.

I've been AWOL for a while and just picking up this project again. Recording and playing WAVs all got done; as did the ability for the app to record the audio stream and save it as a RAW binary .CAS file.

Which brings me onto my next question - according to the Tape\Disk Preservation page, default format .CAS files are basically the same as the way the Dragons store data on cassette "but with truncated leader and header bytes". Can anyone point me in the direction of some further details there? I want the app to "play" .CAS files but am unsure whether I can just read through them and output the audio tones, or whether the leaders and headers will need to be altered for a Dragon to accept the file.

Cheers.

[robcfg]

If I remember right. there's a small utility called fixcas which fixes header lengths and such.

Try to use it before converting the .cas file to .wav.