3,026

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,027

Neon Beast wrote:

Can't extract either.

Unfortunately, their cabs do not support it.

superg wrote:

(Subs indexes)

Try to use "/s 2"

reentrant wrote:

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 (edited by matura713 2021-09-07 15:00:35)

Neon Beast wrote:

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

sarami wrote:

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.

matura713 wrote:

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.

OK, that's gonna be tricky, I have no idea how to even start those processes.

3,032

superg wrote:

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

sarami wrote:

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

@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

fuzzball wrote:

@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

sarami wrote:

I think this is plextor bug.

The error does not occur in 755 and 4012, is it a bug only in 760?

3,037

fuzzball wrote:
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

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

Jackal wrote:

Is this a bug that is already fixed

Yes. Please use the test version.

Jackal wrote:

And this CD-i dump seems to dump correctly with non-plextor and IsoBuster, but messes up with DIC + Plextor:

Same as http://forum.redump.org/post/94866/#p94866

3,040

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

3,041

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

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?

Post's attachments

New Horizon.7z 3.38 mb, 16 downloads since 2021-09-11 

You don't have the permssions to download the attachments of this post.

3,043

F1ReB4LL wrote:

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

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 (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

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

3,047

Jackal wrote:

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.

PX-4824TA (offset +98), PX-755SA (offset +30), ASUS BW-16D1HT (offset +6)

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:

http://forum.redump.org/post/94568/#p94568

3,049

matura713 wrote:

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.

matura713 wrote:

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.

matura713 wrote:

[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

matura713 wrote:
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:

http://forum.redump.org/post/94568/#p94568

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 (edited by matura713 2021-09-12 10:22:34)

sarami wrote:

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)
sarami wrote:

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.

sarami wrote:

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.
sarami wrote:

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.