Latest DiscFerret beta software

Hi guys, Here's a screenshot of the analysis side of the current DiscFerret software build: http://i162.photobucket.com/albums/t242/philpem/Screenshot-1.png At the moment, I've got it reading IMG files (the format of some disc images Chuck Guzis sent me a while back). CWI files are next on the hit list (another one of Chuck's file formats) and then DFI files (the DiscFerret native raw image format). The GUI was built with wxWidgets, and in theory the code is completely cross-platform compatible. I'm aware of wxWidgets backends for GTK, Mac Cocoa/Carbon and Windows, so that covers all the major *nixes, OS X and Windows. As long as you have a half-way decent C++ compiler, that is (*cough* GCC). However: I will openly admit that the code has only been tested on Linux. It slows down to an absolute crawl (~60 seconds refresh time) if you turn anti-aliasing on... though I suppose that's to be expected when you ask it to plot 30-odd thousand data points on a scatter chart... The raw-reader app is working too -- I can specify the various parameters of a disc drive, and do a full track-by-track read of an entire disc, and dump the data into a file. Next on the 'add list' is DFI support (so the analyser can read it, of course!) then disc-format script support. Effectively, I want a tool which can be told what type of drive is in use, what disc format, and will automatically figure out whether double-stepping is needed, and what read parameters to use. Even to the point where it'll warn you if you specify a 100tpi format and a 96 or 48tpi drive... Built in sanity checking :) Which now brings us onto naming -- the reader app currently calls itself "discferret-read", and the analyser "Merlin". Can anyone think of better names for these, or should I be lazy leave them as-is? (Suggestions on an email to the usual address please!) At this point the reader app is close to releasable (involving maybe a few more weeks of work assuming I find a ready supply of Round Tuits), but the analyser needs a lot more work. Mainly because I seem to be spending a lot of time chasing mismatched-free bugs in the algorithms. Thank $DEITY for Valgrind (and a great big sarcastic "gee, *thanks guys*" to the GTK developers who have obviously never heard of it, much less used it on their own code...) Cheers, -- Phil. classiccmp at philpem.me.uk http://www.philpem.me.uk/