My intentions with the first post were not to cause conflict or infighting, but only to spur communication and consensus. I can see where it can be viewed as a bit childish, I will redact it. That can be settled and on with the important stuff rather than communication style...
Yes most of us are aware that this project started and grew from PSX database, that's a good thing and efforts are surely appreciated and attractive to people wishing to preserve whatever is in their interest and leads them here to begin with.
Please elaborate on what you mean by "oddities are examined and defined in db (ASCII field)". I'm not entirely sure what you mean by that.
binary data is a lazy way to do things, if your motivation is to examine and preserve some sort of information -
it's just conservation you'd be doing, missing documentation part.
I'm all for that, but what should we be documenting? Should we be documenting just anomalies in sub code? topology? user data? protection mechanisms? conflicts between sub code and TOC? <insert anomaly here> ? all of the above? Do please be specific, as we should all be really interested to know what it is we should be focusing on, rather than just conservation as you say.
Some of these things are fairly easy to document, others would require a great deal of investigation and documentation. I myself do that on other platforms so am not averted to such things, but certain aspects of it may also garner unwanted attention from various entities. However I believe that should not stop it from being done.
thus i do not agree on generaly expanding image format to .img/.sub/.ccd, .mdf/.mds, 2448 sectors + TOC or any other.
this data should be analyzed and stored in db in readable format.
(the same with other things, i.e. medium topology based protections - timings should be analyzed and stored in table
.mds (or other neccessary format) then could be generated from this data as an output
with SafeDisc and similar protections that already are in db, this information would be much more useful
if actual sectors affected would be listed in records - this data could be examined then and worked with,
without a neccessity to have actual matching images
An interesting point indeed, but how should such information be collected and stored, again please elaborate on it. As for the last part with safedisc and also laserlok, a list of sectors is easy enough to generate. But I think the contents of those sectors should be examined more closely for possible meaningful data which may be contained therein. There is conflicting opinions about that dating back to the first appearance of them, and maybe it's time someone investigate that and figure out exactly what is true or false about such theories.
Your last point I can understand completely, so it need not be discussed any further. As I said I will redact the first post.
Also thank you for maintaining some interest in things even through differences in opinion and sometimes conflict and heated discussion. Also please try to understand that some people are quite passionate about this, and there is no intention of stalling the project or creating dissent. Only to better preserve. =]
BTW. I feel that this topic shouldn't be a sticky, because it states opinions rather than general policy.
The point of such topics is discuss opinions and make decisions which in turn create the general policy and procedures, without it, any project would stagnate and become a dead carcass. I feel important topics and discussions should be stickied as it makes it easier for newcomers to get an idea of what goes on, and also as reference points for reflection by experienced users. IMO there are many relevant posts in this forum that SHOULD be stickied which are not.
ps. I agree with themabus' feeling that things sorta got 'out of hand' and we just kept adding more systems which less and less suitable for our initial dumping method.
Well it's a bit too late to do anything about that now, the cat is already out of the proverbial bag.
Go have some talk with ripper about 'half sectors' and sector overlaps etc and you'll learn that your proposed solution prolly isnt even gonna cut it. A custom format would be needed in order to really preserve all these mastering errors and oddities.
I don't want to talk with ripper about anything, and you know damn well he is very arrogant, and condescending. Also as themabus mentioned in his post, is this about preservation or conservation. That needs to be worked out first before any other discussions about formats and other things take place. Also ripper is not the be-all end-all of information about what's on various discs, the fanboi-ism is getting a bit annoying actually. I don't want this to just end up in a bickering session though, so if you have information about such things rather than tell us to go ask so-and-so about it, post it up here for all to know. Isn't that the whole point?
And maybe it's a good idea to just mark any dump that isn't preserved correctly under the current standards as 'yellow'.
Indeed there are many questionable things, who decides what though, and based on what... again I think "current standards" are not even defined at this point. Except for only certain systems like PSX and PS2 where that has already been decided, but could change if the need to is founded.
Plextor PX-760A 1.07 (+30) : Plextor PX-716SA 1.11 (+30) : Plextor PX-W5224A 1.04 (+30) : Plextor PX-W4824 1.07 (+30) : Plextor PX-W4012TA 1.07 (+98) : Plextor PX-W1610TA (+99) : Plextor PX-W1210TA 1.10 (+99) : Lite-On LTR-48246S (+6) : Lite-On LTR-52246S (+6) : Lite-On LH-20A1H LL0DN (+6) : BenQ DW1655 BCIB (+618) : ASUS DRW-2014L1 1.02 (+6) : Yamaha CRW-F1 (+733) : Optiarc SA-7290H5 1H44 (+48) : ASUS BW-16D1HT 3.02 (+6)