Prev: Possible off-the-shelf C128 RGB to DVI converter?
Next: UDPSlave 0.91
From: Wolfgang Moser on 27 Oct 2006 03:32
Hello Pete,

Pete Rittwage schrieb:
> Wolfgang Moser wrote:
>> Please decide carefully, if IHS nibbling really
>> does make sense in a technical point of view.
>> [...]
>
> It's only useful in a few specific cases, to be sure. Mostly in the
> remastering of disks, which is of little interest for emulation

ah yes, for creating masters an IHS supported write
process would be superior to a technique based on
timer driven measurments.

But here I need to ask the question:

* Do we want this?

Is there really a need for anyone to truly
remaster old disks. I am the last one who wants
to get flooded with such "Originals" through eBay.

So, may I politely ask you to not write such a
"perfect" remastering tool? Having a tool for
creating backups that do run without the need for
breaking the copy protection is absolutely ok (at
least for me, maybe not for some lawyers).
But creating disks that do not contain _any_ hints
that they are no true originals (marks from typical
behaviour of professional duplicators) would make
it a lot harder to identify imitations.
Ok, there are some magnetic effects on aging so
you may find out, how long before a disk was
written, but I'm totally unaware of tools you could
measure that with.

> purposes. Copying disks is still possible using the old software and
> wasn't really a goal of the project. Your software solution for
> detecting the skew works fine for 90% of cases where we have a true
> sector 0.

And I made already some progress on SYNCless tracks.
I wrote another (batch postprocessing) tool that
currently searches for NIB images that contain any
non-empty SYNCless tracks. If found it further
analyses such tracks and tries to identify _any_
regular pattern that can be used as some alternative
synchronisation mark along with soft techniques to
bit align the data stream.
I'm not finished with it, but as far as I can tell:
From the NIB files of my own Originals I could not
find any SYNCless track that does not contain any
such regular pattern. Mostly these patterns consist
of a 2-bit scheme (aa,aa... or 55,55...), but I also
found 16-bit schemes (like: cc,ad,cc,ad,...) as well
as 8-bit and 4-bit schemes. Although I feel
confident that 3-bit schemes are definetly able to
synchronize on with maybe 30 bytes of code in a
15x1, I could not find any such "odd" pattern (my
detection algorithm will find it, if there is one).

So in the end I'm convinced that with a SYNCless
track processing algorithm, the timer method for
analyzing "sector skew" (to not say track
synchronization), could be still applied. It's just
some other hundreds hours of programming, to better
say 10 hours of programming and 90 for testing.


Womo
First  |  Prev  | 
Pages: 1 2 3 4 5
Prev: Possible off-the-shelf C128 RGB to DVI converter?
Next: UDPSlave 0.91