Page 300 of 354
Re: DiscImageCreator
Posted: Mon Aug 23, 2021 9:09 am
by reentrant
Come on guys. It's as simple as implementing some command line switch to perform extra hash caclulations...
Re: DiscImageCreator
Posted: Mon Aug 23, 2021 9:26 am
by F1ReB4LL
reentrant wrote:Come on guys. It's as simple as implementing some command line switch to perform extra hash caclulations...
I've already explained those hashes are important and shouldn't be disabled. DIC dumps every disc upto 15-20 minutes on 4x, while the hash calculating takes maybe a minute (when reading data from HDD, from ramdisk it should be faster). If "the years of your work" don't deserve that minute - better not to do any dumping at all.
Re: DiscImageCreator
Posted: Mon Aug 23, 2021 9:29 am
by sadikyo
F1ReB4LL wrote:I will personally nuke all the dumps made with unofficial/hacked tools, we don't need them. We don't accept the dumps from non-plextor drives, why should we accept dumps from some shady builds?
I just want to add my 2 cents here. Please be aware of how this comes across. I understand we have to have certain standards such as the plextor requirement for standard submissions, but there are ALWAYS going to be some special exception cases, or types of discs that can't be dumped via the normal methods. And if we make a blanket block on any such submission entirely, there will be a lot of content missing.
I'm not sure if that was your intention, but the statement does appear a bit threatening about nuking large batches of content. I'm going to assume this is not an actual intention. We certainly wouldn't make a large decision like that without much discussion and hashing out the details.
I think both you and also user7 have made plenty of great contributions to this project over the years. Let's not let an issue debate cause any actual contention or issues.
Oh, btw...I think his comment about a good build was talking about his computer. Not a build of DIC.
Re: DiscImageCreator
Posted: Mon Aug 23, 2021 1:56 pm
by hiker13526
If the descrambling isn't reversible for discs with mastering errors or unusual scrambling, won't it have to be redumped regardless of what the log shows?
If the .scm hash is the One True Hash, why not store it in the database?
Re: DiscImageCreator
Posted: Mon Aug 23, 2021 2:56 pm
by bsbt
The hashing phase is slow at least in part due to it only reading 2K at a time from the file. There's even a comment to that effect.
https://github.com/saramibreak/DiscImag … l.cpp#L557
Changing it to something like this (reading 512K at a time) should be noticeably quicker (from my experience writing something similar in C#, I haven't tested this change in DIC):
Code: Select all
#define CHUNK_SIZE 524288
BYTE data[CHUNK_SIZE] = {};
UINT64 ui64Remaining = ui64FileSize;
OutputString("Hashing: %s\n", pszFnameAndExt);
while (ui64Remaining > 0) {
UINT uiChunkSize = ui64Remaining < CHUNK_SIZE ? ui64Remaining : CHUNK_SIZE;
if (fread(data, sizeof(BYTE), uiChunkSize, fp) < uiChunkSize) {
OutputErrorString("Failed to read: read size %u [F:%s][L:%d]\n", uiChunkSize, _T(__FUNCTION__), __LINE__);
return FALSE;
};
nRet = CalcHash(&crc32, &context, &sha, data, uiChunkSize);
if (!nRet) {
break;
}
ui64Remaining -= uiChunkSize;
}
Re: DiscImageCreator
Posted: Mon Aug 23, 2021 3:30 pm
by F1ReB4LL
hiker13526 wrote:If the descrambling isn't reversible for discs with mastering errors or unusual scrambling, won't it have to be redumped regardless of what the log shows?
It is reversible for normal cases, but some dumps are a mess of descrambled and scrambled data. Also some scrambling/descrambling tools handle the data differently (the themabus'es descrambler adds weird headers to zeroed sectors, for example).
hiker13526 wrote:If the .scm hash is the One True Hash, why not store it in the database?
Ask iR0b0t. scm contains what was read from the disc, img and bins are conversions.
bsbt wrote:The hashing phase is slow at least in part due to it only reading 2K at a time from the file. There's even a comment to that effect.
Probably also worth not to hash img and bin separately for the single-track dumps.
Re: DiscImageCreator
Posted: Mon Aug 23, 2021 4:08 pm
by RibShark
F1ReB4LL wrote:user7 wrote:I've got a good build bro, thanks.
I will personally nuke all the dumps made with unofficial/hacked tools, we don't need them. We don't accept the dumps from non-plextor drives, why should we accept dumps from some shady builds?
IMO, this is not acceptable behaviour from a redump mod. I would strongly recommend actually making sure you understand someone before immediately taking harsh and counterproductive actions like this. user7 clearly was refering to his PC, not a build of DIC, and if you were unsure, you should have asked him what he meant first. Even if he didn't, you could have talked things over in a much less hostile manner.
Re: DiscImageCreator
Posted: Mon Aug 23, 2021 9:14 pm
by hiker13526
F1ReB4LL wrote:but some dumps are a mess of descrambled and scrambled data
I'm not clear on the benefit of the .scm hash. What's the process for discs with a mess of descrambled and scrambled data? Is the .scm hash used, or is the .bin hash used?
Re: DiscImageCreator
Posted: Tue Aug 24, 2021 10:53 am
by F1ReB4LL
RibShark wrote:user7 clearly was refering to his PC, not a build of DIC, and if you were unsure, you should have asked him what he meant first
Then he has nothing to worry about, what's the problem? Just warned people not to use untested/hacky builds, we have lots of problems with specific official & test versions of DIC, we don't need additional problems with hacky ones.
RibShark wrote:Even if he didn't, you could have talked things over in a much less hostile manner.
No hostility at all, I haven't said anything about
his dumps, the warning was neutral.
hiker13526 wrote:F1ReB4LL wrote:but some dumps are a mess of descrambled and scrambled data
I'm not clear on the benefit of the .scm hash. What's the process for discs with a mess of descrambled and scrambled data? Is the .scm hash used, or is the .bin hash used?
What do you mean by "used"? In db? Db only uses cue-bin images, ofc. SCM hash is needed when/if you decide to verify some descrambled image by scrambling it back. Messy discs may give a different result, depends on the case. Also, there are known mastering errors when the scrambled CD image contains unscrambled sectors and the descrambled data contains scrambled sectors - again, if you don't have .scm checksums and don't have the scm image anymore, you can't really confirm the image is correct.
Re: DiscImageCreator
Posted: Tue Aug 24, 2021 6:02 pm
by hiker13526
F1ReB4LL wrote:What do you mean by "used"? In db? Db only uses cue-bin images, ofc. SCM hash is needed when/if you decide to verify some descrambled image by scrambling it back. Messy discs may give a different result, depends on the case. Also, there are known mastering errors when the scrambled CD image contains unscrambled sectors and the descrambled data contains scrambled sectors - again, if you don't have .scm checksums and don't have the scm image anymore, you can't really confirm the image is correct.
Would you advise that ideally the database would have .scm hashes?