Kryoflux vs SuperCardPro?

[Loedown]

Appreciate your whole CV and life story, no really.

I am sure this whole thing could have been sorted out off board. Two companies, two ideals and there's not a chance in hell that either of you will agree.

[IFW]

Let me just give my unbiased insight into this which is NOT related to either KF or SCP directly.

These are niche products, selling extremely low volumes compared to any other goods you are likely to buy, so future developments may or may not happen.
If you want a niche product buy it for what it is, not what it promises to be.
If it does not do what you want let the authors know about your needs, or re-evaluate them - maybe you can use some other, existing feature instead.

[JimDrew]

Originally Posted by Loedown

Appreciate your whole CV and life story, no really.

I am sure this whole thing could have been sorted out off board. Two companies, two ideals and there's not a chance in hell that either of you will agree.

That's not quite true. The KF team are no dummies. They do have a long history of copying things, but they are not exactly approachable and are very protective of the preservation mission. This really ticked off a lot of people, which prompted me to look at making software for the KF board to make immediate copies, and the rest is history. So, I do agree with some of the KF teams assessments and ideas. If it's right, it's right - and it would be foolish to argue about it just for the sake of arguing.

It's a niche market, but if sales continue as they are there will be thousands of SCP boards out there by the end of the year.

[fryguy]

Originally Posted by JimDrew

That's not quite true. The KF team are no dummies. They do have a long history of copying things, but they are not exactly approachable and are very protective of the preservation mission. This really ticked off a lot of people, which prompted me to look at making software for the KF board to make immediate copies, and the rest is history. So, I do agree with some of the KF teams assessments and ideas. If it's right, it's right - and it would be foolish to argue about it just for the sake of arguing.

It's a niche market, but if sales continue as they are there will be thousands of SCP boards out there by the end of the year.

Does WinUAE support .scpimages ?

[Loedown]

Originally Posted by JimDrew

That's not quite true. The KF team are no dummies. They do have a long history of copying things, but they are not exactly approachable and are very protective of the preservation mission. This really ticked off a lot of people, which prompted me to look at making software for the KF board to make immediate copies, and the rest is history. So, I do agree with some of the KF teams assessments and ideas. If it's right, it's right - and it would be foolish to argue about it just for the sake of arguing.

It's a niche market, but if sales continue as they are there will be thousands of SCP boards out there by the end of the year.

I found that the Kryoflux team are very approachable but I also know that people are people, there's ways and means of dealing with everyone. As I work in the field of electronics my biggest gripe is that standards aren't adhered to and that causes many issues because I am constantly adapting to new and sometimes counterproductive standards. What the community needs is a proper standard whether it be IPF or SCP or even a combination of both. These products are niche products and their volumes will be low but no one will win if there's a constant sniping between the parties.

Each product should have the ability to do a bit by bit comparison with editing and also an exact timing for some of the weirder Amiga copy protection structures. Clear and concise documentation and ongoing support. Time isn't on anyone's side here, the disks are slowly faltering day by day and as someone who needs a good disk duplicator for saving my patch data, it's more important to me as an end user that I know my data will be preserved for as long as I need it in a format that I can continue to use.

[JimDrew]

Originally Posted by fryguy

Does WinUAE support .scpimages ?

No, and it appears that nobody associated with that project cares to support flux level images. I asked about this support a few months ago. Flux level is the only way to have 100% guaranteed compatibility for floppies.

SuperCard Pro software has utilities for editing down to the flux level. Using programs like Aufit and HxC's floppy drive emulator software you can verify .scp images. I have some recovery utilities that will be added to the software that will verify images and disks as well.

With flux level copying, there is no such thing as "protection". Everything, regardless of disk format can be duplicated.

[mr.vince]

Which is why TRACE - the biggest duplicator back in the day - did NOT (exceptions apply) do this. They asked customers to supply scripts in FreeForm. Here formats and protections were defined. The system exactly knew what was duped.

As you are unable to verify pure flux, most games had checksum data added.

It is correct that it's easy for a quick dupe, but you can't verify (unless you'd have parameters, but then that's not far from FreeForm), and copies in general come with generation loss. Since floppies are old and errors happen more frequently people should be aware of the issue.

Speaking of another format, I don't know of anything that could not be handled by ExtADF, IPF and maybe FDI. All of these are supported by WinUAE. The latter also has raw flux afaik.

But, why not surprise us and contribute to the WinUAE code base? Like we did with Vice when we pimped G64 support...

[demolition]

Originally Posted by JimDrew

No, and it appears that nobody associated with that project cares to support flux level images. I asked about this support a few months ago. Flux level is the only way to have 100% guaranteed compatibility for floppies.
With flux level copying, there is no such thing as "protection". Everything, regardless of disk format can be duplicated.

Isn't it like analog copies of tapes for example where the copy gets degraded for every iteration? I mean, the exact timing will be a little different for each drive and will change a bit between each read and write. Thus, if you make a copy of a copy and so on, you will eventually end up with a non-working copy, even if the media is fault-less and the drive as good as they come? If this happens, then how can you verify with 100% certainty that the copy is functionally identical to the source?

[mr.vince]

Exactly. I gets worse if you don't do pre-compensation while writing.

[JimDrew]

No, that is a myth. Copies are digital, not analog. Part of the writing routine is to correct for any changes that occur with the target drive so that copies of copies can be made.

I was involved with duplication long before Mountain Computers (and it's duplication system patents) was sold to Trace, Inc. "Customers" did not supply scripts. These were created by the duplication houses as part of their service. I had hundreds of thousands of disks produced on these machines. I also sold protection schemes to some companies that had to be duplicated on these machines, so I worked with a couple of duplication houses to be able to create the proper scripts to do that.

[demolition]

These scripts you're talking about, could they be automatically generated for all master disks or did it involve some manual work? If the last is true, then that sounds like IPF generation where you not just copy blindly, but try to describe the format on a higher level to be able to verify it properly.

Isn't flux level disk copying similar to creating .TAP files from C64 tapes? Here you also look at zero-crossings in the source signal and create timing codes from them. If you rip the same tape in two different tape decks (or the same for that matter), the output will not be 100% identical, although they might both load just fine. Then there's tools like TapClean which can clean it up and in many cases make two rips be identical, but this requires knowledge of the loader being used. It will not be possible to clean it up completely if you're blind.

Unless there's an inherent hardware quantization in the timing of flux transitions (is it being latched with a clock in the floppy drive?), then it should be considered as an analog signal.

[mr.vince]

Originally Posted by JimDrew

"Customers" did not supply scripts. These were created by the duplication houses as part of their service. I had hundreds of thousands of disks produced on these machines. I also sold protection schemes to some companies that had to be duplicated on these machines, so I worked with a couple of duplication houses to be able to create the proper scripts to do that.

Great - so we agree! Scripts had to be made. There was no blind copying; Trace was against flux level copying - as this could not be verified. Let's ask Rob Northen for advice:

Interview conducted by Codetapper: http://www.codetapper.com/amiga/interviews/rob-northen/

Trace would supply format files to read-in standard formatted disks, but if the format was non-standard, as in a protected disk then the duplicator would have to write a format file of their own to read-in the floppy. I always supplied the format files for Copylock protected disks. This made the duplicators job a lot easier. Format files could be supplied in object form (uneditable) or source (editable).

Before Rob could create his own key disks, he'd send scripts to Trace and get key disks in return. The computers he used were unable to create the protections he used, so he could not supply master disks otherwise.

Flux level copying is a gamble. You never know if the data is valid, you can not verify.

Originally Posted by demolition

These scripts you're talking about, could they be automatically generated for all master disks or did it involve some manual work? If the last is true, then that sounds like IPF generation where you not just copy blindly, but try to describe the format on a higher level to be able to verify it properly.

Exactly. We can/will deliver a set of standard scripts, e.g. for Rob Northen's Copylock, and several others. These can then be used as the basis for new scripts, which can be created by users. We intend to set up a repository, so people can search and exchange scripts.

Scripts will generate results and let you know if the raw data present matches a format. And you will be able to transform the data, e.g. for MFM disks created on a PC. The PC only writes sectors, whereas the Amiga writes tracks. This means disks created on a PC have a write splice for every sector. Many Japanese games were duped this way. So to create an archival master, that can be verified against other disks of the same game, such bogus data needs to be removed. A transformation script would remove these mini splices and create a master track.

We can already do much of the above with the IPFs we do. Because the Analyser knows the formats it encodes, we can compare the data _within_ the format, thus ignoring e.g. weak bits and other rubbish in a write splice, which is never the same for two copies.

Originally Posted by demolition

Isn't flux level disk copying similar to creating .TAP files from C64 tapes? Here you also look at zero-crossings in the source signal and create timing codes from them. If you rip the same tape in two different tape decks (or the same for that matter), the output will not be 100% identical, although they might both load just fine. Then there's tools like TapClean which can clean it up and in many cases make two rips be identical, but this requires knowledge of the loader being used. It will not be possible to clean it up completely if you're blind.

Yes, I'd say this compares very well. May I use your wording for a FAQ?

Originally Posted by demolition

Unless there's an inherent hardware quantization in the timing of flux transitions (is it being latched with a clock in the floppy drive?), then it should be considered as an analog signal.

Yes, the disk itself is analogue. The signal goes through an amplifier and some noise cancelling and will then be converted to pulses by the drive's electronics. These pulses are then sent via the flat ribbon cable to the floppy drive controller. The signal is low active, so the drive pulls down the data line from +5V to 0V for a defined period of time. The information is in the timing, the signal strength does not matter. The trigger itself depends on the analogue readout, so varies slightly from revolution to revolution. This gets even worse due to drive wobble, friction and other fancy stuff. That's why no readout happens at exactly 300rpm. It's 299.59, or 300.61, or 301.02. The PLL (https://en.wikipedia.org/wiki/PLL) in the floppy drive controller must take care of this...

[demolition]

Originally Posted by mr.vince

May I use your wording for a FAQ?

Use it however you want, or get a native speaker to rewrite it to more proper English.

[JimDrew]

The two production houses in Portland, Oregon (where Megasoft, Utilities Unlimited, Epyx, Synapse, and other companies' disks were produced) had a generic "copier" script. It would dump a disk blindly and create the master image from that. I was quite surprised at how good this really was. The *only* thing it had to be told were about 1/2 track usage and weak bit usage. Other than that, it could generate a working disk simply by reading a master disk. Once read, the data was just stored for retrieval later. I could call up and order a 1000 disks and then go pick them up the next day.

By the way, the mass duplicator system (competitor to TRACE) that I worked on at Central Point Software could also blindly dump a disk, figure out what disk format it was, and generate a proper master file. This was a very advanced form of the option board and CPS sold a LOT of those systems to smaller software houses because it was very affordable and extremely reliable.

[mr.vince]

So... You said:

Originally Posted by JimDrew

The *only* thing it had to be told were about 1/2 track usage and weak bit usage. Other than that, it could generate a working disk simply by reading a master disk.

Rob Northen said:

Trace would supply format files to read-in standard formatted disks, but if the format was non-standard, as in a protected disk then the duplicator would have to write a format file of their own to read-in the floppy.

And I was like:

Originally Posted by mr.vince

Scripts had to be made. There was no blind copying; Trace was against flux level copying - as this could not be verified.

I am very pleased we manged to get that sorted. We all agree that blind copying (flux duplication) was depreceated and for everything that wasn't known anyway (standard formats natively supported by duplication equipment) scripts had to be created. Even if this was a fully automated process in some scenarios, the format was understood and then written, so dupes could be verified.

[JimDrew]

Sorry, that's simply not the case. I produced more disks than Rob ever did, and I also sold protection schemes to the production houses. Other than weakbits and half track protections, we never had to do anything more than create a master file by reading the disk.

[r.cade]

I really doubt that. Rob's protection was on hundreds (if not over 1000) of different titles for the Amiga, Atari ST, PC, and probably more.

[Vot]

Well i must say I'm throughly enjoying this pissing contest. Whats next boys time to measure your gear? My disc imaging system is bigger than yours.....

[kipper2k]

my question is can the SPC take an existing ipf and convert ot to write on its own hardware (or in the future have this capability)

[AMike]

From the collectors point of view the KF is the ideal solution. I own more than 1.400 Amiga games and with the IPF's which are easy to find I can preserve more than 99% of my games. The important part is that I can repair the games with a raw and unmodified copy and not with an unverified and perhaps bad user copy. Softpres has made a big effort to the community to verify every single game. At the end of the day IPF & KF is a hard/software combination which I can trust blindly - the most important part for a collector/gamer. Nothing is more horrible when a guru comes in the last level of a game.

It seems that SC can do an similar job but I never know which copy I'll hold in my hand and I think that's the disadvantage of this solution. The "offered backup service" is IMHO also an evidence for that. For preservation you need not only a good hardware - you need also a good and working game database. The offer sounds more like a try to build a database on the cost of the community (you have to pay shipping) than a serious backup service.