Recreated disk does not match source

All questions about how to use KryoFlux go here.
KFX99
Posts: 14
Joined: Sun Jul 23, 2017 7:52 am

Recreated disk does not match source

Post by KFX99 »

Hi,

I created RAW images from a 40 Track DD disk containing FM 125 KBit/s tracks, 18 sectors by 128 bytes, original drive RPM 288.

The drive used to create the image is DD 40 tracks 300 RPM.

When I write back the stream files to disk on the 300 RPM drive, the last sector of half of the track results in CRC error.

Using the -w parameter does not seem to have any influence.

What may I be doing wrong?

Command used to create the image:

DTC -p -e39 -g0 -fD:\myimage_ -i0

Command used to write back the image to disk:

DTC.exe -f"D:\myimage_00.0.raw" -e41 -d0 -dd1 -we2 -w

Regards

dlfrsilver
Posts: 119
Joined: Fri Nov 12, 2010 8:08 pm

Re: Recreated disk does not match source

Post by dlfrsilver »

The problem comes from the drive speed. The original disk was written with a 288 RPM drive. Your drive is 300 RPM. The speed doesn't match.

The kryoflux system doesn't control the motor speed of the floppy drive, basically, with a 300 RPM drive to write a disk normally written with a 288 RPM drive, you get a sector chopped up, hence the CRC error.

KFX99
Posts: 14
Joined: Sun Jul 23, 2017 7:52 am

Recreated disk does not match source

Post by KFX99 »

Hi, I partly agree to what you say. But if I put a 288 RPM disk in a 300 RPM drive and read it, the bits come out slightly faster and with a slightly smaller bit width. This is what the raw stream files should contain, as far as I understand. Now if I write the stream files back to disk using the very same 300 RPM drive and DTC writes the bits as they were previously read (slightly higher frequency and slightly narrower, why wouldn't they fit?

Maybe DTC changes bit width to the next matching standard? For example, if the orginal bit width was 8us, they would come out of the 300 RPM drive with 7,7 us. If they were blown up to 8 us before writing, the track would need more space, so the last stuff would not fit on disk again. It would either overwrite the original start of the track (but then, the last sector would be okay) or the index pulse stops the writing to disk.

Another idea: if writing the track starts with the falling edge of the index pulse and stops with the rising edge, then there would be a small area where data is not written.

IF the index pulse width is maybe 200 us (I did not yet measure it) this makes 40 bytes ...

What do you think?

SomeGuy
Posts: 271
Joined: Wed Feb 18, 2015 8:18 pm

Re: Recreated disk does not match source

Post by SomeGuy »

What system are these disks from?

User avatar
IFW
Posts: 3079
Joined: Mon Nov 08, 2010 2:42 pm

Re: Recreated disk does not match source

Post by IFW »

That is strange.
As far as the KF hardware is concerned, a disk written at 300RPM or 288RPM makes no difference - the flux reversal width read will change for the same bitcell proportionally to the RPM difference.
e.g. as an easy example a 4us bitcell read at 300RPM would be 2us at 600RPM or 8us at 150RPM - but it's still the exact same bitcell.
The KF software has many pipeline stages that make sure that data read from a track at any speed can be written back at any speed. During writing the host constantly measures the RPM and modulates the bitcells to match their original size read as close as possible given the RPM measured.
If the drive speed varies wildly, that can be a problem indeed, but if it's reasonably consistent, or predictably changing it should work.
All bitcells present in a stream read will be written back to the disk - so data shouldn't be missing.
Some drives have pretty bad index signal jitter - if the actual track data is fairly close to the index signal that can cause problems. It's not a problem during reading (other than incorrect index signal location), but stream writing is currently index synced, therefore a few bitcells very close to the index signal can get split during writing. This is not an issue since that data is not legit, however, if the index signal position was incorrect that means at least 1 legit bitcell will be split. Note, that this is not a problem during reading, as the host continuously samples the same track without interruption (ie, not from index-to-index) for several revolutions, so no matter where the real write splice is on the track all bitcells will be present in the stream as is.

Could you please post the original track data read, written and re-read as stream files?

User avatar
IFW
Posts: 3079
Joined: Mon Nov 08, 2010 2:42 pm

Re: Recreated disk does not match source

Post by IFW »

Note, this also means that if the stream data is actually not index synced, writing it back is not possible (reliably) since you will have at least 1 flux reversal damaged at the index signal.
Writing back IPF and G64ext files works differently - they do support having a write splice anywhere in the track. This information is simply not available in a stream (so stream write has to resort to using index syncing), it requires very complex analysis which is in fact being worked on.

User avatar
IFW
Posts: 3079
Joined: Mon Nov 08, 2010 2:42 pm

Re: Recreated disk does not match source

Post by IFW »

Another possibility is that the stream does not contain a whole track worth of good samples.
It does not bother DTC while it's decoding a track - it picks up the best parts available even from pretty badly readable track data.
However, writing back such data will simply replicate the bad data.
Again, this is something that the upcoming DTC will be able to deal with - it can actually measure sampling consistency and it will be able to stitch the most consistent flux reversal samples together for writing.
As a side note, keep in mind that consistently read data can be consistently bad data - so while this feature will be able to work out the most likely "correct" flux reversals present on the track, there is no guarantee that it is actually correct (just very likely). Correctness can be checked to some degree by considering that outliers are less likely to be correct and the host software takes that into account when it encounters ambiguous flux reversals - but nothing compares to the correctness of actual data decoding and reconstruction for writing.

User avatar
IFW
Posts: 3079
Joined: Mon Nov 08, 2010 2:42 pm

Re: Recreated disk does not match source

Post by IFW »

Considering the above, you can try and re-read the offending track from the original disk and see if writing it back works with the new stream data.

KFX99
Posts: 14
Joined: Sun Jul 23, 2017 7:52 am

Recreated disk does not match source

Post by KFX99 »

Today I do not have the time to wite an extensive answer. I hope that I will find the necessary time tomorrow morning. Just some quick replies: I guess that the original disk was produced on an Atari 1050 disk drive. The drive used to read and write the stream files has a constant RPM that varies at max by 0.2 RPM.

SomeGuy
Posts: 271
Joined: Wed Feb 18, 2015 8:18 pm

Re: Recreated disk does not match source

Post by SomeGuy »

That is probably your problem right there. Atari disks are notorious as being one of the few FM/MFM formats that are not index aligned. The Kryoflux does not currently support writing non-index aligned images - if you try, you will usually wind up with one bad sector per tracks where a "splice" occurs.

The good news is that if you convert them to Imagedisk or similar format you can re-create index aligned stream files, using some third party tools or even a real PC, and if there is no copy-protection involved then the resulting copies should be readable on an Atari drive.

Post Reply