KryoFlux FREE for AmigaOS Classic released

[Abaddon]

Disk-analyses does use a unique identifier in the IPF container to distinguish IPF generated with it from the official releases. Of course anyone could change it and attempt to create fakes.

The following is an excerpt from the IPF container.


/* crc32("User IPF") -- Arbitrary ID for identifying generated IPFs.
* This is stamped into the INFO release, revision, and userid fields.
* ** IMPORTANT **
* Please respect the SPS and do not change these field values. They are of no
* interest to the IPF decoder library, but allow our IPFs to be easily
* distinguished from preserved images from the SPS library. */
#define IPF_ID 0x843265bbu

[Keir]

A cryptographic signature in the IPF format would be cool, or perhaps more straightforwardly sha1sum could be added to the SPS database. There's no intention to make disk-analyse IPFs 'indistinguishable' from SPS ones. They aren't up to that standard (manual checking by an expert), although absolutely much closer to that level of reliability than any unchecked raw dump!

[mr.vince]

Full ack. Maybe you want to add CT raw as input there?

We would like to fingerprint all our own IPFs; older IPFs would get re-signed internally and for those out in the wild (e.g. "spread" by contributors) we would put up a new release of the library and add static signatures there.

[Keir]

Originally Posted by mr.vince

Full ack. Maybe you want to add CT raw as input there?

Is that directed to me? Yes, I would like to add CT raw as input and output from my analyser. It isn't documented yet though, so I'm kinda waiting for the v5.0 sources for the IPF decoder.

Originally Posted by mr.vince

We would like to fingerprint all our own IPFs; older IPFs would get re-signed internally and for those out in the wild (e.g. "spread" by contributors) we would put up a new release of the library and add static signatures there.

How would this signature be used by the library? A flag to request to only open an SPS-signed IPF perhaps, or would that be (nooo!) the unconfigurable default?

That said I would be as happy outputting CT files now the decoder library accepts them. It's not the container file format that determines the image's goodness -- the analyser outputting it is responsible for that. You can have a known good CT file just as surely as you can have a bad (non-SPS of course ) IPF.

[mr.vince]

Just wondering: What would be the use of reading AND writing CT raw? I mean... you can just push CT raw in and get an IPF out... wouldn't that make sense?

[Keir]

Originally Posted by mr.vince

Just wondering: What would be the use of reading AND writing CT raw? I mean... you can just push CT raw in and get an IPF out... wouldn't that make sense?

You can't yet make working IPF of a very few games. Also it depends on whether the decoder library continues to accept unsigned IPFs. Apart from those points yes IPF is the preferable format.

[IFW]

Yes, the library will keep on accepting any kind of IPFs, but the host program will be able to query whether it's something verified or not.
At least that's the plan atm...
Way too many things being worked on right now, so...

[mr.vince]

Originally Posted by kaffer

You can't yet make working IPF of a very few games. Also it depends on whether the decoder library continues to accept unsigned IPFs.

We have no plans to change this... emulation authors may chose to allow warnings/notices when an IPF is not "authentic".

But I still don't get where CT raw in and CT raw out would make sense... I mean you import raw, then you find out it's ok, then you write it back to disk?

[Keir]

Originally Posted by mr.vince

We have no plans to change this... emulation authors may chose to allow warnings/notices when an IPF is not "authentic".

But I still don't get where CT raw in and CT raw out would make sense... I mean you import raw, then you find out it's ok, then you write it back to disk?

Well two parts to that. First, CT raw out may be useful if other programs such as emulators can consume that format, and/or if that format can represent certain disk data that other formats cannot. Second, passing CT in and getting another CT out can make sense -- the input data is checked/validated, and regenerated in the output (e.g. bitcells all adjusted to 2us in a regular-length data track). So can avoid degeneration seen in multi-generation analog copies f.ex.

[mr.vince]

For processed I'd definitely prefer a different file ending to be used - raw should be raw, if it's processed, it should be "processed raw" or similar. Just to differentiate between things that originate from floppies and "tampered with" data.

We are currently doing minor tweaks and fixes to the codebase, then this will be handed over to porters to create libs for OS X, Linux etc. After all is fine, there will be a release. This way we can avoid a back and forth of the codebase...

[Keir]

Originally Posted by mr.vince

We are currently doing minor tweaks and fixes to the codebase, then this will be handed over to porters to create libs for OS X, Linux etc. After all is fine, there will be a release. This way we can avoid a back and forth of the codebase...

Understood and as I guessed. Thanks for the update!

[dlfrsilver]

using file *. PCR for Processed RAW and *.CTR for raw files ? would be a good idea

[IFW]

Except for I wouldn't call the updates minor still
So it will take some time; I want to add quite a few things.