DiscImageCreator (Page 120 of 142)

I tried AppVeyor but I have no idea how to build by resolving the dependency of the external library.

Absolutely necessary. Get a new PC if yours can't do fast calculations. Since we're using the descrambled images for redump checksums, the .scm checksum is the only evidence of the original data. And the .img checksum is important to compare with the calculated-by-the-site one + needed for the quick db-vs-log verifications.

Huh? I've dumped the "stacked" saturn discs years ago. And what's the connection between "stacking" the discs and importance of having the scrambled checksums? We have lots of discs descrambled in unusual ways, lots of discs with mastering errors, if they don't have logs with .scm checksums - they will be nuked sooner or later.

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?

What's the problem to make a 4GB RAMdisk and do all the dumping stuff there? All the calculations will be instant.

Come on guys. It's as simple as implementing some command line switch to perform extra hash caclulations...

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.

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):

#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;
        }

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.

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.

No hostility at all, I haven't said anything about his dumps, the warning was neutral.

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.