Logs, please.
of course:
https://mega.nz/file/Hs0hATjT#ceHRfZie8 … F3eymAvxW4
or the disc txt attached
You are not logged in. Please login or register.
Redump Forum → General discussion → DiscImageCreator
Logs, please.
of course:
https://mega.nz/file/Hs0hATjT#ceHRfZie8 … F3eymAvxW4
or the disc txt attached
I have a CD-rom with audio tracks (enhanced CD) that will dump completely then have an error at the end "Internal error. Failed to analyze the subchannel. Track[06]/[07]"
Logs:
current test build: https://drive.google.com/file/d/1wQxo9- … sp=sharing
older stable: https://drive.google.com/file/d/1Zp-FOJ … sp=sharing
of course:
The mode of track 1 on cuesheet is corrupt.
Try again whether it's fixed and upload logs http://www.mediafire.com/file/eq80y20l9 … st.7z/file
I have a CD-rom with audio tracks (enhanced CD) that will dump completely then have an error at the end. Something about subchannels, not completely sure what it says since the command line window closes immediately.
Yes, subchannel is weird.
LBA[303688, 0x4a248]: P[00], Q[0105010328060067311387e5]{Audio, 2ch, Copy NG, Pre-emphasis No, Track[05], Idx[01], RMSF[03:28:06], AMSF[67:31:13]}, RtoW[0, 0, 0, 0]
LBA[303689, 0x4a249]: P[00], Q[012501a4280800673114431d]{Audio, 2ch, Copy NG, Pre-emphasis No, Track[25], Idx[01], RMSF[a4:28:08], AMSF[67:31:14]}, RtoW[0, 0, 0, 0]
etc.
But there is no error on subError.txt. I don't know why now...
Let me know if there is anything I can do to fix. Very rare disc.
----
Another is an unlicensed Sega CD (Good Deal Games) https://drive.google.com/file/d/1-T62cg … sp=sharing
Subindexes are different bins for audio tracks. Fireball asked for you to have a look please.
The mode of track 1 on cuesheet is corrupt.
Try again whether it's fixed and upload logs http://www.mediafire.com/file/eq80y20l9 … st.7z/file
wow, how did i miss that. well spotted.
new logs: https://mega.nz/file/ehshhbSD#zWkDmDpVs … WIHm_0DvRw
wow, how did i miss that. well spotted.
It seems good, thanks.
========== OpCode[0xd8]: SubCode[0]: Check Drive + CD offset ==========
========== Offset (Drive offset referes to http://www.accuraterip.com) ==========
Combined Offset(Byte) 14552, (Samples) 3638
- Drive Offset(Byte) 392, (Samples) 98
----------------------------------------------
CD Offset(Byte) 14160, (Samples) 3540
Overread sector: 7
There is a different combined offset
========== Offset (Drive offset referes to http://www.accuraterip.com) ==========
Combined Offset(Byte) 15000, (Samples) 3750
- Drive Offset(Byte) 392, (Samples) 98
----------------------------------------------
CD Offset(Byte) 14608, (Samples) 3652
Overread sector: 7
Another is an unlicensed Sega CD
Due to many duplicate MSF on sub (LBA 134, 203 etc.), subQ is fixed per a sector.
I don't know such MSF is really correct.
If clonecd sub has also duplicate MSF, I can ignore it by new flag.
Smurfs CloneCD subs: https://drive.google.com/file/d/1TJPRji … sp=sharing
Thank you
Smurfs CloneCD subs
There is no duplicate MSF... So, 0xd8 specific problem? If yes, I can't fix it. Try to dump other plextor if you have.
This is known for Good Deal Gaming releases. Which is more accurate for audio tracks? Regular dat or Subindexes dat?
Having trouble with dumping a new revision of xbox game "Marvel Nemesis: Rise of the Imperfects". Logs are enclosed.
fails with
[F:ReadXBOXDirectoryRecord][L:1129] GetLastError: 87, The parameter is incorrect.
could you check http://forum.redump.org/topic/30953/ss- … orrection/ ?
I have 1 ecc/edc error on the data track (and no c2 error) when dumped with 4012, but not with 716a.
Logs for the 716a: GEX_US_716-logs.rar => 2 dumps
Logs for the 4012: GEX_US-logs.rar + GEX_US_4012BIS-logs.rar => 3 dumps with always the same error and the same crc (so the drive always read the same data)
Logs for the 4012 with latest DIC test built: GEX_US_DICtest20200825-logs.rar => same result
(link to logs on my sig)
Could this be a problem of the 4012 drive (firmware), DIC, disc ? Anything else ?
What do you think ?
I have several factory-pressed CDs which are PC single-track data discs with no protection. They are already in Redump database and I would like to submit the dumps for verification.
However, my drive can't pass lead-out check in DIC, so I can't generate anything. But if I dump them as raw BIN/CUE using IsoBuster, .BIN gives perfect CRC32/MD5/SHA1 checksums.
Is there any other way I can submit these for verification? Is there a switch for DIC which can by-pass this check?
The discs in question are:
http://redump.org/disc/71165/
http://redump.org/disc/71164/
http://redump.org/disc/70428/
http://redump.org/disc/70429/
These are all late re-issues which are out of print and not so common in second-hand market, they probably won't get verified anytime soon.
Having trouble with dumping a new revision of xbox game
Use the latest version.
What do you think ?
716 is good, not 4012.
Is there any other way I can submit these for verification
R00n5t3r wrote:Having trouble with dumping a new revision of xbox game
Use the latest version.
That sorted it. I'll submit new dump info shortly
Madroms wrote:What do you think ?
716 is good, not 4012.
Ok, so I made more tests, all with the 4012 ODD. Here are the results:
- DIC: bad dump
- latest test DIC: bad dump
- Isobuster: good dump
- T...: good dump
- CD Manipulator: good dump
So DIC problem with 4012 ODD maybe ?
Difference could be seen in the picture attached: part of the EDC/ECC field of sector 97747, total of 96 bytes.
Do you need any other logs ?
Do you need any other logs ?
Try to use cdtoimg.exe http://www.mediafire.com/file/9b31r4fv44eut36/file
This is a simple 0xd8 dumping tool. You can compare the scm of DIC and cdtoimg. (It needs to be careful not to fix the offset.)
Madroms wrote:Do you need any other logs ?
Try to use cdtoimg.exe http://www.mediafire.com/file/9b31r4fv44eut36/file
This is a simple 0xd8 dumping tool. You can compare the scm of DIC and cdtoimg. (It needs to be careful not to fix the offset.)
Here are 3 pictures attached to compare .scm by DIC with 4012, with 716 and cdtoimg (with offset = Combined Offset: 6464 bytes, 1616 samples):
- DIC4012vsDIC716.PNG: DIC716 is good, DIC4012 is bad => diff of 96 bytes
- DIC4012vsCDTOIMG.PNG: cdtoimg is good, DIC4012 is bad => diff of 96 bytes
- DIC716vsCDTOIMG.PNG: cdtoimg is good, DIC716 is good => no difference
=> so cdtoimg with 4012 ODD is good and is the same as DIC dump with 716 ODD. And DIC dump with 4012 ODD is bad.
Do you need anything else ?
Do you need anything else ?
Try to dump the disc without /c2.
Madroms wrote:Do you need anything else ?
Try to dump the disc without /c2.
4 more logs available.
With 716a: no problem, no error, good dump
With 4012 and DIC: sector 97747 without error, but a lot of new errors (697) on other sectors (MSF, ECC/EDC, sync). How is it possible when with c2 param there is no error on any of these sectors ?
With 4012 and DIC test (2 dumps made): sector 97747 without error, but a lot of new errors (677, so 20 less than with DIC official release) on other sectors (MSF, ECC/EDC, sync).
but a lot of new errors (697) on other sectors (MSF, ECC/EDC, sync).
This is well known problem. (Main channel is shifted unexpectedly)
In many cases, this is a drive problem. Try to use /f. Or changed the drive speed. (But I'm not sure whether the problem is avoided.)
Hi, I have four discs that has issues with DIC.
First disc (see: WINDOWS_MME_LOG.7z) gives me this GetLastError error, prompting on dumping the disc with "Subcode: 2", resulting in the dumping process being very slow. Another disc from Fujitsu (see: F-BASIC 386 V1.1_logs) have the same problem.
Second disc (see: WIN32_DOS622_OEM_logs) got stuck on "Checking EXE: 24" and refuse to move on, even if I remove the /sf flag;
There are a few very abnormal things in the logs:
QBASIC.EXE: offset is very big (1092628067). read skip [TODO]
SCANDISK.EXE: offset is very big (1092628067). read skip [TODO]
SETUP.EXE: offset is very big (1092628067). read skip [TODO]
UNDELETE.EXE: offset is very big (1092628067). read skip [TODO]
Are these MS-DOS files causing the EXE checking process to stall?
Third disc (see: PAYUTA_FRE_logs.7z) quit dumping after detecting a protected file ".Process$".
Could you look into the issues?
Thank you very much!
Madroms wrote:but a lot of new errors (697) on other sectors (MSF, ECC/EDC, sync).
This is well known problem. (Main channel is shifted unexpectedly)
In many cases, this is a drive problem. Try to use /f. Or changed the drive speed. (But I'm not sure whether the problem is avoided.)
With /f: a lot less errors (without c2 param) but still 2 MSF and 7 ECC/EDC errors (no error on sector 97747): GEX_US_4012_NO_C2_F-logs.rar
And it is very slow.
The speed param does not work correctly with 4012: 8, 16 and 40 gave the same time dumping a cd. (log attached for the speed 40 and c2 param, just in case).
For this disc, it is always about 12-13 minutes to run DIC (118650 sectors), so about x2 (?) speed.
I have four discs that has issues with DIC.
When searching offset with 0xd8 08, hardware error occurs in your drive. Please try to dump by the other drive if you have.
Second disc (see: WIN32_DOS622_OEM_logs) got stuck on "Checking EXE: 24" and refuse to move on, even if I remove the /sf flag;
/ns also checks it.
Third disc (see: PAYUTA_FRE_logs.7z) quit dumping after detecting a protected file ".Process$".
It's escaped.
http://www.mediafire.com/file/eq80y20l9 … st.7z/file
Latest dump for my GEX US on 4012a: GEX_US_4012_F-logs.rar
so with c2 and f params: no error on sector 97747, but 2 bad MSF and sector 98215 with ECC/EDC error.
I also added the T... logs in case you need them.
So I try to sum this up (for other users):
DIC + my 4012 ODD with [SS] GEX US disc:
- with c2 param: no c2 error reported but 1 sector (97747) with EDC/ECC error => bad dump
- with c2 param + f param: no c2 error reported, sector 97747 is good but 1 sector (98215) with EDC/ECC error and 2 MSF errors => bad dump
- with no c2 param: sector 97747 is good but a lot of errors: 697 MSF errors, 7 ECC/EDC errors, 60 invalid sync => bad dump
- with no c2 param + with f param: sector 97747 is good but 2 MSF errors + 7 ECC/EDC errors => bad dump
- same results with latest DIC test
[why the sector 97747 is bad with c2 param, but good without it ? Something I don't understand myself]
DIC + my 716a ODD with [SS] GEX US disc:
- with c2 param: no error => good dump
- without c2 param: no error => good dump
DIC + my 4012 ODD: Speed param does not work correctly: it always dump at 2x
Other tools + my 4012 ODD with [SS] GEX US disc:
- T...: good dump
- cdtoimg: good dump (scrambled, no offset correction)
- Isobuster: good dump
- CD Manipulator: good dump
So at the moment, dumping with DIC on 4012 ODD is not 100% accurate as there could be errors not identified correctly.
For example, I think about PSX games where ECC/EDC errors could be normal, but, as seen with my GEX US [SS] disc, these errors could also be due to a problem with DIC+4012.
On the opposite, a game with intended errors could be dumped without error reported but DIC on 4012 ODD, whereas it must have errors.
=> with this setup (DIC+4012 ODD), you could have:
Games without intended error dumped with errors (no c2 error, but errors in MSF, ECC/EDC, etc.)
Or games with intended errors dumped without error.
How to avoid these problems with 4012 ODD ?
As other dumpers stated the 4012 ODD is the best Plextor drive to dump CDs, how could we help to improve the use of DIC with such ODD ?
Or any other users with [SS] GEX US disc and 4012 ODD ? To confirm the problem (or not).
[FYI, I also identified a bug with 755 ODD some months ago, when dumping 2 3DO games, Killing Time and Icebreaker 2 if I remember correctly].
Redump Forum → General discussion → DiscImageCreator
Powered by PunBB 1.4.4, supported by Informer Technologies, Inc.
Currently installed 6 official extensions. Copyright © 2003–2009 PunBB.