Recreated disk does not match source

[KFX99]

Hi,

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

Well, here comes the problem. Almost all original disks carry some kind of copy protection. If there was no copy protection, we could preserve stuff just by creating disk images or refreshed originals using a simple sector copier. As far as I understand Kryoflux is used to preserve stuff that is difficult to being preserved by normal means.

But what is preservation good for if things cannot be retrieved? That's like creating uncrecoverable backups.

Okay, thanks for the information, that DTC cannot write back raw stream files from non-index-aligned disks. Though I do not understand why that is so. I guess there will be some note in the stream file where the index pulse occured and what is so difficult about writing the following bits until the next pulse back to disk.

People were able to create highly advanced protetion schemes even with a Floppy Disk Controller Chip being involved. There were upgrades to drives which were capable to bypass the FDC to read and write plain bits from or to the tracks. This sounds a bit like how Kryoflux works. And Kryoflux has the advantage of some 30 years of evolution in computer technique...

If we create disk images from the stream files and write those back creating index aligned disk that disk has nothing to do with the original, has it? That is a black and white photocopy of a Picasso painting.

[KFX99]

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

Hi,

though I already know by know that the propable cause of the problem is that DTC cannot write back stream files created from non-index-aligned disks I will attach the two stream files, a.raw being the stream from the original disk and b.raw being the stream read from the copy. It is track 1 [0,39].

As far as I can see the track(s) in question do not contain any copy protection. I performed a binary compare between the sector data from the original disk against a created image and there were no errors.

CU

[ZrX]

There's a difference between preservation and duplication. The priority is on preservation, getting the bits stored before it's too late.

Regarding protection vs sector images, protections tend to rely on data that plain sector images most often can not store. For example, setting a sector number something unusual. That kind of information doesn't transfer with plain sector images.

[KFX99]

There's a difference between preservation and duplication.......

I am sorry, but I guess a full reply would be off topic.Be sure that I do not want to duplicate stuff in a row. But what I want is to recreate my original when it is dead one day. I know that things are intricate,

[SomeGuy]

Yep, not aligned. See the screen shots below. Looks a little odd because it is just one track. Note the "---" line, that points the the index. The first one shows the stream file as it was read. The second is the result of writing it to a real disk and reading it back. Note the orange bad sector that crosses the index.

There are a couple of ways to straiten this out with third party tools, but those are rather tricky.

There's a difference between preservation and duplication. The priority is on preservation, getting the bits stored before it's too late.

I disagree with that. Often duplication is required in order to verify that preservation was successful. There have been a good number of times where duplication/verification has shown I made some mistake, had to do something extra, or there there was some otherwise unseen problem.

[ZrX]

There's a difference between preservation and duplication. The priority is on preservation, getting the bits stored before it's too late.

I disagree with that. Often duplication is required in order to verify that preservation was successful. There have been a good number of times where duplication/verification has shown I made some mistake, had to do something extra, or there there was some otherwise unseen problem.

That could be in case DTC was not able to analyse the format of some special type disk. And in such case, the only way to test it would be to write it back and rely on the reports from the original system, however it decides, if what it read was ok.

In this case the output of the original track "02.0 : FM: OK*, trk: 001, sec: 18, *H +14" indicates it's likely a self-written disk, 14 out of 18 sectors are modified, but other than that the track is good.