151

(2 replies, posted in General discussion)

Hello,
   Does someone know why does my Plextor 760A seem to be locked to 8x when reading CDs? Did you come across such issue before?

152

(3,526 replies, posted in General discussion)

sarami wrote:
reentrant wrote:

subchannels are corrupted.

This? http://forum.redump.org/post/54682/#p54682

I'm not the original dumper, I only saw the logs. In idlord's case /s 2 didn't help. In one of the logs you output a table describing TOC with pregap and this table is computed using RMSF in SubQ, yes? The problem with the CD is that RMSF in Q channel is bad but not random. For example at some point (say LBA 90000), RMSF is changed to some low value like 00:24:24 and goes up on each frame. After some sectors it restarts again and goes up.

RMSF goes 1 frame up with each sector (it's good) but the value is shifted and it screwes everything...

153

(3,526 replies, posted in General discussion)

I checked idlord's logs and the issue is because subchannels are corrupted.

Listing the different protection schemes for the 8 subcoding channels...
Channel P: no protection, Channel Q: 16-bit CRC, Channels R to W:

[FONT=Arial][SIZE=2][SIZE=2][FONT=Arial][SIZE=2][FONT=Arial]To protect the data in the subcoding channels R to W, a (24, 20) Reed-Solomon error correction code is used. To improve the burst error correction capability, 8 times interleaving is added to this error-correction system. The first two symbols in a PACK have additional protection with a (4, 2) Reed-Solomon error correction code.
[/FONT][/SIZE][/SIZE][/FONT][/SIZE][/FONT]

https://club.myce.com/t/subchannel-issues/195516/9

Sarami maybe you could take the CRC16 from Sub Q and attempt to detect single bit errors by bit swapping each bit in Sub Q and checking if CRC16 matches (CRC16 could also be corrupted). cdgtool is using such approach to clean the subs for random bit errors. Could you implement this simple algorithm. That could solve issue with such rotting CDs...

154

(8 replies, posted in General discussion)

Sector 16, offset 320-370 in isobuster.
Newest DIC puts PVD to one of the log files.

It's this:

if(sector[0x10] == sector[0x14] && sector[0x11] == sector[0x15] && sector[0x12] == sector[0x16] && sector[0x13] == sector[0x17]) { OK } else { FLAGS_NOT_SAME }

156

(2 replies, posted in General discussion)

Try to read discs with positive and negative write offsets...

157

(2 replies, posted in General discussion)

What OS ? Recent OS can screw the protectors...

158

(3,526 replies, posted in General discussion)

So in case of this 1024B sector is DIC going to have support for this?

Sarami: Could you made a commit to git with latest changes? I think I have a DVD that fails to dump and I'd like to debug it...

159

(3,526 replies, posted in General discussion)

sarami wrote:

http://redump.org/disc/43476/
File system doesn't corrupt, but CD-ROM that "Logical Block Size" isn't 2048 byte is perhaps rare or irregular. So, I think the OS that is newer than WinXP doesn't support it.

Nice find. Also some tools do not support it either (Total Commander) + 7z.

160

(3,526 replies, posted in General discussion)

In this case it's possible to reimage from mounted image in virtual drive

161

(3,526 replies, posted in General discussion)

It's not a bug in DIC. DIC correctly parses the data. It's disc fault. New operating systems do not detect anything on the cd. Only old Windows show the data (I guess those old versions do not handle Path Table records).

162

(3,526 replies, posted in General discussion)

I just had a small morning debugging session and one of the dumpers found a CD which has corrupted Path Table Record. I inspected it under debugger and basically all fields are off. I think Path Table Records related values in PVD are wrong.

Please add an option to disable reading Path Table Record via command line in order to fight such weird CDs...

Yes

It could this: http://redump.org/disc/42279/

Also Ring PROTECH cannot be dumped with Plextors.
1) Extract AUDIO using DIC.
2) Extract DATA using OptiARC.

This is the only solution...

165

(3,526 replies, posted in General discussion)

I checked under debugger that pDirRec[*nDirPosNum].uiDirNameLen = 0. It's an error during mastering phase?

> Is this solved ?

I forgot which dics it was neutral

166

(3,526 replies, posted in General discussion)

Also I found one bug in CD-Text dumping. In function: SetAndOutputTocCDText -> strlen(pTmpText + uiIdx) crashes. iuIdx has some big value. This only happens with PX760. Other drive reads it correctly. Maybe before parsing those data structures subchannels should be corrected (packed mode read?).

/rc /d8 /c2 10 is common

Only DIC can rip it properly. There should be 10 errors...

169

(3,526 replies, posted in General discussion)

sarami wrote:

Escaped 0 length.

        if (pDirRec[*nDirPosNum].uiDirNameLen > 0) {
                                   :
                                   :
        }
        else {
            OutputVolDescLogA(
                "\t     Length of Directory Identifier: %u\n", pDirRec[*nDirPosNum].uiDirNameLen);
            break;
        }

Is 0 correct value? I want to look the *mainInfo.txt and *volDesc.txt

When I terminate program mainInfo.txt is empty and volDesc has:

========== LBA[000018, 0x00012]: Volume Descriptor ==========
                           Volume Descriptor Type: 255
                              Standard Identifier: CD001
                        Volume Descriptor Version: 1
========== LBA[000019, 0x00013]: Path Table Record ==========
         Length of Directory Identifier: 1
    Length of Extended Attribute Record: 0
                     Position of Extent: 21
              Number of Upper Directory: 1
                   Directory Identifier: 

I checked under debugger that pDirRec[*nDirPosNum].uiDirNameLen = 0. It's an error during mastering phase?

170

(3,526 replies, posted in General discussion)

There seems to be some inifite loop in function: OutputFsPathTableRecord:

pDirRec[*nDirPosNum].uiDirNameLen is 0 in my CD and it casues infinite loop

171

(3,526 replies, posted in General discussion)

I don't have logs from: http://redump.org/disc/42648/. Usurper has them...

172

(3,526 replies, posted in General discussion)

VobProtectCD

http://redump.org/disc/42648/

173

(3,526 replies, posted in General discussion)

Sarami there's a small regression in latest version of DIC. When you specify /rc switch and no protection is detected a warning pops up with message /rc is ignored. For some discs (when protection cannot be detected) this is causing a regression and some sectors are not properly dumped. Please provide a way to override /rc so that it's always active.

174

(32 replies, posted in General discussion)

Is it possible to glue valid sector ranges from all your copies?

175

(3,526 replies, posted in General discussion)

"it uploaded a dozen or so junk files" - what?