DiscImageCreator (Page 120 of 141)

Is there anyway to prevent dic from hashing .scm and .img to save time? is it necessary?

Thanks <3<3

sarami is it possible to make the latest dic test build a static link on GitHub (not Mediafire)? Darksabre wants to implement a "Update to latest test build" button in MPF to encourage more people to give you timely feedback - and having a static link directly to the latest test build file would allow him to do that. Many people still dump with old dic builds in DICUI/MPF and this would ensure new dumps are more likely to be using the latest dic.

I hereby veto Fireball. It's just a waste of time for everyone dumping a lot of discs and not worth adding just because someone thought the feature would be neat imo.

Because it requires going through a website interface rather than a direct file link which could be pulled down via an automated process. MPF could add a "push button to automatically update to latest test build" feature in it. Then more people can use your test version and give you feedback.

Please please tyty <3 <3

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.

Says the guy who has undumped discs marked on the wiki for years...

No sympathy for people that dump stacks of discs at a time I see. I've got a good build bro, thanks.

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.