findcrcs (fast crc finding tool, v0.2, windows support added)

[HwitVlf]

That's unfortunate.  EDIT SEE POST 15

I use findcrcs mostly to extract the split-tracks from a multi-track game that I dumped into a single image. Its easy to make a frontend to search for one track at a time from user input size/CRC, but it's miserable to enter all that information for a game with 40 tracks. So the question is how to automatically parse a game listing, automatically extracting size/crc, in a way that's compatible all the listings here. I've used my fromend for PS1 game listing extensively with no problems.

The upgrades in your v3 are quite useful.

[HwitVlf]

Anything worth doing is worth doing right, so I care to make this tool decent. But I'm also fairly busy, so there's  a small window when I'm willing to put effort into refining the GUI. If anyone cares to do some testing to iron out bugs, speak now or forever hold your peace.

EDIT See post 15 for GUI

@rosewood I tried your build on some larger ISOs. It rejects some large windows with a message, but runs on some ~4GB images and incorrectly lists no matching CRCs. It would be better to add a limit message to my GUI that have it erroneously report ' no match'. Do you know what the size cap for an accurate scan is?

[rosewood]

I figured out what was wrong. It seems that it depends on the browser how the data is copied. IE11 - copies all values separated with a space and rows separated with a space and line break. Edge - copies all values/rows separated with a line break. Firefox - does it right.
Your program requires a fixed formatting (i.e. all values separated with a tab and all rows separated with a line break). Maybe you should implement a check for whitespace characters first before doing the scan.
For now I'll use Notepad++ to change the data into the correct format, e.g. replace ' \r\n' with '\r\n' and ' ' with '\t'.

By the way, I am neither the author nor did I change comething in the code of findcrcs. It just happened that the link to v2 was unavailable for some time, so I searched the www for the file and found the updated source on github. I couldn't get it to compile under Windows and in the end I used Ubuntu with Win64 target settings.

[HwitVlf]

Thank you rosewood, very helpful info. I'm working on a fix for IE and testing other browsers. I implemented a variable detection in v4, but it will still fail with IE because of the extra space added to row-ends.

The frontend currently seems to work with track-info copied from Firefox, Midori and Opera v12.18.

[HwitVlf]

HERE is the final version of the GUI. I tested with every browser I could find and the only ones that bungled the formatting were Microsoft IE and Edge. I added a fix for IE, but I don't really care to fool with Edge when so many other browsers work properly. Microsoft products just aren't what they used to be.

As far as changes in the GUI, I tested on about 30 BINs from my garbage folder of bad dumps and fixed several bugs, some significant, some only triggering on rare random factors. Hopefully it'll be useful to someone.

The v0.3 findcrcs appears to have bugs (not the GUI but findcrcs itself). I confirmed that t doesn't detect CRCs in some files as it should. It will not detect Track1 of the game HERE, but v2 does.

[retaliator]

Checking the archive of v7 I'm getting a virus / malware alert: Pynamer.A!ac!?

[celebi]

same here.

[HwitVlf]

It's wise to be cautious. I did include the source code, but I doubt anyone cares or knows enough to go through it. If you open the source code and search for 'filewrite', you will find the only interaction the code has with the PC that can actually changes anything. This is the line that writes the extracted tracks to the hard drive. 'FileRead' will show you the only place it gathers any data from your PC; this is when it's reading the tracks from the source CD image.

This tool is written in Autoit language. Autoit doesn't compile the script into machine code, but stores it internally in an executable wrapper. Since all Autoit scripts share the same wrapper, it's fairly common for the language to produce false positives. You can read about it HERE. I have Comodo anti-virus, and for whatever reason, it alerts every now and then when I'm compiling one of my AutoIt scripts.

I know we live in an age when people can't really be trusted, but for what it's worth, I give my word that I wouldn't produce anything like a virus.

On a side note, after I made this front end, I found that someone else had already made a similar tool HERE. If you're still worried about the false-positive, it's a very good alternative. I prefer the smaller footprint of my version, but the built in tools in the other front-end are very nice too.

[HwitVlf]

I ran the frontend through VirusTotal and it was tagged as virus by about 30% of the scanners. With those results, I wouldn't even use it if I hadn't written it. The tool is insanely simple so I wondered what was causing so many alerts.

After some testing, it appears to be from a function that pauses/resumes findcrcs.exe. Normally a front end would wait for the tool to finish and process the resulting console-output.  But if findcrcs is scanning for a track that is all 00s, it will often return thousands of hits and take forever to finish. To overcome this long wait, my frontend monitors findcrcs output, when some results have been found, pauses findcrcs, tests the result's MD5, and it there is a match, terminates findcrcs, or if there is no match, resumes findcrcs and continues to wait.

This 'pause exe' function is built into Windows, you'll find it near the bottom of the source code as  'Func _ProcessSuspend()' and 'Func _ProcessResume()'. Apparently the virus scanners think using it means you're up to no good. I 'commented out' these two functions and VirusTotal went down to 2 no-name positives.

It's rather heavy handed for virus scanners to alert on anything using the pause function, but anyways, I'm submitting a false positive notice to a few of the bigger name companies. We'll see what happens.