Page 15 of 16

Re: IPF and Openness

Posted: Sun Jun 19, 2011 9:16 pm
by mr.vince
balrog wrote:Still, the spec is most important for me. Even if it's just a bunch of (hopefully documented!) header files.
Regardless of which direction we choose to go, this is what hopefuly will happen in parallel, either by us or by someone else doing it... BUT header files won't help you much. IPF is not a sector dump format, but a fully scripted mastering format that contains information on how data is going to be written to a master disk. Therefore a proper documentation needs to be done...

Re: IPF and Openness

Posted: Fri Jul 15, 2011 7:43 pm
by Darkstar

I have to rant a bit here about IPF and openness, but I keep reading about that in various forums and mostly people tell other prospective users who want to dump their disks for preservation to "stay away from KryoFlux". So why is that?

I don't think the attitude KryoFlux is presenting wrt. opening up the format is NOT a very helpful one.

It's practically like Stroustrup saying "Hey, you know, we will never release our C++ compiler because we're the only people who know how it works because we spent countless years perfecting our C++ programming skills. If we release it now, people who don't have a clue will use it and the world will be swamped by broken software"... guess what? That's exactly what happened, and it's not an entirely bad thing IMHO.

Some other analogy: "We don't want people to have access to screwdrivers and soldering irons, because they will want to use it to repair their TV sets. We have spent years on perfecting our TV set repair skills, and we know how to do it, if people start doing it themselves they will obviously break something. So we want to keep close control on who gets our screwdrivers and soldering irons. Oh, and we also invested lots of money in developing these repair tools so we obviously don't want other people to make any money off it. Our repairs are as cheap as possible so please let us do the work"

See the analogy?

I mean, seriously, of course opening up IPF and the hardware will lead people to start hacking with it, and they *will* break the format in the process and submit bad/broken dumps. But the key to keep IPF files as close as possible to the originals, and not get swamped by "fake" dumps, lies not in keeping the software closed but in establishing an "official" dump database or something. No matter if it's SHA checksums, cryptographically signed files, or something else entirely. You would probably get enough dumps of different games to tell the originals from fake ones yourselves, it's not that hard if you have access to the raw stream data.

Oh, and while I think that creating the DLL file with the complete floppy emulation is a good thing for some Emu devs out there who don't know an awful lot about floppy disk hardware, *requiring* the use of a closed-source emulation component will deinitely be a blocker for most open-source emulators. IPF could become some sort of de-facto standard for *all* disk images (just look at the hundreds of image types that MESS supports for example to see why this would be a good thing) but by keeping the library closed-source and available for some systems only, you're basically scaring away most of the people who could really help drive IPF adoption forward. I mean, wow, there's actually *three* emulators now that support IPF (UAE, Caprice and Spectaculator), and this is after what, 5 years that the DLL files exists now?

I really hope that you'll reconsider your stance, but until that happens I guess that the STREAM format is the only open way to use DTC/KryoFlux. Widespread IPF adoption will most probably remain a wish.

Again, sorry for the rant, I am a proud owner of a 1st generation KryoFlux device and I consider it to be one of the simplest ways to dump my disk collection, but I won't be completely happy until these "format wars" have ended and IPF (or some other open format which can be created with KF) is the one and only disk image format out there. Might take a few generations though ;-)


Edit: Mixed up STREAM and DRAFT, sorry for the confusion. I know STREAM is open and that's what I was referring to

Re: IPF and Openness

Posted: Fri Jul 15, 2011 7:56 pm
by karadoc
I'll reply to this more full later, but the "format" that KryoFlux produces is already open:
We also know of one independent implementation of this already.

Re: IPF and Openness

Posted: Fri Jul 15, 2011 9:37 pm
by karadoc
Okay, firstly I want to say that I don't think anything you have said is unreasonable. We ourselves initiated discussions on opening the format because we want to do it. We know we need do it. Things have just got in the way.

You're analogies seem to stem from our website about open source. That stuff on is years old (at least five), and most of it no longer applies. We should delete it.

I don't think the checksums are as much a problem as we originally thought. As you say, we can just publish SHA hashes for them. Something better can be contributed when the source is available perhaps.

So really, as this thread details, we "just" need to pick the license. It does take time to sit down together and nail down exactly what we want to do, and what license we are going to use. We need to have a plan that we all agree on, that we are all happy with. This is currently the hold up, because we've been extremely busy.

Once the writing stuff is done, we'll pick this up again. Once that is out, give us a little longer, and then please complain if we don't.

Re: IPF and Openness

Posted: Wed Oct 12, 2011 9:51 am
by karadoc
We have (finally) come to a decision about the IPF library. As we said, we would come back to this after the KryoFlux writing work was finished, and last week we had "the discussion" that needed to be done.

We have decided to use the MAME license. Other licenses may follow, we will have to see how things go.

We often like to "just release stuff", but by some wierd coincidence some independent work has been done in MESS to support IPFs, so we might as well announce it now.

We'll post a download link here when it is available.

One other thing we discussed was documentation. We would very much like this format to be properly documented, and ideally, we would have liked to do that along with releasing the source. Quite some time ago we realised we simply did not have the resources to accomplish this. So, if you are intending to have a look at the IPF library source, or maybe you already had some intention to document it, please let us know. We can organise a concentrated effort rather than have many different documents available, and this way we can have many eyes on the same one.

We would finally like to say *thank you very much* to everyone who took the time to contribute their help and ideas on this subject, both in this thread and privately. Whether we agreed or not, it was all very helpful to us in making a decision.

Re: IPF and Openness

Posted: Sat Oct 15, 2011 8:52 pm
by mr.vince
Here it is, enjoy!


Re: IPF and Openness

Posted: Sat Oct 29, 2011 12:01 pm
by mr.vince
Hey guys, why so silent...? Any feedback? This issue seemed so urgent and pressing... Anyone already used the code? What did you find? How does it work? What could we add to it?

Re: IPF and Openness

Posted: Mon Oct 31, 2011 8:06 pm
by Jeff_HxC2001
mr.vince wrote:Hey guys, why so silent...? Any feedback? This issue seemed so urgent and pressing...
:lol: are you really surprised ?

IPF and Openness

Posted: Mon Oct 31, 2011 10:20 pm
by mr.vince
Compared to the huge discussion upfront... Yes, a bit.

But since you are here... Will it improve IPF support in HxC?

Re: IPF and Openness

Posted: Mon Oct 31, 2011 11:38 pm
by Jeff_HxC2001
mr.vince wrote:Compared to the huge discussion upfront... Yes, a bit.

But since you are here... Will it improve IPF support in HxC?
mmhh no i don't think so. the library already has all what i need.
About the game who doesn't work, this is a settle time problem. the game jump/test/leave the last track only a few ms (~10ms).
i have to reduce the USB HxC settle time to get it working ;)