21 March 2014, 04:00 | #21 |
Registered User
Join Date: Apr 2010
Location: Chicago/USA
Age: 55
Posts: 659
|
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 |
21 March 2014, 08:26 | #22 |
Registered User
Join Date: May 2011
Location: Cambridge
Posts: 682
|
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!
|
21 March 2014, 10:11 | #23 |
Cheesy crust
Join Date: Nov 2008
Location: Hawk's Creek
Age: 48
Posts: 1,383
|
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. |
21 March 2014, 12:35 | #24 | |
Registered User
Join Date: May 2011
Location: Cambridge
Posts: 682
|
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.
Quote:
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. |
|
21 March 2014, 14:03 | #25 |
Cheesy crust
Join Date: Nov 2008
Location: Hawk's Creek
Age: 48
Posts: 1,383
|
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?
|
21 March 2014, 15:50 | #26 |
Registered User
Join Date: May 2011
Location: Cambridge
Posts: 682
|
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.
|
21 March 2014, 15:56 | #27 |
Moderator
Join Date: Jan 2003
Location: ...
Age: 52
Posts: 1,838
|
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... |
21 March 2014, 16:23 | #28 | |
Cheesy crust
Join Date: Nov 2008
Location: Hawk's Creek
Age: 48
Posts: 1,383
|
Quote:
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? |
|
21 March 2014, 20:18 | #29 | |
Registered User
Join Date: May 2011
Location: Cambridge
Posts: 682
|
Quote:
|
|
23 March 2014, 11:12 | #30 |
Cheesy crust
Join Date: Nov 2008
Location: Hawk's Creek
Age: 48
Posts: 1,383
|
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... |
23 March 2014, 18:24 | #31 |
Registered User
Join Date: May 2011
Location: Cambridge
Posts: 682
|
Understood and as I guessed. Thanks for the update!
|
23 March 2014, 18:45 | #32 |
CaptainM68K-SPS France
|
using file *. PCR for Processed RAW and *.CTR for raw files ? would be a good idea
|
23 March 2014, 19:59 | #33 |
Moderator
Join Date: Jan 2003
Location: ...
Age: 52
Posts: 1,838
|
Except for I wouldn't call the updates minor still
So it will take some time; I want to add quite a few things. |
Currently Active Users Viewing This Thread: 1 (0 members and 1 guests) | |
Thread Tools | |
Similar Threads | ||||
Thread | Thread Starter | Forum | Replies | Last Post |
KryoFlux host software available for AmigaOS 4 | mr.vince | News | 1 | 13 February 2014 05:00 |
AmigaOS 4.1 Classic Available To Buy | amigakit.com | News | 72 | 19 August 2012 21:56 |
AmigaOS 4.1 Classic Screenshots | DarrenHD | support.Hardware | 34 | 06 January 2011 17:47 |
AmigaOS 4.0 for Classic Amiga available now! | Mikey_C | News | 20 | 30 November 2007 20:35 |
m4-1.4.2 for classic AmigaOS (not using IXemul) | Paul | News | 1 | 24 October 2004 21:01 |
|
|