IPF and Openness

All news about KryoFlux go here.
ZXDunny
Posts: 2
Joined: Tue Feb 08, 2011 5:15 pm

Re: IPF and Openness

Post by ZXDunny » Tue Feb 08, 2011 7:38 pm

Interceptor wrote:I dont see why anyone wants to create their own ipf files though?

Nor am I sure why anyone thinks they are qualified to do it?

Not ignoring the rest of your post it's all good comment, but that's the part that stands out, to me at least.

I fear that nay be off topic though, sorry.
Thanks for not blowing up at me :)

Your question is a good one - and my answer has to be that as you're using .ipf files as disks in an emulator, then people are going to want to write to them in the emulator - that's what they do. You could insist that all .ipf disks are read-only, but some games do write to the disk.

And of course, if I'm going to add .ipf support to FUSE on the Pandora, I'll need to be able to implement my own library, as yours likely won't run on ARM-linux.

The key here is of course that the emulator author is likely to know what he wants to do with .ipf files, so you should make all the information available that they need.

D.

User avatar
karadoc
Posts: 138
Joined: Sun Oct 31, 2010 9:12 pm

Re: IPF and Openness

Post by karadoc » Tue Feb 08, 2011 7:42 pm

Hi Dunny. Thank you for your comments.

This is a bit off topic, because ultimately this thread is about what we need for our preservation goals, however, I will try to address your points.

Yes, the format should be open, that is what we want, and the goal of this post.

I think you are very much underestimating how much work it will be to rewrite our library however, let alone try and reverse engineer it. People have tried that before, but it is quite unlike anything else out there that we know of - it is not simply a case of supporting a file format.

It would be much more useful to work together on improving what there is. However, if rewriting the library is what you have decided to do, so be it.

Maybe it is worth making it clear that the library does far more than reading a simple bit stream, it does "virtual mastering", and you would need to do the same if you want to support ipf files. This is why I say you would need to rewrite the library, and that is many thousands of lines of code to do, just for the algorithms.

As to producing IPF files... What is it you want to be able to do? Sadly, It's not going to magically make copy protections work. We have an entire tool chain built up over 10 years that is required to do that properly. I suspect that would take a lot of effort, for little gain.

Anyway, back on topic, do you know of any licenses we could use given our requirements?

User avatar
karadoc
Posts: 138
Joined: Sun Oct 31, 2010 9:12 pm

Re: IPF and Openness

Post by karadoc » Tue Feb 08, 2011 7:58 pm

Okay, I see. Well one alternative is to use diff files like WinUAE does. This also has the benefit of not corrupting the original disk image. I think we dont need, from a preservation perspective is a load of alts flying around. If you want to write to a disk, use another format. I just feel that IPF is the wrong tool for that job...

User avatar
Interceptor
Posts: 58
Joined: Wed Oct 06, 2010 10:17 am

IPF and Openness

Post by Interceptor » Tue Feb 08, 2011 8:08 pm

The reason we are harping on about the lib, is that documenting ipf is an epic job, releasing the lib source which is fully commented is a great weight off this effort, and we want it open anyway.

User avatar
mr.vince
Posts: 2120
Joined: Tue Oct 05, 2010 5:48 pm

IPF and Openness

Post by mr.vince » Tue Feb 08, 2011 8:22 pm

If I may: IPF stands for Interchangeable Preservation Format. Writing to such a container after creation is a no-go. If someone wants to write a highscore or a save game... Do like Karadoc has explained and write a diff file. These can even be versioned and deleting them will return you to the original state.

This is again not meant to sound arrogant but there is a wealth of information available on the Softpres website. It also explains the philosophy behind this, e.g. the problem above.

User avatar
IFW
Posts: 3079
Joined: Mon Nov 08, 2010 2:42 pm

Re: IPF and Openness

Post by IFW » Tue Feb 08, 2011 10:10 pm

Actually, I am quite happy to help out with the ARM side of things, you see we have this little device called KryoFlux that happens to run on one of those lovely beasts - not to mention the recently unveiled NGP is using one as well, although a slightly more advanced version ;)

MrX_Cuci
Posts: 7
Joined: Sun Feb 06, 2011 3:43 am

Re: IPF and Openness

Post by MrX_Cuci » Tue Feb 08, 2011 11:22 pm

Probably an interesting read for you guys by the BSnes author: http://byuu.org/articles/licensing/ I hope it works out for you guys and your file format will be widely supported eventually. I am looking forward to it. The only thing holding me off getting a Kyroflux board.

User avatar
IFW
Posts: 3079
Joined: Mon Nov 08, 2010 2:42 pm

Re: IPF and Openness

Post by IFW » Tue Feb 08, 2011 11:31 pm

KryoFlux has nothing to do with IPF, although you can use it to create stream dumps to be processed later.

User avatar
IFW
Posts: 3079
Joined: Mon Nov 08, 2010 2:42 pm

Re: IPF and Openness

Post by IFW » Tue Feb 08, 2011 11:48 pm

Very interesting article btw, thanks for the link!
I'd highly recommend it for everyone to read and think about it.

So, back on topic: any suggestions yet for a suitable, existing licence...?
As we said, we'd rather make the whole code public and free to use for anything (apart from highly commercialized projects) rather than let a small amount of information (format definition) available only.

User avatar
karadoc
Posts: 138
Joined: Sun Oct 31, 2010 9:12 pm

Re: IPF and Openness

Post by karadoc » Wed Feb 09, 2011 12:40 am

Very interesting article MrX. Thanks for that.

Post Reply