DiscImageCreator

[sarami]

Thx.. same bug perhaps? https://drive.google.com/file/d/1pM0Kmb … 6CCAd/view
https://redump.info/disc/73323/

SubHeader shows "Form1" but there is not EDC in main channel.

Code: Select all

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.

[F1ReB4LL]

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?

[sarami]

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?

Code: Select all

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

[matura713]

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?

[matura713]

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.

[Jackal]

@sarami any way to get BCA data from gamecube discs with a PC drive?

[RibShark]

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.

[matura713]

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:

/viewtopic.php?p=26227#p26227

[sarami]

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

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:

/viewtopic.php?p=26227#p26227

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

Code: Select all

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);
}

[matura713]

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:

Code: Select all

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

Code: Select all

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:

Code: Select all

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.