26 Reply by Feltzkrone (edited by Feltzkrone 2009-11-04 08:12:03)

  • Registered: 2009-10-13
  • Posts: 34

No, I didn't made any mistake while posting the dumps and Plextor ones are not the same: There are three 01s in the D8 dump (channels R-W) where in the READ CD dump are 00s. The only mistake I made is that XORing as explained does NOT result in Plextor's READ CD result but in LG's one. Tonight I will burn a test CD with some data on subchannels R-W and read that one out using D8 - should give some clue about what Plextor really returns on D8 as I don't have trust anymore that it really returns raw subchannel data for P-W. I deeply hope that it's a fault in my interleaving code but I don't believe so.

EDIT: If everything goes bad, a plain D8 dump wouldn't be sufficient. The proposed C2 reporting still needs a check and for now returned subchannel data doesn't look like being proper and as themabus set D8 along with code 08 can be guessed not to be supported by all D8-capable drives. I'm afraid we run into real problems here and have these variants:

1. We can choose between D8/08 and D8/02 for either receiving C2 pointers or correct subchannel data, the first one probably not supported by all drives.
2. If we go for D8/02 immediate re-read with normal READ CD command (and C2 pointer selection) might return the wanted C2 pointers, but only if the drive caches data, so this method is pretty unsafe IMO - but how to get C2 pointers for our D8-read data then?
3. As for audio sectors I believe READ CD pretty much should return the same data as D8 - shouldn't we switch to plain READ CD (+C2+SUB) after receiving the first audio sector with D8?
4. Are C2 pointers really needed when reading data sectors using D8? Wouldn't descrambling, calculating ECC/EDC and re-reads (maybe multiple times like EAC) on ECC/EDC differences between stored and calculated data be sufficient?

  • Registered: 2006-12-24
  • Posts: 3,847

You provide too less details about the performed commands. What was the subs reading mode? 001? 010? 100?

Also, you won't be ever able to get the proper subchannels dump this way - the subchannels dumping tool should be standalone, because taking a complete dump takes hours (and you should get at least 2x confirmations on at least 2 different drives to get a somewhat reliable result).

  • Registered: 2009-10-13
  • Posts: 34

F1ReB4LL wrote:

you should get at least 2x confirmations on at least 2 different drives to get a somewhat reliable result

Agreed for this. But the same argument (that it will take hours to properly dump sub-channel data) might be used for claiming that reading subchannel data (and give susicious positions -one- re-read) along with main channel data on a regular dump is a good thing, because you save at least one complete dump of the disc (in order to read sub-channel). Btw. as subs reading mode I have used 001b.

However, the problems I've written about led me to the decision to first concentrate on helper classes and conversion routines etc. so that later changes or extensions of the utility won't be such an annoyance to do (the main code can be kept clean better the more lower-level stuff is moved to separate classes). This additionally will help non-coders to read and understand the main code i.e. what the utility does.

Just to inform you that work is still in progress... big_smile