Search options (Page 1 of 3)

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.

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.

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.

Thank you both. I was able to do it with your advice 

The file was 0x752C big (29,996 bytes).
Since there is 0x800 bytes worth of "file data" in each CD sector, each sector will end at even intervals ie 0x800, 0x1000, 0x1800, 0x2000, 0x2800 and so on. So if I'm thinking right, the file's last sector should end at 0x7800 which leaves some unallocated space at the files end:

  0x7800
- 0x752c
-----------
    0x2d4 (724 bytes of unallocated space - that's a lot of room for text!)

I found the 2 copies of the file size right above the file name in a hex editor. And it worked well to edit them to the new file size (0x7800).

It's worth noting that the Playstation routine that loads data from the CD into RAM ignores the file boundaries anyways. Like you say pablogm123, the load sizes and  start-sector are written into the game's programming. The load routine uses with 3 variables.
1. Destination in RAM
2. Location of source data on CD (LBA value)
3. Number of bytes to load

Those values are usually stored in a table in the game's exe. So changing the file size  really has nothing to do with making the game load more data. All this edit will do is let CDMage inject/extract data into that wasted space at the end of the last sector. I'll edit the game exe separately to get it to load the new-larger file!

Thanks again, BIG help   

The database you are working on is a huge undertaking! I hope it goes well since the info would be great to have.

Redump's dat files do include the CRC32s for each track. Maybe you are running the dat files through a converter of some sort that is stripping some of the the information? I know RomCenter strips everything except the name, size and crc32 when you 'import' Redump's dat file.

Do I check the 'lead-in and lead-out area' by looking at the first and last sectors in ISOBuster?

On Rhapsody's music CD, both Subchannel Analyzer and EAC seem to be measuring the gap by counting the frames that have a Q-Index '0' combined with a P of 'FF' (i.e. 120 lines =1.45 gap etc), but they aren't counting the frames immediately above that have a Q-Index '1' and a P of 'FF' (see picture I posted above). That means they're detecting the gap correctly right?  I only wonder because if the '1+ff' frames are included in the gap with the '0+ff' frames, their total becomes 150 which seems suspiciously close to a standard 2 second gap.

Thanks again for the help Velocity
So a CD's offset is basically a data shift distance that occurs between the data track and audio tracks, but not on data-only or audio-only CDs?

I see other PS sound tracks in the database so I figured out that question myself.

EDIT: A couple more questions- 
EAC shows irregular gaps (1.45, 2.43 etc) on the CD tracks;  is that normal?
Except for the last track (which gets a sync error) , I get no errors and identical CRCs on all the tracks from both dumps. Is there a way to manually dump the last track in ISO buster?

Thanks for the advice velocity, I'll go that way in the future
And thanks NvrBst for the PARs links, I'll go over them and see whats there

Yes, I think Nexy is correct. Because you get all 00s (no 'garbage data') when you go back 150 sectors in track2's 'sector view', you are likely dealing with a negative combined offset  for that game. It's probably a disk with -12 or -647 offset.

As far as I know, you can't accurately know a CD's offset if the 'combined offset' is negative (unless your drive supports the 'px_d8' program), and you can't dump audio tracks unless you know the CD's offset.

I kept having this problem with -12 and -647 disks (because my drive was only +6).  I finally bought a
LG Electronics - DVDRAM GH24NS50 drive off Amazon that is +667 and I haven't had that problem since.
The only downside to the GH24NS50 is that it doesn't support 'over-read' so I have to use a different drive to to make sure it doesn't cut any data off the end of the last audio track.

What is your drive's offset?

EAC's site mentions a firmware incomparability with some drives (toshiba) that can cause dump errors on different disks but always at the same locations. I know one of my problem drives doesn't report sync errors when it should (IE on last track when drive doesn't support overread). I'm going to see if I can find a different disk that also dumps incorrectly and check if the errors are happening at the same locations.