the problem is that things like .cue and .bin are really bad approximations of a CD and eventually the internal format of the CHD will progress well beyond a level where those things can even be represented.
the SHA1 of the CHD is the SH1 of all the data and metadata that the CHD format uses to store a CD.
cuesheets can contain information like the filename of the .bin file (and even the path it's stored on) as well sa comment fields and the like, completely arbitrary information that we have no reason to store. It's also a loose and badly defined format (or at least badly used, many pieces of software interpret the same cues in different ways which has actually been a major problem in building software lists)
When CHDMAN outputs a .cue and .bin (or any other format) it attempts to build them based on the data that is stored in the CHD the best it can, nowhere is the original .cue or .bin being stored. If we were to store the original cue data in the CHD as non-hashed data people would quickly remove it anyway (as we see with romsets, readmes getting stripped etc.) If we store the original cue data and hash it we'd be hashing arbitrary data meaning you could have a CHD with the exact same data but different internal hashes because of an additional comment in the cue file or similar.
Also remember CHD is used for a lot more than CDs, and is completely unaware of the underlying file systems.
|
Index 
Flat 
Re: Chdman questions
Reply
