redump.info Forum

Themabus:

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
etc.)

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. =]

Jackal:

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.

- Nexy

my point of view is such that this extra information should be presented in format suitable for database,
i.e. organized as some sort of readable structure, as it is with libcrypt
with this the purpose of this database extends further than index of hashes - it can be used independently of binary data -
one does not need to violate copyright law to work with such data

what should be or shouldn't be analyzed must be discussed, imho,
we have different opinions on this, i wouldn't want to push mine, i agree with you there, i just think it should be discussed

about topology, basically i don't see it much different from how it was done with libcrypt again
either .mds can be analyzed and data filtered from this container or medium could be examined itself with specific tools
my understanding is such that only few elements are of interest, as validation takes few seconds
though it could be that at each execution a subset of some particular elements is selected randomly from larger set
it would be easier to start from older implementations of such protections and then proceed forth to newer ones
maybe those older ones do not have ring 0 drivers of their own, so SPTI monitoring could be sufficient
or at least hacking shouldn't be too difficuly
(StarForce is what i have seen most, so i'm basing on that)

how to organize this all, i think new people should be recruited - coders, hackers, etc.
defined how things will be organized - by voting? / who votes? are all votes equal? what should staff hierarchy be?
(imho it's on shoulders of too few people now, i think Jackal was pretty much running site alone last year
now much depends on iR0b0t - hit by the bus factor and such
i myself would gladly resign then), etc.
and then those matters should be looked into and new database model developed at the same time,
that would address current issues and take those changes ito account
imho model Dremora had came up with was pretty good as far as addressing issues go - it could be recycled for ideas

Sorry for late reply, wasn't notified the thread was replied to.

Yes lets discuss what should be done and in which ways. Please put your idea's and opinions up for discussion, got to get the ball rolling.

PLEASE don't resign, your input and experience is very valuable and needed!

I'm not familiar with Dremora's model, enlighten me please.

Yes we need more people and knowledgeable ones, I'm trying to recruit such people, and have at least one now who will work behind the scene's at least, see other new sub forum.

So my thoughts on what to keep on the db, are list of error sectors for safedisc/cd ring protect/laserlock. That data is easily kept as a list, and doesn't violate any kind of copyright. Some research needs to be done into if the sectors are just plain bad on purpose, contain some meaningful data which can be extracted through a different unscrambling process, or unknown?

For sub code, maybe just a hash of that data to check if they match another disc, and only blue when matched once and green with multiple matches (fireball's suggestion).

For topology data, I don't even know where to begin with that, you say you have experience with starforce, please elaborate on what it checks for. I have some with securom and tages, and they are checking seek times. I am not entirely sure how the data is on the discs though, if they are doubled sectors or just constant/angular velocity changes or what. Certainly need more research into that.

thanks Nexy

this is wip db structure way back from 2009
http://pics.dremora.com/redump-NGS.png
titles are seperated to a table, so no limit of 2; sub info is broken apart to release table, so no need to specify it in brackets; info on languages is more detailed
we were discussing db issues at that time, though since then more problems surfaced

i haven't messed with Starforce, it's just from observations - it spins up medium and then does some seeks, apparently clocking timing between sectors
on some specific sites or forums .mds files, that people made with DPM on can be downloaded and then they can be used with .iso images, so it's all in there, in this meta data
Starforce is quite popular here, i'd say about every 6th or so game has it, so this could be used to advantage when doing debugging, comparing information from multiple .exes
sometimes there would even be DVD and CD release of same game, both protected with Starforce, so such cases could be of particular interest