Search options (Page 1 of 9)

Ok. I think I know where's the problem = confusion. Arguments to function "ContainsC2Error" look correct but this not 1:1 correlated to arguments to "WriteC2". In other words to have a perfect C2 file arguments to WriteC2 function has to be modified too in the same manner.

Btw, this line of code:

else {
    bRet = ContainsC2Error(pDevice, 0, CD_RAW_READ_C2_294_SIZE, lpNextBuf, &pDiscPerSector->uiC2errorNum, nLBA, FALSE);}

I think when you specify "lpNextBuf" you assume 294 C2 offset but what for drives that have 0 C2 offset?

Maybe it should be like that:

if(Plextor712+) {assume 295 offset);}
else if(Plextor) {assume 294 offset);}
else {assume 0 offset);}

sarami, I checked this topic and noticed one thing:

"It does seem that the .c2 file includes the missing sector now. Ideally it would be great if DIC would output 'corrected' .c2/log files that reflect the locations in the scm. That means a version of the .c2 with combined offset, additional offset (if present for certain drives), and reported c2 ofs."

Small progress: I think that these numbers (ofs):

                 ofs: 3e2, 3e3, 3f2, 3f3, 41d, 4aa, 4ab, 4b0, 4b1, 4d5, 562, 563, 568, 569, 620, 621, 630, 631, 
 LBA[080785], LBA translation to SCM address in hex[0xb534430], LBA in C2 file[0x16a6886] Detected C2 error 18 bit
..
LBA[080785, 0x13b91]: crc32[078]: 0xba9f0657 good. Rewrote .scm[190006288-190008639(b534410-b534d3f)] .c2[23750790-23751083(16a6886-16a69ab)]

Should be interpreted as being shifted by combined offset if you try to match these pointers to specific sector in SCM.

In my example dump I had to shift data by 40 bytes but combined offset is 8 samples = 32bytes. It's still a question why I had to shift data by additional 8 bytes (2 samples). I have a feeling that not all Plextors 760 have equal C2 offset...

There are non-zero bytes in C2 file. I did some analysis of logs / files and came to a conclusion that sth is wrong with parsing C2 / writing to SCM.

                 ofs: 1d4, 1d5, 1df, 272, 273, 297, 32a, 32b, 365, 3e2, 3e3, 3f2, 3f3, 41d, 4aa, 4ab, 4b0, 4b1, 4d5, 562, 563, 568, 569, 620, 621, 630, 631, 
 LBA[080785], LBA translation to SCM address in hex[0xb534430], LBA in C2 file[0x16a6886] Detected C2 error 27 bit

Next step: verification of SCM writes:
1) Extract sector 080785 from SCM file prior to rereading -> File A
2) Extract sector 080785 from SCM file after rereading -> File B
3) Compare File A <=> File B
4) Differences at offsets: F4 and F5, and 2 more. The thing is that offsets F4 and F5 can't be written to according to C2 pointers. I have also verified that the writes to F4 and F5 offsets inject wrong data which result in extra errors after descrambling.

Then I attempted to repair the image in cdmage and extracted 080785 sector (2 files - before and after repairing).
Then I tried to match differences between those both 2 files and C2 file. C2 pointers matched after I shifted the sector by 40 bytes (see attachment - UNFIXED_SECTOR file). So maybe Plextor 760 has some additional C2 shift?

Another thing is that it looks like single bit in C2 file should be treated as if there were 2 erroneous bytes in image file. Some bits are not reported in C2 file and 2 bytes are bad in image. It's weird.

Disc info:

========== Offset (Drive offset refers to http://www.accuraterip.com) ==========
     Combined Offset(Byte)     32, (Samples)     8
    -   Drive Offset(Byte)    120, (Samples)    30
    ----------------------------------------------
           CD Offset(Byte)    -88, (Samples)   -22
    Overread sector: 1
    SubChannel Offset: 0

Btw, is the C2 file using combined offset? 40bytes = 10 samples vs 8 samples combined offset, this gives 2 samples offset in C2. What is this? Some versions of PX760 have different C2 offsets?

Please look at it and try to fix it.

EDIT: have a look at this:

if (IsPlextor712OrNewer(pDevice)) {
    BOOL bRetA = ContainsC2Error(pDevice, 1, CD_RAW_READ_C2_294_SIZE, lpNextBuf, &pDiscPerSector->uiC2errorNum, nLBA, FALSE);
    UINT c2ErrorBak = pDiscPerSector->uiC2errorNum;
    BOOL bRetB = ContainsC2Error(pDevice, 0, 1, lpNextBuf + CD_RAW_SECTOR_WITH_C2_294_AND_SUBCODE_SIZE, &pDiscPerSector->uiC2errorNum, nLBA, FALSE);
    pDiscPerSector->uiC2errorNum += c2ErrorBak;

    bRet = bRetA == RETURNED_NO_C2_ERROR_1ST ? bRetB : bRetA;
}

In your implementation first bRet was overwritten with 2nd one

EDIT2:
After I applied fix above C2 rereading algorithm started to work but I don't know why since there's that 40bytes SCM / C2 offset. Weird

Yes, that's the part I didn't like since ages. IMHO data should be left as is without any voodoo magic / analyzing sectors contents, etc.

It should be possible to reconstruct such image given some metadata in comments section. If you want working ISO, just generate it by yourself using special tool like redumper or sth else

Dying drive / CD. I have never encountered such errors with DIC and I have dumped many of such crap discs

I'm the author of this CDArchive tool and I can suggest few explanations to the wiki page:
extroverread - this parameter is used to specify how many extra sectors should the drive read before starting to read ring range. For example if your ring range is LBA 1000 - 2000 and you specify extroverread = 100, the drive will start reading at sector 900. The reason for this is that sometimes the drive goes haywire when you read these ring ranges and it's to recover the drive into valid state (also the bigger the overread the faster the discs can spin when it 'sees' the ring).

extrskip - this parameter is used to describe the amount of sectors which are impossible to read before giving up with the range. For example if your ring range is LBA 1000 - 2000 and you specify extrskip = 10, the tool will stop reading the range at sector 2010. But if the drive successed reading sector 2009, the tool will reset the counter and stop reading at 2019.

Hope it's clear now. The tool makes it easy to use any drive for reading rings. The problem is that Plextors are not very good at this...

In the past Bitpool discs were 'fixed' with custom tool (replacing with 0x55). But recently it's was considered imperfect and all Bitpool discs have to be redumped without any kind of 'fixes'.

More debug output

Default = impossible because load of IBM PC DVD discs with ring protection have data padded with 0x00. Like this one:
http://redump.org/disc/60860/

> if it occurs so rare, then if dump 2 times and the two dumps match it should be correct dump.

IIRC I had never 2 consecutive bad dumps with ASUS. But it's just a probability - if something might happen it will happen

In the other thread I described what was the problem with ASUS drives (problems with locating data offset in cache). If this is handled correctly the dumps should be safe.

Problem = data in cache can sometimes be shifted by 1 (or more?) sectors. It's mandatory to parse cache data (subs) to locate correct offset instead of blindly assuming the offset.