Yes, read the topic in the Dumpers forum. All Xbox/360 dumps are missing the L1 video partition. The database must be fixed in order to accept new dumps. Please wait .
Re: [REDUMP_NEEDED][XBOX360] Warhammer 40.000: Space Marine (World) XGD3 (6 replies, posted in Dumps)
I have already confirmed it is Q using a microscope a while ago. A microscope is too powerful for some PS3 discs, though, so you have to use a magnifying glass instead. I can see the Q's tail with just my eyes on most PS2/3 discs, so a scope isn't necessary.
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.
but -686 is needed for PerfectRip
Why is needed for PerfectRip?
I think it is probably a drive firmware issue causing this to happen. I tested CDs with CD-TEXT and without CD-TEXT, both need -686 in PerfectRip. EAC needs +98 for both. Hopefully you can find the cause when you get the drive.
Program does not keep periods in the file name (v1.1 gets named as v1)
Determined that the period since the last extension.
So, please specify an extension.
This issue is Windows OS specification.
That explains it. I wasn't adding an extension since it's usually added automatically. Can you make the program ignore extensions?
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
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)
Please tell me px_d8 log & dump data to cdtoimg (about sector 1-5) your PX-W1210TA (1.10) & PX-W2410TA (1.04)
Here is the px_d8 log and cdtoimg data: http://www.mediafire.com/?0yya05nd27pz842
The PX-W2410TA is the only drive still detecting the wrong CD offset, the PX-W1210TA is correct with the 1.10 firmware.
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)
If you use Windows7, check off below
explorer -> tool(T) -> folder option(O) -> show tab 'Do not show extensions that are registered'
Hiding or showing file extensions doesn't fix the issue.
Now I've got another bug to report. I noticed that the combined offset is detected incorrectly for these two Plextor drives: PX-W1210TA, PX-W2410TA
The combined offset is detected as +588 samples too big, but the disc still dumps correctly, just the CD offset is listed wrong. I noticed this in the log: Need overread sector: 2
This is set to 1 for my working Plextors, and it looks like it needs to be set to 1 for these two drives as well.
Here is a log file: http://www.mediafire.com/?5y8kdp4q42t27rj
The following errors appear before the dumping starts with both of these drives:
PX-W1210TA SCSI bus status codes:02-CHECK_CONDITION [F:ReadConfiguration][L:1089] Sense data, Key:Asc:Ascq: 05:20:00(ILLEGAL_REQUEST. INVALID COMMAND OPERATION CO DE) PX-W2410TA 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) Can't get CDROM_TOC_CD_TEXT_DATA
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
Could you upload a 32-bit version? I can't test 64-bit programs.
upload version 20121228.
All three issues are still present in this version, though I didn't expect them to be fixed yet.
For the present, cleaning your pickup lens of drive & disc.
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.
This file is created by perfectrip? If so, please look at the setting for your PC.
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.
EF BB BF 5B 43 6C 6F 6E 65 43 44 5D 0D 0A 56 65 ï»¿[CloneCD]..Ve
EF BB BF 46 49 4C 45 20 22 54 6F 75 73 68 69 6E ï»¿FILE "Toushin
I'm still on old 32-bit, but that would be nice for many others I'm sure. This program would be a good addition to the dumping guides, once all of the issues are fixed.
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
It's exactly the same as the Xbox 1 dumping method, so you can just follow that guide's instructions. Just make sure you don't calculate the SS.bin CRC32 until after you pass it to ss_sector_range.exe. The SS gets fixed by the program, which is necessary in order to match others' SS CRCs, but usually the SS is different for most dumps. Xbox 1 SS doesn't need fixing so you can calculate the CRC any time.
There are also a couple other steps for 360 games, but they are simple.
- Open DMI.bin and copy the string from offset 0x40-4C (13 bytes). Post this in the comments section. It contains the serial, version, and region.
- Open Track 01.iso in IsoBuster and copy the Primary Volume Descriptor:
Sector 16: 0320 - 0370. Post this in the PVD section.
To answer your question about the dumping method, it's true our .iso dumps don't contain the security info, but you can inject it later with Xbox Backup Creator using the DMI, PFI, and SS files that you dump.
I can confirm it for USA and Japan, but I think it's very likely that Europe is the same because there are some Europe dumps with the code on the label side.
I've noticed that all of the recent PS3 dumps keep getting the mould code/text added to the data side field. This is incorrect. All PS3 games only have one mould code/text and it is always on the label side. I hope this can be fixed so that we don't have a database full of inaccurate information.
Here are some examples of different region mould codes/text:
Europe: IFPI 94xx
USA: IFPI QWxx
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.
Well, not all BD drives will work. I think ASUS, Lite-On, and Samsung drives should work since others have dumped successfully with these brands. My drive is a Lite-On iHBS112 2 and it works, but dumping is pretty slow. If you do get a working drive, make your first dump a verification because some drives may overdump the discs.
Nothing has changed with regards to dumping. Use a BD drive and IsoBuster or ImgBurn to dump the discs. The PS3 section is accessible to dumpers only, and there are still not any guides for dumping the discs. The dat file has the same checksums as always (encrypted dumps).
I didn't know about mislabeled licensed discs. My unlicensed discs don't have the logos. Identifying by ringcodes is good, but most members don't know how to do that, which brings up another guide issue that I'll explain below.
It'd be nice if we had a ringcode guide on the site. There are a lot of new and old members that don't know they are supposed to provide the codes with their dumps. Having a guide would eliminate the confusion, since the current guides only cover dumping and they don't even mention ringcodes. There have been some helpful posts by members in the dumps forum recently. Maybe their posts could be the basis for a guide on ringcodes.
I was already using the intelligent bad sector scanner with the SafeDisc profile.
Dumping as audio with the audio trap disc didn't get any farther than dumping as normal.
I agree with iR0b0t. Those rings look like physical gaps in the discs, which is causing the dumping problems. Even the blue disc has a ring, which is probably why they all stop at 6%.
Here's some info about the discs if anyone wanted to know:
CD discs: 318933 sectors, has data from SLUS-20202 (Crazy Taxi)
DVD discs: 2282416 sectors, has data from SLUS-20071 (DOA2: Hardcore)
I gave up on the error skipping methods. They take too long and it usually gives me a different unreadable sector each time I try to copy. I was hoping that there would be an easy method to copy these discs, but I'm not too concerned about them, I was just curious if they could be dumped.
EDIT: I tried your IsoBuster method and it didn't work, the program just locked up with two different drives. I've already tried the CloneCD method, so it looks like these discs are copy-proof. It'd be nice if there were a program to run on the PS2 itself that could dump discs, that might be the only way.
Re: [Discussion] XBOX 1 / 360 dumping instructions (11 replies, posted in General discussion)
Yes, these drives can dump GD-ROM discs, but I haven't had very good results with my drive. Most of my discs won't dump because of very minor scratches, which makes me think it's not the best for these discs, but it does dump Xbox/360 discs, which is mainly what I wanted.
The SH and TS drives use the same Kreon firmware, but each letter revision of the drives uses a different Kreon firmware. When flashing the TS drives you have to run the command "sfdnwin.exe -nocheck" and then select the Kreon firmware, you have to do this because the flasher only wants to flash SH drives by default.
pablogm123 is correct that the TS-Hxxxx are OEM drives, mine is a Dell. So you could also search for HP or Dell to find the TS drives. The TS drives are usually cheaper, mine was $13 new. Just make sure you don't get the C version of the SH-D163/TS-H353, it's not Kreon compatible.
I mentioned some Kreon compatible drives in the Dreamcast thread, but I'll list all of them here for quick reference. You can search for either Samsung, Toshiba, or TSSTcorp to find these drives.
IDE drives: SD-M2012C, SH-D162C, SH-D162D, TS-H352C, TS-H352D
SATA drives: SH-D163A, SH-D163B, TS-H353A, TS-H353B