copyprotection over devlib

[Joe Maroni]

currently i try to start an information tool about caps images but i saw in the document that your .dll doesn´t support any function to get the type of copy protection the ipf image has....

is it possible to implement this feature or not...??

[Interceptor]

István may correct me on this, but i think you'll find that the copy protection format itself isnt defined in the IPF file, so you'd have to recognise the protection from the data in it.

the IPF files doesnt say 'this is a copylock track, so here's what you need to do' it just presents the data to whatever is reading it, and let that make what it will of it, just as a real disk on a real machine.

[Joe Maroni]

well thats really sad to read..:(

i thought that there is any kind of header where this information may be stored...

just for remastering...how did you think to rewrite the data to any original disk without having the information about how the data is stored on the disk...???

[Interceptor]

just for remastering...how did you think to rewrite the data to any original disk without having the information about how the data is stored on the disk...???

that information IS in the IPF file. what not in the IPF file (i'm not certain on this, just "fairly sure"), is "this is a copylock track, this is a speedlock track" etc etc, since to a disk image it doesnt matter what the track is by name, it is how it is. and it's stored fully descriptive in a remasterable format.

you're talking about 2 different things :)

like i said, István can probably answer that in a more informative way.

[Joe Maroni]

and what is about tracks with different density..??

e.g. how to know like turrican 2 data is stored..??

is it really a problem to offer the structure of the ipf format..??
i´ve got in contact with jens schoenfeld last days and can tell you that no disk can´t hide its secret with the usage of the Catweasel MK IV...


well...i think it the solution for your remastering tool...;)
probably...:D

[fiath]

There is a good Knowledge Base entry on this:
http://www.softpres.org/page.php?id=faq:disk_images:documenting_formats

Of course, if you have any individual requests we can probably let you know. However, please note we still have a huge mail backlog, so please not many! :O

We heard the same thing of the CW Mk IV. It sounds good. Unfortunately, we don't have one to play with.

Structure of IPF format - yes, we will one day for preservation reasons (or at least, the source code to the IPF lib). However, you don't really need it anyway. You can use the library. You could knock-up a simple mastering tool using this. Granted, it might not be a perfect solution, but certainly better than the current situation. Or just wait until we do it, one day...

[Joe Maroni]

well i like to donate one catweasel to the team but like to get it back when you finished your work...


does this sounds well..???

[fiath]

Thanks, but no need, Jens said he would send us one.

[fiath]

Some more information on this, now I verified a few things.

*Anybody* can write a mastering tool for IPF images, which can be as good as any we would write ourselves. This can be done completely using the IPF library as it is right now.

The problem is entirely down to the target hardware. If you want to support a piece of hardware, writing IPF's to it. Feel free. Mastering IPF's is still relatively low priority for us atm against other things we have got to do. I'm sorry to dissapoint, but that is the simple truth. Lack of hardware to use is also obviously a problem.

The one protection that *might* (but might not! - but I'm can't find out for sure though right now) need additional information exposed by the IPF library, is games with flakey-bit-type protections. However, this is relatively few games, and is this information something that can be easily added to the library later anyway.

So anyone is free to have a stab at it - there is full developer documentation on the download page for the IPF library. Of course, working out how to write the protections you will have to find out for yourself ;)

[Joe Maroni]

but its not really easy to understand bit cells and all the stuff...

well...i´ll give it a try but if i get problems with all that stuff i like to abort everything...and work on to my new levelripper project...:(

its really better for me to work with files that include chunks and all that stuff....;)

[fiath]

If you are going to write a mastering tool, it is really rather imperative to understand the fundermentals of magnetic recording theory. This is how the data is stored on the *disk*, and not how it is locally structured at a higher level (chuncks etc). We represent the data *as it is stored* and hence to deal with this data you have to understand about these lower level properties. Don't blame the file format! Bit cells has nothing to do with us, we didn't invent them, it is how the data is stored of the disk themselves, and hence why we talk about them all the time.

You really need to understand about flux transitions, bit cells, grouping, encoding, etc. etc. otherwise, I am afraid to say there is probably not much point starting to write a mastering tool. It's *not simple*, its actually quite complicated. Hence why we have not found time for it yet! :D