English Amiga Board


Go Back   English Amiga Board > News

 
 
Thread Tools
Old 21 March 2014, 05:00   #21
Abaddon
Registered User

Abaddon's Avatar
 
Join Date: Apr 2010
Location: Chicago/USA
Age: 48
Posts: 422
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
Abaddon is offline  
AdSense AdSense  
Old 21 March 2014, 09:26   #22
kaffer
Registered User
 
Join Date: May 2011
Location: Cambridge
Posts: 430
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!
kaffer is offline  
Old 21 March 2014, 11:11   #23
mr.vince
Cheesy crust

mr.vince's Avatar
 
Join Date: Nov 2008
Location: Hawk's Creek
Age: 41
Posts: 1,374
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.
mr.vince is offline  
Old 21 March 2014, 13:35   #24
kaffer
Registered User
 
Join Date: May 2011
Location: Cambridge
Posts: 430
Quote:
Originally Posted by mr.vince View Post
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.

Quote:
Originally Posted by mr.vince View Post
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.
kaffer is offline  
Old 21 March 2014, 15:03   #25
mr.vince
Cheesy crust

mr.vince's Avatar
 
Join Date: Nov 2008
Location: Hawk's Creek
Age: 41
Posts: 1,374
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?
mr.vince is offline  
Old 21 March 2014, 16:50   #26
kaffer
Registered User
 
Join Date: May 2011
Location: Cambridge
Posts: 430
Quote:
Originally Posted by mr.vince View Post
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.
kaffer is offline  
Old 21 March 2014, 16:56   #27
IFW
Moderator
IFW's Avatar
 
Join Date: Jan 2003
Location: ...
Age: 46
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...
IFW is offline  
Old 21 March 2014, 17:23   #28
mr.vince
Cheesy crust

mr.vince's Avatar
 
Join Date: Nov 2008
Location: Hawk's Creek
Age: 41
Posts: 1,374
Quote:
Originally Posted by kaffer View Post
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?
mr.vince is offline  
Old 21 March 2014, 21:18   #29
kaffer
Registered User
 
Join Date: May 2011
Location: Cambridge
Posts: 430
Quote:
Originally Posted by mr.vince View Post
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.
kaffer is offline  
Old 23 March 2014, 12:12   #30
mr.vince
Cheesy crust

mr.vince's Avatar
 
Join Date: Nov 2008
Location: Hawk's Creek
Age: 41
Posts: 1,374
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...
mr.vince is offline  
Old 23 March 2014, 19:24   #31
kaffer
Registered User
 
Join Date: May 2011
Location: Cambridge
Posts: 430
Quote:
Originally Posted by mr.vince View Post
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!
kaffer is offline  
Old 23 March 2014, 19:45   #32
dlfrsilver
CaptainM68K-SPS France
dlfrsilver's Avatar
 
Join Date: Dec 2004
Location: Melun nearby Paris/France
Age: 40
Posts: 7,175
Send a message via MSN to dlfrsilver
using file *. PCR for Processed RAW and *.CTR for raw files ? would be a good idea
dlfrsilver is offline  
Old 23 March 2014, 20:59   #33
IFW
Moderator
IFW's Avatar
 
Join Date: Jan 2003
Location: ...
Age: 46
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.
IFW is offline  
AdSense AdSense  
 


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 06:00
AmigaOS 4.1 Classic Available To Buy amigakit.com News 72 19 August 2012 22:56
AmigaOS 4.1 Classic Screenshots DarrenHD support.Hardware 34 06 January 2011 18:47
AmigaOS 4.0 for Classic Amiga available now! Mikey_C News 20 30 November 2007 21:35
m4-1.4.2 for classic AmigaOS (not using IXemul) Paul News 1 24 October 2004 22:01

Posting Rules
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts

BB code is On
Smilies are On
[IMG] code is On
HTML code is Off

Forum Jump


All times are GMT +2. The time now is 00:59.


Powered by vBulletin® Version 3.8.8 Beta 1
Copyright ©2000 - 2017, vBulletin Solutions, Inc.
Page generated in 0.27814 seconds with 11 queries