JimDrew wrote:Like I said before, reproducing the exact same number of bitcells is certainly possible and that is what SuperCard Pro always attempts to do.
So we are back to the main issue. If it's possible and reliable to reproduce exactly the same flux transition pattern, even at the write splice, which depends a lot on the drive speed stability. We'll know better when (and if) you'll implement the verify and retry logic at the software.
So I think this discussion is fascinating, really, but I think it would be extremely helpful if we just had someone who could _test_ the theory that it is indeed possible to write back ... ?
To test that in practice we need software that would implement the mentioned "verify and retry" mode. Otherwise it doesn't have much chances.
For all those that might not understand the concept of this mode/logic. Normally you don't reproduce the exact number of transitions (or bits, or bitcells or even bytes). The main reason is the difference between the rotation speed of the source and the target drive. It is not very difficult to measure the target drive speed and to adjust the widths of the transition pulses accordingly. But the drive speed is not perfectly constant. It changes slightly in every revolution. You measure one specific revolution, or perform an average in the best case. But when you go to actually write the track the speed probably won't be exactly the same.
The end result is that usually, the number of transitions won't be exactly identical to the source. For most cases it doesn't matter. The protection check doesn't expect a perfect precision. It doesn't because some variations were also present when the disks were originally duplicated. If you check the track length in multiple copies of the same original release, you will see quite some significant variations. A protection check verifying, say, a so called long track will accept a range. It doesn't expect an exact number of bytes (let alone bits or transitions).
But this case is very different. Each copy has an unique key and the protection check is then much stricter. You need much more precision. So the idea of that verify logic is as following. After writing the track, the software reads the track again and check if the number of transitions is correct or not. If it isn't, try to adjust the width and retry writing the track once again ...
To actually be able to write back the track and pass the protection you depend on two things. One is the stability of the target drive speed. If it is very unstable to mention extreme cases, as it would be with most belt driven drives, it would be very difficult. You might need to retry too many times. The other one is if, and how much, the protection check has some tolerance.
It seem it has some tolerance in this specific case. It doesn't require the transition pattern to be 100% exact. This is probably because otherwise it might be a bit risky. The write splice magnetization is not clean. It might be diffuse and noisy. Then the exact read back behavior might depend on the end user's drive. I don't know for sure how much tolerance this program allows and in which way.
Note that other cases are less tolerant. I understand that some PC games with this protection use the checksum directly as a decryption key. This would require an exact match.