Search options (Page 3 of 4)

Time to bump this topic for a new discussion!

I noticed about a week ago that we have a few bad dumps in the database. I found these thanks to TheHustle. He had asked me how to dump one of them, but I found out they were not standard UMDs and they could not be dumped the usual way.

http://redump.org/disc/808/ [UCJB-98306]
http://redump.org/disc/1196/ [UCJB-98302]
http://redump.org/disc/1743/ [UCJB-98303]

These are demo discs with a game + video partition and the entire video section is corrupt in the dump I tested "UCJB-98302". I do not know which dumping tools were used to make these dumps, but I'm sure the video partition must be corrupted in all three dumps.

I bought one of the demo discs to try dumping this type of UMD myself, the demo disc I have is "UCJB-98306". My dump does not match the database, which is not surprising. I found a way to dump both partitions correctly, but they have to be dumped to separate .iso files.

Here are the instructions:
Note: UMD_DATA.BIN of each ISO has the partition number, 0001 & 0002.

There is currently no dumping tool that will dump both partitions at once, and I don't know if this is able to be done either. The dumps in the database were joined together to make the dump one file. I think merging the two ISOs is okay. There are very few game UMDs with two partitions, and we can include the non-merged hashes in the comments. The only issue with merging is that the video partition is unplayable after merging, but that may change in newer PSP CFW.

As a test, I also tried to dump Video UMDs using UMDKillerPRX V1.5, but only the 0002 partition will dump. PSP Filer 6.6 and UMDKiller V1.2 cannot be used on Video UMDs, so these UMDs will have to remain unsupported for now.

So how should we proceed? I think it would be safe to add the fixed dumps with the non-merged hashes in the comments.

The ISO 'Volume Space Size' is being logged incorrectly. My last post explains some issues with DVD dumping.

Thanks! I tested it and everything is working fine

I sent a message to iR0b0t about the redump .cue file issue.

I found some CCD file issues:

Here are the .ccd files: http://www.mediafire.com/?z3idm72x26751d8

That was the issue, thanks! The PerfectRip tracks now match EAC when using -98. I had to manually move the gaps to the correct position, though.

Here are a few drive issues to make note of:

PX-W1210TA/PX-W2410TA (Data-only CDs):
Sense data, Key:Asc:Ascq:05:64:00(ILLEGAL_REQUEST. ILLEGAL MODE FOR THIS TRACK)

PX-W1210TA/PX-W2410TA (CDs without CD-TEXT):
Sense data, Key:Asc:Ascq:05:24:00(ILLEGAL_REQUEST. INVALID FIELD IN CDB)
CDTEXT on SCSIOP_READ_TOC
    Undefined CDROM_READ_TOC_EX_FORMAT_CDTEXT on this drive

PX-W2410TA (CDs with CD-TEXT):
Doesn't dump tracks correctly. Bad TOC MSF for last audio track (PX-W1210TA also has this issue).

These are issues with discimagecreator:

Crashes after running these commands (Tested 32bit):
DiscImageCreator.exe -c D:
DiscImageCreator.exe -s D:

End line issue:
DiscImageCreator.exe -split foo.dec
DiscImageCreator BuildDate:[Jan 28 2013 23:59:57]
Start -> 2013-01-28(Mon) 14:40:03
Split File(num)  5/ 5End -> 2013-01-28(Mon) 14:40:57

ReadMe.txt issue:
PX-W2410TA(PX-W2410A)    1.04    +686 is right
+98 is right, but -686 is needed for PerfectRip

Could you also add this issue to the first post?:
Program does not keep periods in the file name (v1.1 gets named as v1)

Need overread sector is now set to 1 after updating the PX-W1210TA (1.10), but the PX-W2410TA (1.04) still has Need overread sector: 2, which is making the CD offset +590 instead of +2.

I am still getting this error with both drives:

SCSI bus status codes:02-CHECK_CONDITION [F:ReadTOCText][L: 1696]
Sense data, Key:Asc:Ascq:05:24:00(ILLEGAL_REQUEST. INVALID FIELD IN CDB)

You fixed the dumping problem The tracks now match PerfectRip's and the database. The log still has ISRC entries though. Here is a link with the subcode and log files: http://www.mediafire.com/?yvido8a9uc88ooq

All three issues are still present in this version, though I didn't expect them to be fixed yet.

1. I redumped the disc at speed 0 with the new version and it produced a cleaner sub file, but the issue still remains. The disc is very clean, but there is a tiny spot I see that could be causing the issue.

2. Both your program and PerfectRip have the file name issue. I don't think there is any setting I can change to fix this. Other programs I use don't have this issue.

3. Take a look below to see the problem I'm talking about. The first 3 bytes are the issue.

Hi sarami, I've got a few issues to report.

1. I was verifying this disc with your program and tracks 12 & 13 don't match the database. I dumped it using two different drives and got the same results. However, when I dump it with PerfectRip or EAC my results match the database. The pregap seems to be detected differently, which is causing it to not match. Here is a link with the log files and subcode file: Toushinden (Japan) (v1.1)

2. As you can see from my files, the program does not keep periods in the file name (v1.1 gets named as v1). Is this an easy problem to fix or not fixable?

3. The last issue is with .ccd and .cue file output. Can you make the program not add a byte order mark at the start of the file? This makes the .cue files not match the database, and having a BOM makes .ccd files and .cue files unusable in a lot of software.

I hope you can fix these issues in a future version

iR0b0t, please move my Plextor PX-708A entry to the supported drives list. I tested it some more and got it to work repeatedly. I also retested my ASUS and got it to work a little bit, but now I can't get it to work again.

PS: Just a note for anyone dumping GD-ROMs. Make sure you dump the disc at least twice for new dumps and don't rely on the ice output to tell you if something is bad. For one verification I did the first time I dumped the disc it didn't match but ice didn't report any errors. The disc is a little bit scratched, so I had to use DCdumper to dump it successfully.