1

(63 replies, posted in General discussion)

Audio = no. Use DIC for that.

Maybe you forgot to set corect current directory? 2 - error file not found. I'd also select different directory for extracted sectors...

3

(1 replies, posted in General discussion)

Hi,
  Today I came across some interesting info. Translated:

I'll give you a better puzzle to solve. At the market in my city, a guy sold Russian games for PSX and PS2, but you could also buy blank CD-R and DVD-R discs from him. These blank discs had something strange, apart from the manufacturer written in Cyrillic, the CD-Rs were copper gold on the bottom and the DVDs were very navy blue. The recording layer, the so-called gold on the disc, was silver The problem was elsewhere, in the package of 10 discs there was an 11th disc with a special recording program, of course in Russian, because every other known program, such as alcohol, etc., believed that the discs were recorded. After recording this disc and inserting it into the console, everything was fine and working fine. At one point I went to a friend's house with a stack of games, a few originals, a few I recorded on regular CDs, a few on Russian ones, and a few ready-made games I bought until I learned how to burn bins and cues onto CDs myself.
My friend, the console was not modified, it read the originals and there were no pirates. Finally, after several attempts to put other pirates in my hand, I came across one recorded on a disc from a Russian, and the disc started running and the game started normally without a modchip. All the discs I bought from this company played perfectly, I checked with a few people and in fact these pirated discs were the only ones that worked on unmodified consoles. The guy was arrested by the police 2-3 months after discovering this discovery and so we ran out of "almost original" records and I couldn't buy them anywhere anymore. I should have one or two of his songs somewhere on his CDs, but I'll ask my friend if he still has the PS1 with the games we recorded on those CDs, there could be some good material on YouTube with it

Reply:
It sounds interesting! It's a bit like they were discs with Sony protection recorded by him. That's why they had a bit of data recorded on them, or simply "embossed" on the inner edge.
Probably the recording program was modified to skip the first few sectors on the disc and start "further".
I suspect that it would be possible to record a similar trick on every disc, if only there was a way to copy this anti-piracy code and then use the program provided by the guy.

Do yo have some more info about it - discs manufacturer / russian software / low level idea how it worked?

4

(3,506 replies, posted in General discussion)

Super cool, thx.

5

(3,506 replies, posted in General discussion)

Thx. Btw, could you also add command line parameter for setting c2 offset value (if there's no value assume 0)?

6

(3,506 replies, posted in General discussion)

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

7

(3,506 replies, posted in General discussion)

"It's easy to add the combined offset value to "ofs: xxx"."

Could you add such line to c2 log file (with offset corrected c2 pointers - "ofs corrected:")? It's tricky because you already print offset corrected base of sector in SCM file.

EDIT:
Just found a nice info from ehw about c2 offset correction (https://github.com/saramibreak/DiscImag … issues/154):

https://user-images.githubusercontent.com/885618/200966548-e522efea-06ba-4dbf-a395-12b690723d40.png

It's actually what I see - 8 bytes difference! I think that without taking into account that additional offset value c2 rereading algorithm is not correct. Plz could you also implement this - it's so close to have a perfect c2 rereading algorithm smile

8

(3,506 replies, posted in General discussion)

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

9

(3,506 replies, posted in General discussion)

Ok, but how to explain the following:
- That I had to shift data sector by 40 bytes to match c2 pointers?
- That C2 file size is not 8 times smaller than SCM file (C2 = 91568946 / SCM = 732549216)? It looks like C2 doesn't contain pointers from single sector, last one?

10

(3,506 replies, posted in General discussion)

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 smile

11

(3,506 replies, posted in General discussion)

Plextor 760: I have a disc with small C2 errors and I think current DIC doesn't handle C2 rereading properly:

                 ofs: 11c, 11d, 127, 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 30 bit
                 ofs: 1dc, 1dd, 1e7, 294, 295, 29f, 332, 333, 357, 3ea, 3eb, 425, 4a2, 4a3, 4b2, 4b3, 4dd, 56a, 56b, 570, 571, 595, 622, 623, 628, 629, 
 LBA[080813], LBA translation to SCM address in hex[0xb544570], LBA in C2 file[0x16a88ae] Detected C2 error 26 bit
LBA[080785, 0x13b91]: crc32[000]: 0x5a6d23bd good. Rewrote .scm[190006288-190008639(b534410-b534d3f)] .c2[23750790-23751083(16a6886-16a69ab)]
LBA[080813, 0x13bad]: crc32[000]: 0xc20ab857 good. Rewrote .scm[190072144-190074495(b544550-b544e7f)] .c2[23759022-23759315(16a88ae-16a89d3)]
LBA[311456, 0x4c0a0], MSF[69:14:56], mode 1
LBA[311457, 0x4c0a1], MSF[69:14:57], mode 1
[ERROR] Number of sector(s) where user data doesn't match the expected ECC/EDC: 2
    Sector: 80785, 80813, 
Total errors: 2

Sarami, can you check the algorithm and verify it rereads / writes correct bytes?

12

(14 replies, posted in General discussion)

superg wrote:

Yes I saw that, at some point I think sarami changed something in DIC. This is the most important thing I'm trying to "fix" here. Regardless of applying shift correction, or not - I think we should not rely on sector content (or rely less) when deciding whether we should unscramble sector or not. It's impossible to come up with good decision algo if sector is partially damaged as pretty much any byte can be damaged and this shift issue here clearly demonstrate that.

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.

user7 wrote:

Redumper fixing the shifting offset makes it completely useable, thus truly preserving the ROM in a fully useable state.

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 smile

13

(63 replies, posted in General discussion)

Guys, I have just seen ringed discs dumping guide and one small step is missing:
- it's necessary to use eccedc with parameter -fixex at the end of dumping process. This is needed because cdmage has a bug. If you attempt to repair all the sectors in an image, the sectors which are already filled with 0x55 pattern, they will be erroneously damaged by filling reserved field with 0x00 value (8 bytes IIRC). EccEcc with fixex command restores full 2352 bytes with 0x55 value. It's not a critical bug (images can be repaired at any time, but it's better to have it correct in first place).

14

(3,506 replies, posted in General discussion)

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

15

(3,506 replies, posted in General discussion)

superg wrote:

Please see my reply here: http://forum.redump.org/post/99760/#p99760

Very nice research. Is this fix already implemented?

16

(4 replies, posted in General discussion)

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

My PX760 doesn't like DVD5 - same symptom. Cleaning the lens helps for a week or two...

18

(3,506 replies, posted in General discussion)

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'.

19

(63 replies, posted in General discussion)

More debug output #2

20

(63 replies, posted in General discussion)

More debug output

21

(63 replies, posted in General discussion)

Updated version of application in attachment.

Fixed: various bugs

22

(3,506 replies, posted in General discussion)

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/

True. All my Plextors: 2x760, 716, 4012 are not that great at reading scratched discs. Other drives perform much better.

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

Looks random and happens from time to time like 1/15