> Thanks Haze,
>
> So... is this statement correct? (I am simplistically assuming everything is cue +
> bin again):
>
> The Data SHA1 is the combined data of the source (pre-chd compressed) cue and bin
> files, minus cue metadata like comments (and other arbitrary variable data).
>
if you do a chdman info -i e:\mamechds\ddr2m\885jaa02.chd
SHA1: f02bb09f41533c6ec496a662d815e85b304fcc72
Data SHA1: 5c57eeafa4c8dd8e62bab04fcabd46e586d1b59d
The "SHA1" I believe is the full hash of the uncompressed metadata and data, this is the one that gets listed in the drivers as it identifies the individual CHD. (Metadata can include things like disk geometry on HDD images, and the lock code on certain types of Flash cards too for example - ie things that are just as important as the data)
the "Data SHA1:" I believe is just the hash of the uncompressed data part. It means you can see if 2 CHDs are the same except for the metadata part more easily.
> i.e. The combined cue + bin checksums of the original ( pre-chd compressed) source
> files would not match the Data SHA1.
>
correct, it would not match, remember even with CDs some of the source images have multiple tracks split into multiple files (eg .bin and .wav files, in which case obviously we don't want to be storing wav headers either, but rather the actual data) The data SHA1 we store is after we've ensured all that is in a standard internal format.
> Am I getting it?
basically as long as you understand that the only way to verify a CHD is to decompress it, ideally by calling CHDMAN and asking it to perform a verify operation, yes.
The idea of the format is that the CHD file can be verified as non-corrupt by using CHDMAN without the need for extra cue files etc. because the CHD itself contains the hash for all the data it stores, should the CHD become corrupted then verification against that hash would fail.
|
Index 
Flat 
Re: Chdman questions
Reply
