DrCoolZic wrote:We are obviously not looking at the problem from the same angle. Jim is apparently more interested by duplication of discs than by preservation ... which from a marketing point of view makes sense ...
There is NO difference between duplication and preservation - to me they ARE the same thing.
DrCoolZic wrote:It is obvious that there is no way to detect fuzzy bits without several revolutions because this is the definition of fuzzy bits.
That is simply incorrect. If this were actually true, then none of the .scp images captured with just a single revolution and having weak bit protection schemes would work under the various Amiga emulators, and they most certainly do. You also would not be able to duplicate the protection by writing it back to a real disk (with any disk format), which obviously works just fine. There is a very simple trick, which is actually an interesting byproduct of how flux works. I am REALLY hoping that Jookie will add .scp image format support to his device. If he did, you would say "wow, I can't believe all of these protections work" - and they do, as proven by the .scp image support in the Amiga emulators.. and the Amiga protections are much more critical because there are no WD1772 constraints.
DrCoolZic wrote:There are 4 cases I describe in my doc: Data over index, data after index, ID over index and the tough to detect ID over the index.
And all of these cases are handled by how SCP works.
DrCoolZic wrote:Now back to making sample of disks for preservation I am totally confuse??? I do not understand what is written in the SCP file in splice mode ???? From file description I assumed that data always starts from index. If indeed the data starts from middle of the track then all dumps can go to the trash can as I am not aware of any indication about the position of the start of samples relative to index. But I doubt this is true because all disks I have sampled would be wrong which does not seems to be the case, therefore I do not understand ???
All data does START at the beginning of the track (using the index pulse) with both INDEX and SPLICE modes. With SPLICE mode, the end of a write can appear anywhere in the last revolution - on a write splice. That is, where a flux transition is invalid.
DrCoolZic wrote:Requests for SCP SW:
- is it possible to make sure we can sample several revolutions starting at the index?
It does already.
DrCoolZic wrote:- would it be possible to also pass samples prior to the first index so we can be sure the first transition is sampled correctly?
No. If you want to see what is before the first index, read 2 revolutions and discard all of the first revolution except what you need.
DrCoolZic wrote:- would it be possible to give position of the index relative to the transition located above index?
It has always been this way. Look at SCP's analyzer with a multi-revolution image. You will find the flux value highlighted in yellow where the index mark occurs.
I think the difference here is that you guys are stuck looking at decoded data all of the time. I look at the flux transitions and see/decode it in my head if needed, but generally I only look at the flux. Writing with INDEX mode will stretch/compress the track data to fit the rotational speed of the destination drive. SPLICE mode does not do that. Instead, SPLICE mode writes out the number of revolutions -1, and on the last revolution it writes until there is an invalid flux transition (too short or too long) and attempts to overlay the end of the writing in that location. I need to change the SPLICE mode to also stretch/compress the flux data to match the drive speed for each revolution, and then end the write in the correct location. SPLICE mode is so infrequently used for producing disks that this change has not been a priority. The change only affects writing back data. Reading of data is fine.
We don't care about decoded data when we are dealing with flux data. If you reproduce the track exactly like the original, right down to the last bit cell time then you can not have any better of a preservation - period. In the real world, drive speed variation can make the copy off a bit. You can see exactly how much off by looking at SCP's flux display. You can see the total track time (from index to index) in nanoseconds vs. the total track time of the bit cell times (from index to index) added together. With a good drive you typically see this off by anywhere from a 200ns-1500ns. There is not much we can do about drive speed variations, and these same variations occurred on the original duplication equipment that was used to produce the original disks (so every single disk made was slightly different). Since every read will also be slightly different due to drive speed variation (which is never the same on each revolution) there is no way to do any type of 100% accurate verify routine because of this. The best you can hope for is having the exact same number of bit cells on a track, which is the goal of SCP's disk write routines.