sarami, is it normal to have a separate set of (Subs indexes) where everything is the same as in primary TOC based split?
Logs: https://www.dropbox.com/s/4clypf96lu0zq … OR.7z?dl=0
Asking because my verification has identical (Subs indexes) but doesn't match what we have in the DB: http://redump.org/disc/15537/
I compared both dumps and the new data track is 1 sector more padded with zeroes and audio track is 1 sector less comparing to the DB one.
3,026 2021-09-05 20:45:18
3,027 2021-09-06 02:52:57
Can't extract either.
Unfortunately, their cabs do not support it.
(Subs indexes)
Try to use "/s 2"
3,028 2021-09-07 14:49:46
Hi,
Yes, I remember that disc. It was not possible to get consistent dump. If you look at scm file you'll notice that some bytes at discguard locations are always different. It's some kind of 'weak data' protection.Such dumps need manual fixing. But you need to know the data to fix with. In my case it was easy as these weak bytes happened in the middle of a sector (surrounded by zeroes).
Hi, how can I fix my DiscGuard discs? Thanks.
3,029 2021-09-07 14:59:42 (edited by matura713 2021-09-07 15:00:35)
Hi, how can I fix my DiscGuard discs? Thanks.
my understanding based on what @reentrant is saying is that you need:
1. identify the "weak bytes", i.e. those bytes that are different on every dump due to the protection
2. try to "guess" what is the correct value of each "weak byte"- in case of @reentrant dump it was looking like 00000XX00000 and so it was easy to guess that XX=00
however, in your case it could be not that easy to guess the "weak byte" value.
3,030 2021-09-07 18:11:04
Try to use "/s 2"
/s 2 didn't help.
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.
3,031 2021-09-08 03:37:12
my understanding based on what @reentrant is saying is that you need:
1. identify the "weak bytes", i.e. those bytes that are different on every dump due to the protection
2. try to "guess" what is the correct value of each "weak byte"- in case of @reentrant dump it was looking like 00000XX00000 and so it was easy to guess that XX=00however, in your case it could be not that easy to guess the "weak byte" value.
OK, that's gonna be tricky, I have no idea how to even start those processes.
3,032 2021-09-08 09:50:02
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.
3,033 2021-09-08 12:46:35
279144 belongs to track 1.
Got it, I'll mark the old dump as bad and will add a new one.
Thanks for your help!
3,034 2021-09-09 02:49:42
@sarami
Please see this topic. http://forum.redump.org/topic/38579/
The error occurs only on the PX-760A. Do you know why?
3,035 2021-09-09 03:13:36
@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.
3,036 2021-09-09 08:22:46
I think this is plextor bug.
The error does not occur in 755 and 4012, is it a bug only in 760?
3,037 2021-09-09 16:21:59
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.
3,038 2021-09-10 08:58:13
Here's 3 logs with bad multisession cuesheets. Is this a bug that is already fixed or a new one?
https://www109.zippyshare.com/v/qX1iHqXW/file.html
https://www109.zippyshare.com/v/j0cYXyUz/file.html
https://www109.zippyshare.com/v/WqOmxrW7/file.html
And this CD-i dump seems to dump correctly with non-plextor and IsoBuster, but messes up with DIC + Plextor:
https://www29.zippyshare.com/v/iP7DufIh/file.html
3,039 2021-09-10 10:34:18
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:
3,040 2021-09-10 11:25:12
Thx.. same bug perhaps? https://drive.google.com/file/d/1pM0Kmb … 6CCAd/view
http://redump.org/disc/73323/
3,041 2021-09-10 13:01:46
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.
3,042 2021-09-10 23:27:18
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?
3,043 2021-09-11 05:39:31
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
3,044 2021-09-11 09:18:57
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?
3,045 2021-09-11 14:33:47 (edited by matura713 2021-09-12 00:02:43)
Today, I found Yamaha CDR200t drive in my storage, it supports 0xd8 reading and I wanted to try dump with it and compare against Plextor, but DiscImageCreator outputs:
This drive doesn't define in driveOffset.txt
Please input drive offset(Samples): +733
This drive supports [OpCode: 0xd8, SubCode: 0]
Failed to get write-offset
This drive supports [OpCode: 0xd8, SubCode: 1]
This drive supports [OpCode: 0xd8, SubCode: 2]
Failed to get write-offset
Retry 1/10 after 10000 milliseconds
This drive supports [OpCode: 0xd8, SubCode: 2]
Failed to get write-offset
BTW, regarding the offset - I assumed it's +733 as all other Yamaha drives from that era - it's almost sure that is the correct offset. In any way, if the above DiscImageCreator error is fixable and it can work with DiscImageCreator, then I will burn with ExactAudioCopy test offset disc to confirm the offset for sure and we can add it to "driveOffset.txt" file.
[EDIT] CDR200 can be modified to CDR400 with just 1 resistor removed - that's according to the following article:
https://www.nickles.de/artikel/html/7.htm
however, CDR400 firmware file "40010g.exe" needed for that modification seems is no longer available for download even on archived copies of yamaha website. in any way, i believe it's interesting information...
[EDIT2] I found the aforementioned CDR400 firmware, not the latest, but at least it's something:
https://web.archive.org/web/19970816224 … 40010g.exe
[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.
3,046 2021-09-11 18:26:17
@sarami any way to get BCA data from gamecube discs with a PC drive?
3,047 2021-09-11 18:30:06
any way to get BCA data from gamecube discs with a PC drive?
I believe claunia found a single drive that could get this data, it seems it needs to at least recognise the disc. You might be able to swap trick with a legit DVD with a BCA to read it on other drives but that might not work if the drive reads the BCA on insertion and caches it from there.
3,048 2021-09-12 00:32:50
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:
3,049 2021-09-12 04:48:55
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);
}
3,050 2021-09-12 10:19:28 (edited by matura713 2021-09-12 10:22:34)
28h, A8h are general commands. See https://en.wikipedia.org/wiki/SCSI_command
D4h, D5h are old NEC drive commands, AFAIR.
I see, I was thinking they are Plextor special commands only because of CacheX, source code:
https://github.com/xavery/cachex/
since with Plextor it outputs:
Supported read commands: BEh A8h(FUA) 28h(FUA) D4h(FUA) D5h(FUA) D8h(FUA)
I know some 90's drives of sony, pioneer, etc also support it.
according to CDParanoia source code, some NEC and Sony for sure have 0xd8:
http://www.acquerra.com.au/personal/bir … nterface.c
the nec drive expects d8 to be 10 bytes, and a 12 byte version (Sony) crashes the drive
but as obviously from that comment, they use different bytes number passed to 0xd8: respectively 10 bytes and 12 bytes. I don't know Plextor how many bytes requires, i.e. is it Sony-like or NEC-like or neither, i.e. it's Plextor-like.
Please try to use cdtoimg_d8
it fails and I wonder if the reason is what CDParanoia code mentioned, i.e. 10-bytes versus 12-bytes D8h command:
cdtoimg.exe f: test.iso 6
Drive type is recognised as CDROM/DVD.
Sending SPC1 Test Unit CDB6 command..done.
Returned good status.
Sending read TOC command..done.
Total user tracks : 1
Total sectors : 27807
Sending MMC1 CD speed command (read: 1058kbytes (6x)write: max speed)..done.
Reading sector 0 to 26 (total: 27807, progress: 0.1%)
Sense data, key:ASC:ASCQ: 05:64:00
Aborting process.
Could not create image from drive f.
Perhaps, BCA data of the Nintendo disc is stored in another place?
Cleanrip code
thanks, I will investigate further by myself, my plan is:
* make small tool using SPTI Windows interface, e.g. called "bca_test" that tries only to read the BCA with the Cleanrip code
* test that on few DVD-RAM discs I have - their BCA is not empty for sure, because that is where CPRM information is stored and they all mentioned on their box/cover they are CPRM licensed and support it
I don't know if that is good plan for such a test, but I will report back here when I have any result to share, plus will have some (nerdy) fun, while doing (trying) the above plan.