Search options (Page 2 of 3)

Argh, I forgot. This forum truncates 7z files.
Mediafire: http://www.mediafire.com/?4ugyum5wnzl

What's weird is that my Mitsumi FX54++M also sync errors.

Yes. If you have a combined negative offset, dump the first audio track in ISOBuster.

For two track games, push the end address bubble and subtract the length of the pregap from the start address (150 for two seconds, for instance.) For multi-track games with identical gap lengths, do the same without hitting the end address bubble. For games with differing gap lengths, check the end address bubble, then subtract track 2's pregap length from the start address, and track 3's pregap length from the end address.

Use the following commands on the resulting ISOBuster BIN file, where the number is (offset*-4). For -617 combined, this would be:
psxt001z.exe --gen offsetfix.bin 2468
copy /b offsetfix.bin+ISOB_T2.bin ISOB_T2Good.bin
FPCopy64 -r "ISOB_T2Good.bin" -2468

------

I've also had a couple situations where EAC would give a sync error on a flawless disc (My GH20NS15 fares fine, but my PX-760A and FX54++M don't like these weird discs). PerfectRip does well here, but for those where this is not an option, you might also have the need to manually extract a track on a disc with a positive combined offset.

The method is a little different. Before you touch anything in the extract from-to dialog, if the combined offset is >+587, you need to divide it by 588 and add that to the start address (while the length bubble is still ticked). After you've done that, set the dialog options as you would with a negative offset disc. After that, add +1 to the start address (and the end address field if that is checked). If you had a large negative offset, pretend the resulting bin file has an offset of the remainder. For instance, my GH20NS15 is +667, so with a +2 disc (+669 combined) I would add 1 to the start address and pretend herein that the offset is +81.

Once you have your dump (with real or pretend offset), we have to get rid of that extra sector we added. This is different from a negative offset, since we have to delete data from the beginning and end of the file. You fire up a hex editor, delete offset*4 bytes from the beginning, and 2352 - (offset*4) bytes from the end. On my GH20NS15, this would mean 324 bytes from the beginning and 2028 bytes from the end.

I have no idea why EAC does that on specific discs in specific drives, but every time I've manually extracted the tracks, they match EAC on the GH20NS15 and PerfectRip on the Plextor.

I have the same problem, goes straight to crash after launching the EXE on Win7 X64. Works perfect in XP compatibility mode, though.

Crash log:

Protection ID v0.6.3.5 DECEMBER has crashed...
Build 12/24/09-20:33:24

Welcome to the scene of the crash.... take me to the hospital

EAX = 000000030h, EBX = 00000000Ah, ECX = 000000030h, EDX = 000000000h
ESI = 0004F3240h, EDI = 000000031h, ESP = 00028CF50h, EBP = 00028CF98h

DS  = 0002Bh, ES  = 0002Bh, FS  = 00053h, GS  = 0002Bh, SS  = 0002Bh
DR0 = 000000000h, DR1 = 000000000h, DR2 = 000000000h, DR3 = 000000000h
DR6 = 000000000h, DR7 = 000000000h

CCW = 00000037Fh, CSW = 000004020h, CTW = 00000FFFFh, CEO = 076CC7C3Ch
CES = 002E90023h, CDO = 000000000h, CDS = 00000002Bh, CR0NPX = 000DB223Fh

Crash @ CS:EIP -> 00023h:077219D60h, EFlags : 000010206h
Stack @ SS:ESP -> 0002Bh:00028CF50h

Crash Code : 0C0000005h
Crash Report : In Page Error

ThreadID : 0109Ch / 04252
ThreadName : PiD Core Thread (thread 1)
Crash Happened in Scan File -> Unknown :(
Procedure Name : N/A
Crash File Line Range (low) -> 00
Crash File Line Range (high) -> 00
ProtectionID was scanning -> 
Last Scan was -> Crash did NOT happen in scan thread
Scan was N/A 
Next Scan is -> Crash did NOT happen in scan thread

Thread Start Va / Tag : 0x00408FFD

Pid executable range 0x00400000 -> 0x00574000 (0x00174000 bytes)

Crash address is NOT within pid's image

Yeah, on negative combined offsets, EAC cuts off data from the beginning of track 2.

In order to combat that, you can dump the track manually in ISOBuster.

For this game specifically, in ISOBuster, right-click extract from-to the 2nd track. First, click the End Address bubble, then subtract 150 from the start LBA. Extract.

Open the resulting file in a hex editor. Insert 2,468 (617*4) bytes of 00 at the beginning, and delete 2,468 bytes from the end.

If you're uncomfortable with hex editors, you can instead:
psxt001z.exe --gen offsetfix.bin 2468
copy /b offsetfix.bin+track02.bin track02good.bin
FPCopy64 -r "track02good.bin" -2468

For other games, there's a couple of precautions to take. Firstly, always calculate the correct number of bytes to shift with offset * 4. The second, and most important, is that if the game has >2 tracks, you have to delete track 3's pregap from the end of the file in addition to some bytes.

The only other precaution I can think of is that ISOBuster will not have error recovery as good as EAC, so if you're going to use this method for a new entry, be sure to dump it a couple of times (preferably in a couple of drives, too).

Well, I looked at the sample Playstation XML dat, and it didn't even use the index and image fields, so neither did I. There was also spaces between some blank fields, so I recreated those too.

Anyways, I threw together this crappy program in VB (I'm more of a scripting guy, myself). You'll probably need the .NET framework if you don't have it.

Just rename the redump.org dat to "RD.dat", and throw it in the same folder as the program. Run it, and it'll create "NEW.DAT".

If you give me an example of a complete redumb db entry from the dat, and how you want that resulting entry to be formatted, I will look into throwing something together that can do it for you.

For example, here's Tekken 2 (USA) for the PlayStation:

    <game name="Tekken 2 (USA)">
        <description>Tekken 2 (USA)</description>
        <rom name="Tekken 2 (USA).cue" size="306" crc="7b45c1a8" md5="b28b88a353507118f1586d71eef1b7c0" sha1="73b58d9c70c59f0f2a6b19ad9d04e9a61f820256"/>
        <rom name="Tekken 2 (USA) (Track 1).bin" size="717922128" crc="7ab1c17b" md5="b2ce9448df23b0378f7bf5cce901eecc" sha1="2b6a371fc70c2e625f238ef98104ad1d2a07a5bc"/>
        <rom name="Tekken 2 (USA) (Track 2).bin" size="26554080" crc="9a0d6a04" md5="9f64359d59fa921a68dea3300bd54ac2" sha1="5faad8d827cc9390dc097e75822e23c2f4953364"/>
        <rom name="Tekken 2 (USA) (Track 3).bin" size="6350400" crc="d387cac5" md5="131bb82eb1ba56b4991091f1717770a2" sha1="47eb5ef6093e80099f710b7e221b461ca3ab3c26"/>
    </game>

What do you want the result to look like?

1. Check "Add MD5"
2. Check "Add SHA1"
3. Click "...", and select the folder containing your BIN files.
4. Click "...", and select the location and name to save your dat file as.
5. Set the DAT format to Deprecated. (This isn't needed anymore, but I prefer the old format to XML.)
6. Create your dat.

You'll get a DAT file like this:

clrmamepro (
    name "-insert name-"
    description "-insert description-"
    category "Standard DatFile"
    version "-insert version-"
    date "-insert date-"
    author "-insert author-"
    email "-insert email-"
    homepage "-insert homepage-"
    url "-insert url-"
    comment "-insert comment-"
)

game (
    name "playstation magazine 33"
    description "playstation magazine 33"
    rom ( name track01.bin size 330630048 crc 1d6bdd87 md5 cc86a82c37c269d209a8fe678a21902e sha1 524adff5b635c295478ef2844098f4745a93f29e )
    rom ( name track02.bin size 18592560 crc 65ba643b md5 4133f6ac99a044bf43ca7ddcdf3aa3e0 sha1 44c31aaacec46587dd7ab5e46aa365fdfc79bb92 )
    rom ( name track03.bin size 18841872 crc 9ebedee7 md5 bf8f384c34c7e264921a609ba3e8132c sha1 9a5674526def6d2097bc541bc51d5ad875ac2bdc )
    rom ( name track04.bin size 35103600 crc acbd2e8a md5 1166e5026f0a5f8cdb3bbf89fb5e780b sha1 5ded4fd4e5df366a4a68a6692d326eda6e48fad9 )
    rom ( name track05.bin size 1401792 crc 780b1fc7 md5 54734d3fe6f75e0d6cf73fa0d3b63c83 sha1 d11089e8cd3f7d9fc4dfd1156e1a02f2f992897a )
)

Cut out the following portion to paste into the disc submission form:

    rom ( name track01.bin size 330630048 crc 1d6bdd87 md5 cc86a82c37c269d209a8fe678a21902e sha1 524adff5b635c295478ef2844098f4745a93f29e )
    rom ( name track02.bin size 18592560 crc 65ba643b md5 4133f6ac99a044bf43ca7ddcdf3aa3e0 sha1 44c31aaacec46587dd7ab5e46aa365fdfc79bb92 )
    rom ( name track03.bin size 18841872 crc 9ebedee7 md5 bf8f384c34c7e264921a609ba3e8132c sha1 9a5674526def6d2097bc541bc51d5ad875ac2bdc )
    rom ( name track04.bin size 35103600 crc acbd2e8a md5 1166e5026f0a5f8cdb3bbf89fb5e780b sha1 5ded4fd4e5df366a4a68a6692d326eda6e48fad9 )
    rom ( name track05.bin size 1401792 crc 780b1fc7 md5 54734d3fe6f75e0d6cf73fa0d3b63c83 sha1 d11089e8cd3f7d9fc4dfd1156e1a02f2f992897a )

You'd open Track 2 in the hex editor, but you don't have to do this if you're uncomfortable with it.

In EAC, don't detect gaps, instead leave them undetected. Enter the offset in the drive options as you would normally, and dump the track with test & copy. This will give you track 2 without its pregap.

Use psxt001z.exe to generate your pregap using: psxt001z.exe --gen pregap.bin 352800

Use the command prompt to merge the files, like: copy /b pregap.bin+track02.bin track02good.bin

That will give you your track 2 with a 2 second pregap.

Have ISOBuster make a cuesheet for you, or you can just use this cuesheet for PSX:

FILE "Track01.bin" BINARY
  TRACK 01 MODE2/2352
    INDEX 01 00:00:00

Unfortunately, -647 is a fairly common offset for PlayStation games. It would be unsafe to assume an offset we can't see, though.

PC recycling stores are good places to look for cheap drives, if you have any around you. I have a few around my city, and they always have stacks of CD-ROM drives on the cheap ($1 for me). Just bring a Smartphone/PocketPC/NDS/PSP/etc with the Accuraterip list with you and look for a drive with a huge offset. I found an "HP - CD-Writer+ 8100" with an offset of +1160, for instance.

On eBay you can get a IDE/SATA to USB kit for about $7 (China), if you don't want some ugly old drive in your tower.

Or you can always pick yourself up a Plextor, which will automatically detect offsets for you with px_d8. You can grab a PX-760A on eBay for ~$30 shipped with some luck.

I wonder if Brasso will work as a replacement solution for the aluminum oxide paste that comes with the Memorex OptiFix. It's just a little machine with motorized scrubbers that spin in a radial motion. Theoretically, that could turn all the hard work into pressing a button.

Spot on with the math.

You should put a value of 8 in EAC for the offset correction value.

+2 is the offset of the disc itself (this is a very common value). We also have to account for the offset of the drive, so we add the two together to get the "combined offset".

Let's pretend you had a drive with a negative offset, like -444. We wouldn't see garbage data in this drive, but if we figure out the combined offset with our disc offset (-444 + 2), we would know to use -442. Likewise, if you had a +667 drive, you could find large negative offsets, and figure out what to use in your SH-S223L by adding 6.

[It should be noted that combined negative offsets can give bad results in EAC, so in that case you will want to dump manually or use a tool like PerfectRip (tutorial)]

No garbage data means that the combined offset is <=0, which means you can't determine it with that drive, and can't dump the disc without already knowing it. If you have a drive with a large positive offset (or a Plextor compatible with px_d8) you can find out the disc's offset, then figure out the right combined offset by combining the disc and drive offset.

Having only two lines of garbage is okay. What's your drive's offset according to the Accuraterip database?

According to the previous dumper, the offset for Lunar is -647. This means you can't manually detect it in a large number of drives. A large number of LG drives have +667, but if you're going to look into new drives, you might want to think about getting a Plextor (you can get them fairly cheap on eBay).