You are not logged in. Please login or register.
Redump Forum → Posts by sarami
> HARRY_POTTER_POL
It seems no problem.
> HPPoA
There are non-intentional c2 errors (bad dump).
Anyway, redump.org does not accept your drive.
VendorId: Optiarc
ProductId: CD-RW CRX880A
ProductRevisionLevel: KX07
VendorSpecific: Nov10,2006 ASUS BW-16D1HT
90DD0200-B28000
Manufactured April 2021
Firmware v3.02
Tell me the drive name and firmware before a flash, plz.
I’ve run it 30 times so far,
Thanks. If data-shifted is really random, it will occur someday... btw, what drive and os do you use? Jackal reported that it occurred by ASUS (What ASUS?) and linux (What distribution?) http://forum.redump.org/post/93955/#p93955
I do not know how to check if something is compressed with UPX or not. ?
SETUP.EXE
UPX is https://upx.github.io/
I've attached logs for the unsuccessful dump on 0601.
========== IMAGE_SECTION_HEADER (40 bytes) ==========
Name: UPX1
VirtualSize: 0002e000
VirtualAddress: 0005b000
SizeOfRawData: 0002e000
PointerToRawData: 00000400
PointerToRelocations: 00000000
PointerToLinenumbers: 00000000
NumberOfRelocations: 0000
NumberOfLinenumbers: 0000
Characteristics: e0000040
=> contains initialized data
=> can be executed as code
=> can be read
=> can be written to
========== IMAGE_SECTION_HEADER (40 bytes) ==========
Name: .rsrc
VirtualSize: 00002000
VirtualAddress: 00089000
SizeOfRawData: 00002000
PointerToRawData: 0002e400
PointerToRelocations: 00000000
PointerToLinenumbers: 00000000
NumberOfRelocations: 0000
NumberOfLinenumbers: 0000
Characteristics: c0000040
=> contains initialized data
=> can be read
=> can be written to
========== IMAGE_EXPORT_DIRECTORY ==========
Characteristics: 2c10227c
TimeDateStamp: 284ef6b9 (1991-06-07T03:00:09)
MajorVersion: 197f
MinorVersion: 03b2
Name: dae40257 ("UPX" is shown in IMAGE_SECTION_HEADER of SETUP.EXE. Please check if it is compressed by UPX or not.
If yes, DIC is not supported it yet. 20210401 version does not output IMAGE_EXPORT_DIRECTORY yet.
it says "Cache is short. Retry 45/50" and at the end fails.
Change the retry count -> /mr 100 or /mr 150 or more
I cannot get the link to your "PS3Auth" from your signature to work for me:
It needs a login.
I guess yours do the same anyway...
Yes.
on Nintendo discs. Unfortunately, even on PC drives that works for getting the "Manufacturer", I cannot get the BCA on any disc. So, it's still open question, if there is PC drive that can read the BCA...
Perhaps it's the same as PS3 compatible drive cannot get data1/data2. If we get BCA on PC, we need to get Wii optical drive emulator like 3k3yRipper of PS3.
@bikerspade
If you have time, continue to dump your +1176 disc by ASUS until the hash unmatches, and upload the unmatched logs, plz.
Here is what I get using latest test DIC. Trying to grab TOC/pre-gap with this troublesome CD
a little off-topic, but i want to ask just out of curiosity, what is the exact difference between 0xd8 used by DiscImageCreator and other special Plextor read commands: 28h, A8h, D4h and D5h?
28h, A8h are general commands. See https://en.wikipedia.org/wiki/SCSI_command
D4h, D5h are old NEC drive commands, AFAIR.
Today, I found Yamaha CDR200t drive in my storage, it supports 0xd8 reading.
I know some 90's drives of sony, pioneer, etc also support it.
[EDIT3] It reads the LeadOut and considering the offset is positive, then if the above DiscImageCreator error is fixable, then I guess it will be able to make proper dumps.
Please try to use cdtoimg_d8 https://www.mediafire.com/file/9b31r4fv … g.rar/file
RibShark wrote:found a single drive that could get this data
very curious which is that single drive that can read the BCA on Nintendo discs, because I very recently had issue exactly with that:
My source code is probably wrong. Normal DVD needs 0xAD opcode and 0x03 format code for getting BCA data. But Nintendo discs return there is no BCA data. Perhaps, BCA data of the Nintendo disc is stored in another place?
Cleanrip code
void dvd_read_bca(void* dst)
{
dvd[2] = 0xDA000000;
dvd[5] = (unsigned long)dst & 0x1FFFFFFF;
dvd[6] = 0x40;
dvd[7] = 3;
DCInvalidateRange(dst, 64);
while (dvd[7] & 1);
}LBA[009128, 0x023a8]: Track[03]: Subchannel & TOC doesn't sync. LBA on TOC[9168, 0x23d0], index[01]
But "New Horizon.dat" and "New Horizon (Subs indexes).dat" hashes/sizes are the same, "New Horizon.cue" and "New Horizon (Subs indexes).cue" gaps/indexes are also the same? Misdetect?
LBA[009128, 0x023a8]: Track[02]: SubQ Reread [crc16 unmatch] -> NG. Fix manually
========== LBA[009128, 0x023a8]: Sub Channel ==========
+0 +1 +2 +3 +4 +5 +6 +7 +8 +9 +A +B
P FF FF F7 FF FF FF FF FF FF FF FF FF
Q 01 03 08 00 00 39 00 02 03 53 48 C9
R 00 00 08 00 00 00 00 00 00 00 00 00
S 00 00 00 00 00 00 00 00 00 00 00 00
T 00 00 00 00 00 00 00 00 00 00 00 00
U 00 00 00 00 00 00 00 00 00 00 00 00
V 00 00 00 00 00 00 00 00 00 00 00 00
W 00 00 00 00 00 00 00 00 00 00 00 00
LBA[009128, 0x023a8]: Track[02]: SubQ[14]:Idx[08] -> [01], [L:934]
LBA[009128, 0x023a8]: Track[02]: SubQ[15-17]:PrevRel[7439, 01:39:14], Rel[39, 00:00:39] -> [7440, 01:39:15], [L:1256]
LBA[009128, 0x023a8]: Track[02]: SubQ[22]:CrcHigh[0x48] -> [0x53]
LBA[009128, 0x023a8]: Track[02]: SubQ[23]:CrcLow[0xc9] -> [0x8a]Index should be 0.
- fixed: when 1st pregap sector has an incorrect index and isn't well-known pregap size (225, 150, 149), can't fix it correctly. https://www.mediafire.com/file/eq80y20l … st.7z/file
Thx.. same bug perhaps? https://drive.google.com/file/d/1pM0Kmb … 6CCAd/view
http://redump.org/disc/73323/
SubHeader shows "Form1" but there is not EDC in main channel.
LBA[000016, 0x00010], MSF[00:02:16], mode 2 no edc, SubHeader[1](FileNum[00]), [2](ChannelNum[00]), [3](Submode[09])[NoEOF, Form 1, Data, EndOfRecord], [4](CodingInfo[00])[]
LBA[002268, 0x008dc], MSF[00:32:18], mode 2 no edc, SubHeader[1](FileNum[00]), [2](ChannelNum[00]), [3](Submode[89])[EOF, Form 1, Data, EndOfRecord], [4](CodingInfo[00])[]
LBA[002269, 0x008dd], MSF[00:32:19], mode 2 no edc, SubHeader[1](FileNum[00]), [2](ChannelNum[00]), [3](Submode[89])[EOF, Form 1, Data, EndOfRecord], [4](CodingInfo[00])[]
LBA[002270, 0x008de], MSF[00:32:20], mode 2 no edc, SubHeader[1](FileNum[01]), [2](ChannelNum[01]), [3](Submode[88])[EOF, Form 1, Data], [4](CodingInfo[00])[]
LBA[002271, 0x008df], MSF[00:32:21], mode 2 no edc, SubHeader[1](FileNum[01]), [2](ChannelNum[01]), [3](Submode[88])[EOF, Form 1, Data], [4](CodingInfo[00])[]
LBA[002272, 0x008e0], MSF[00:32:22], mode 2 no edc, SubHeader[1](FileNum[01]), [2](ChannelNum[01]), [3](Submode[88])[EOF, Form 1, Data], [4](CodingInfo[00])[]
LBA[002273, 0x008e1], MSF[00:32:23], mode 2 no edc, SubHeader[1](FileNum[00]), [2](ChannelNum[00]), [3](Submode[89])[EOF, Form 1, Data, EndOfRecord], [4](CodingInfo[00])[]
LBA[002274, 0x008e2], MSF[00:32:24], mode 2 no edc, SubHeader[1](FileNum[01]), [2](ChannelNum[01]), [3](Submode[08])[NoEOF, Form 1, Data], [4](CodingInfo[00])[]
LBA[002275, 0x008e3], MSF[00:32:25], mode 2 no edc, SubHeader[1](FileNum[01]), [2](ChannelNum[01]), [3](Submode[08])[NoEOF, Form 1, Data], [4](CodingInfo[00])[]
:Mode 2 form 1 has always ECC and EDC, so EccEdc.exe counts them as errors.
Is this a bug that is already fixed
Yes. Please use the test version.
And this CD-i dump seems to dump correctly with non-plextor and IsoBuster, but messes up with DIC + Plextor:
sarami wrote:I think this is plextor bug.
The error does not occur in 755 and 4012, is it a bug only in 760?
It depends on the disc. It also occurred by RibShark's 755.
@sarami
Please see this topic. http://forum.redump.org/topic/38579/
The error occurs only on the PX-760A. Do you know why?
http://forum.redump.org/post/91255/#p91255 and see mainError.txt
I think this is plextor bug.
My primary concern is that in my new dump the split is 1 sector earlier comparing to what we have in the DB.
e.g. in the new dump the data track last sector is audio track but in the DB it's not and it seems more correct. I have to identify which dump is correct, old or new.
279144 belongs to track 1.
Can't extract either.
Unfortunately, their cabs do not support it.
(Subs indexes)
Try to use "/s 2"
Maybe I am doing it wrong I can't extract the files.
Also try i6cmp13b.zip
https://www.sac.sk/files.php?d=7&l=I
they are InstallShield cabinet files instead of Microsoft ones
Can you extract them of the _setup directory manually using i6comp.exe?
on Nintendo disc with DiscImageCreator I get:
fixed. https://www.mediafire.com/file/eq80y20l … st.7z/file
But Nintendo disc dumping is extremely slow. If you merely want to dump the iso, use RawDump or cleanrip on wii.
Dumped again with /mscf flag.
There is not IOSLINK.VXD.
No, not replaced with 0x55 but they can be "cleaned" somehow. I think the sectors match surrounding sectors except for the random error bytes which need to be cleaned so that they match (besides header). Perhaps it can be accomplished by rereading sectors and keeping the bytes that are most consistent between reads.
Ok, but who guarantees the kept bytes is correct?
Is there anything that be done about this problem or did I miss the solution?
The problem may be that there is not EDC in LBA 16. Perhaps it can read using 0xbe, not 0xa8. I don't fix it yet.
The installed game will have these two files
There are some cab and hdr files in the disc. If they are Microsoft cabinet files, you need to use /mscf to detect DiscGuard.
The protection of 7K2 was detected as DiscGuard.
Detected a protected file [IOSLINK.VXD]. LBA 302 to 330I think there were some sectors without EDC where the random errors needed to be cleaned manually.
According to the 3 logs of Neon Beast, LBA 299 to 1498 do not have EDC. These should be replaced to 0x55 like SafeDisc?
Dumped HoMM 3 again, still got different hashes.
How about the other 2 discs?
According to CD Media World https://www.cdmediaworld.com/hardware/c … uard.shtml, DiscGuard has IOSLINK.VXD and IOSLINK.SYS but your HoMM 3 doesn't have them.
Uploaded test version. I don't have DiscGuard discs. Test plz.
https://www.mediafire.com/file/eq80y20l … st.7z/file
t has DiscGuard protection, don't know if this is causing the problem.
c2 errors exist.
LBA[000302, 0x0012e] Detected C2 error "00 F0 F0 F0 00 00 00 0F 0F 0F 00"
This error can't be fixed by plextor drive. Needs to dump it by non-plextor drive and replace itThis is known as the plextor drive bug but may be the problem of the DiscGuard? I'm not sure about this protection.
It's just a waste of time for everyone dumping a lot of discs and not worth adding just because someone thought the feature would be neat imo.
When hashing, DIC doesn't access the disc, so you can eject it and insert the new one and start dumping by the other DIC (instance).
If you hope to eject the disc automatically like CloneCD, I can add it.
Redump Forum → Posts by sarami
Powered by PunBB 1.4.4, supported by Informer Technologies, Inc.
Currently installed 6 official extensions. Copyright © 2003–2009 PunBB.