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.

27

(3,497 replies, posted in General discussion)

Jackal wrote:
Neon Beast wrote:

Hi, I have this Chinese release of Heroes of Might and Magic III, I got two copies with identical ring codes, but hashes don't match, and I can't get a consistent dump. It has DiscGuard protection, don't know if this is causing the problem.
Dumped with the latest test build.
Logs: https://mega.nz/folder/XzB3SYyL#0g-CNMwckW9kQgmEFv-iRQ

DiscGuard needs a special treatment. I think there were some sectors without EDC where the random errors needed to be cleaned manually. Maybe reentrant remembers.

http://redump.org/discs/quicksearch/dis … tion/only/

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

28

(3,497 replies, posted in General discussion)

Come on guys. It's as simple as implementing some command line switch to perform extra hash caclulations...

29

(3,497 replies, posted in General discussion)

W8. I have found where the problem is. The drive returns the data that is sometimes shifted by 1 sector.

Look at those 2 dumps:
lgcache_all_0_378251_OK - cache dump starting with sector 378251. It's good cache.
lgcache_all_0_378251_BAD - cache dump starting with sector 378251. It's bad cache.

The data in bad one is shifted by 0xB00 bytes = 1 cache sector.

So the real solution has to analyze cache dump and find proper starting offset of data. Right now it assumes the offset is 0. In case of audio tracks MSF is not available so subchannel data has to be taken into account.

30

(3,497 replies, posted in General discussion)

Jackal: combined offset (if > 0 cache is used).

I replicated the issue locally (last few samples are bad - 6 in my case). Disc is 0 offset (combined 6). I have also modified DIC to dump the cache from Asus drive to clearly see what the drive returns.

Result:
Cache dumps contain scrambled data so I took last 6 samples of scm file and tried to bin search cache files. I got a hit. The bad samples were present in cache dumps. This means that the drive is returning bad data.

It took like 10 dumps to hit bad data in cache.

31

(3,497 replies, posted in General discussion)

I have both Plextor PX760 and Asus BW-16D1HT and I've been dumping discs with both of them since quite some time. After dumping few hundreds discs (with both of them for comparision) I can say that Asus is not 100% reliable with positive combined offset discs where data is taken from cache.

From time to time last few samples are bad (for example if combined offset is X samples I get X last samples bad). I haven't debugged if it's firmware issue or DIC bug). Most of the time reripping the disc 2nd time produces correct dump.

http://forum.redump.org/post/89943/#p89943 -> I have this issue. Most probably bad dump. Rerip.

> The audio tracks all seem to the data starting 4 bytes later than Nexy's Plextor dump

Haven't observed it. Probably different master disc.

Example off hand (Asus):

LBA[378268, 0x5c59c], mode 1
LBA[378269, 0x5c59d], mode 1
LBA[378270, 0x5c59e], mode 1
LBA[378271, 0x5c59f], mode 1 User data vs. ecc/edc doesn't match
[ERROR] Number of sector(s) where user data doesn't match the expected ECC/EDC: 1
    Sector: 378271, 

If you see this in console:

========== Reading 378251 - 378271 INTO CACHE ==========
01 Cache LBA 378251, SubQ Trk 01, AMSF 84:05:27
02 Cache LBA 378252, SubQ Trk 01, AMSF 84:05:28
03 Cache LBA 378253, SubQ Trk 01, AMSF 84:05:29
04 Cache LBA 378254, SubQ Trk 01, AMSF 84:05:30
05 Cache LBA 378255, SubQ Trk 01, AMSF 84:05:31
06 Cache LBA 378256, SubQ Trk 01, AMSF 84:05:32
07 Cache LBA 378257, SubQ Trk 01, AMSF 84:05:33
08 Cache LBA 378258, SubQ Trk 01, AMSF 84:05:34
09 Cache LBA 378259, SubQ Trk 01, AMSF 84:05:35
10 Cache LBA 378260, SubQ Trk 01, AMSF 84:05:36
11 Cache LBA 378261, SubQ Trk 01, AMSF 84:05:37
12 Cache LBA 378262, SubQ Trk 01, AMSF 84:05:38
13 Cache LBA 378263, SubQ Trk 01, AMSF 84:05:39
14 Cache LBA 378264, SubQ Trk 01, AMSF 84:05:40
15 Cache LBA 378265, SubQ Trk 01, AMSF 84:05:41
16 Cache LBA 378266, SubQ Trk 01, AMSF 84:05:42
17 Cache LBA 378267, SubQ Trk 01, AMSF 84:05:43
18 Cache LBA 378268, SubQ Trk 01, AMSF 84:05:44
19 Cache LBA 378269, SubQ Trk 01, AMSF 84:05:45
20 Cache LBA 378270, SubQ Trk 01, AMSF 84:05:46
21 Cache LBA 378271, SubQ Trk aa, AMSF 84:05:47
22 Cache LBA 378272, SubQ Trk aa, AMSF 84:05:48 [Lead-out]
23 Cache LBA 378273, SubQ Trk aa, AMSF 84:05:49 [Lead-out]
24 Cache LBA 378274, SubQ Trk aa, AMSF 84:05:50 [Lead-out]
25 Cache LBA 378275, SubQ Trk aa, AMSF 84:05:51 [Lead-out]
26 Cache LBA 378276, SubQ Trk aa, AMSF 84:05:52 [Lead-out]
27 Cache LBA 378277, SubQ Trk aa, AMSF 84:05:53 [Lead-out]
28 Cache LBA 378278, SubQ Trk aa, AMSF 84:05:54 [Lead-out]
29 Cache LBA 378279, SubQ Trk aa, AMSF 84:05:55 [Lead-out]
30 Cache LBA 378280, SubQ Trk aa, AMSF 84:05:56 [Lead-out]
31 Cache LBA 378281, SubQ Trk aa, AMSF 84:05:57 [Lead-out]
32 Cache LBA 378282, SubQ Trk aa, AMSF 84:05:58 [Lead-out]
33 Cache LBA 378283, SubQ Trk aa, AMSF 84:05:59 [Lead-out]
34 Cache LBA 378284, SubQ Trk aa, AMSF 84:05:60 [Lead-out]
35 Cache LBA 378285, SubQ Trk aa, AMSF 84:05:61 [Lead-out]
36 Cache LBA 378286, SubQ Trk aa, AMSF 84:05:62 [Lead-out]
37 Cache LBA 378287, SubQ Trk aa, AMSF 84:05:63 [Lead-out]
38 Cache LBA 378288, SubQ Trk aa, AMSF 84:05:64 [Lead-out]

Better watch out for bad dumpies...

IMHO audio tracks made with Asus and positive offset discs should be temp banned unless fully resolved smile

32

(3,497 replies, posted in General discussion)

sarami wrote:
Nicknine wrote:

SafeDisc DVDs don't need DPM graph, they only need DMI sector.

I know it, but I don't support mds/mdf itself yet.

Nice info. Btw. libmirage has headers + parser for MDS. It's just a copy paste stuff + some renaming to look more legit smile

Sony doesn't like people "pirating" Sony movies smile

34

(3,497 replies, posted in General discussion)

Lame wrote:

Hello. I have problem with newest version of DICUI (1.8). Today i tried to dump Midtown Madness which turned out it's verification, but 1.8 version made 3 different result and 1.7.1 two times in row matched to dump on main site. I spotted 2 times this problem occured also with other disc I tried:

Creating .scm (LBA)  37068/301245[F:ProcessReadCD][L:288] GetLastError: 1117, Nie mo┐na wykonaŠ ┐╣dania z powodu b│ŕdu urz╣dzenia We/Wy.

(Cannot execute task, because of input output device error)

I have Plextor PX-755SA

I have similar errors. I think they are related to bad cabling and controller is dropping the device from time to time.

35

(3,497 replies, posted in General discussion)

It turns out it doesn't depend on number of lead out sectors. But in most cases last few samples are wrong. I'll try to dump the cache to disk and manually inspect what's causing this...

36

(3,497 replies, posted in General discussion)

sarami wrote:

I also tried it with the same combined offset disc using the latest test version (20201115T172518) and it was no problem...

Another one. Offset +1617 and 3 or 4 lead-out sectors - last 3 sectors were off by one (MSF).

I think something bad happens when there's not enough lead-out (aa) sectors in the cache. Maybe retry cache read by reading more sectors? I have dumped maybe 20 plus offset discs and had these 2 cases. Both had very few 'lead-out' sectors printed to console. This looks like a problem with drive cache...

37

(3,497 replies, posted in General discussion)

FYI: I have tested a combined plus offset disc with mastering error on Asus BW-16D1HT and the result is the same as on Plextor 760. Probably more tests are needed but it seems like this Asus drive is finally a good replacement drive for all these retro Plextor drives...

EDIT:

Sarami I have such disc:

     Combined Offset(Byte)     24, (Samples)     6
    -   Drive Offset(Byte)     24, (Samples)     6
    ----------------------------------------------
           CD Offset(Byte)      0, (Samples)     0

ASUS gave me wrong image. Last 6 samples of image are all zeroes. They should contain some data. Can you fix this?

EDIT2:

Reripped the disc and it was ok next time. I noticed that when there's more than one lead-out sector in cache it's ok. Maybe the computations are off by one somewhere?

cdrwin anyone?

39

(3,497 replies, posted in General discussion)

Wow, works nice now.

Offsets: 2000+
Data track: ok
Audio track: ok

I don't have disc with big offset and mastering error so I cannot test. Is there a way to search for big offset disc and mastering error in comments?

http://redump.org/disc/27483/ - Nexy disc. Maybe he can check it?

40

(3,497 replies, posted in General discussion)

x = 6468 (combined offset * 4)

========== Offset (Drive offset referes to http://www.accuraterip.com) ==========
     Combined Offset(Byte)   6468, (Samples)  1617
    -   Drive Offset(Byte)     24, (Samples)     6
    ----------------------------------------------
           CD Offset(Byte)   6444, (Samples)  1611

41

(3,497 replies, posted in General discussion)

Problem is here:

INT tmpLBA = MSFtoLBA(md, sd, fd) - 150;
if (tmpLBA == nLineNum ||
    (pDisc->SCSI.toc.TrackData[0].Control & AUDIO_DATA_TRACK) == 0) {

tmpLBA = 325226
nLineNum = 21

In case of data track code never goes inside 'if'

And in my case nLBA i always bigger than tmpLBA by 2.

It looks like the data in cache has some offset.

I hacked it this way:

if (nLBA >= pDisc->SCSI.nAllLength) {
        for (DWORD x = 0; x < CD_RAW_SECTOR_SIZE * 16 - 16; ++x) {
            if (IsValidMainDataHeader(aMainBuf + x)) {
                bHeader = TRUE;
                BYTE m = (BYTE)(aMainBuf[x + 0x0c] ^ 0x01);
                BYTE s = (BYTE)(aMainBuf[x + 0x0d] ^ 0x80);
                BYTE f = (BYTE)(aMainBuf[x + 0x0e]);
                BYTE mode = (BYTE)(aMainBuf[x + 0xf] ^ 0x60);

                BYTE md = BcdToDec(m);
                BYTE sd = BcdToDec(s);
                BYTE fd = BcdToDec(f);
                INT tmpLBA = MSFtoLBA(md, sd, fd) - 150;
                if (tmpLBA == nLBA ||
                    (pDisc->SCSI.toc.TrackData[0].Control & AUDIO_DATA_TRACK) == 0) {
                    OutputLog(standardOut | fileDisc,
                        "-----------------------------------------------------\n"
                        "Cache SIZE: %u (This size is different every running)\n"
                        "-----------------------------------------------------\n"
                        , nLineNum
                    );
                    *lpbCached = TRUE;

                    break;
                }
            }
        }

Read 16 sectors from cache. On 3rd iteration (offset 2) it entered 'if'

EDIT:
For audio maybe parsing subs would be better?

42

(3,497 replies, posted in General discussion)

Still sth not right. Under debugger I see that ReadCDForCheckingReadInOut returned FALSE and exception was thrown. Only cache was printed on console.

43

(3,497 replies, posted in General discussion)

Ok. A small suggestion: it's better to read two sectors from cache on each F1 call and scan only first 0x900 bytes for 0x00 0xFF.. 0xFF 0x00 pattern because there could be a case where the sector header starts at offset: 0x8FF. If you read only 0x900 bytes such header won't be found.

44

(3,497 replies, posted in General discussion)

sarami wrote:
reentrant wrote:

It looks like data is copied from wrong cache sectors.

I forgot to set the offset.
http://www.mediafire.com/file/eq80y20l9 … st.7z/file


Still sth not right:

LBA[325218, 0x4f662], MSF[72:18:18], mode 1
LBA[325219, 0x4f663], MSF[72:18:19], mode 1
LBA[325220, 0x4f664], MSF[72:18:20], mode 1
LBA[325221, 0x4f665], MSF[72:18:21], mode 1
LBA[325222, 0x4f666], MSF[72:18:22], mode 1
LBA[325223, 0x4f667], MSF[72:18:23], mode 1 User data vs. ecc/edc doesn't match
LBA[325226, 0x4f66a], MSF[72:18:26], mode 1
LBA[325227, 0x4f66b], MSF[72:18:27], mode 1
LBA[325228, 0x4f66c], MSF[72:18:28], mode 1
LBA[325229, 0x4f66d], MSF[72:18:29], mode 1
[ERROR] Number of sector(s) where user data doesn't match the expected ECC/EDC: 1

45

(3,497 replies, posted in General discussion)

Sth is not right. Cache:

19 Cache LBA 325224 (MSF 72:18:24) MODE 01
20 Cache LBA 325225 (MSF 72:18:25) MODE 01
21 Cache LBA 325226 (MSF 72:18:26) MODE 01
22 Cache LBA 325227 (MSF 72:18:27) MODE 01
23 Cache LBA 325228 (MSF 72:18:28) MODE 01 Lead-out
24 Cache LBA 325229 (MSF 72:18:29) MODE 01 Lead-out
25 Cache LBA 325230 (MSF 72:18:30) MODE 01 Lead-out
26 Cache LBA 325231 (MSF 72:18:31) MODE 01 Lead-out
27 Cache LBA 325232 (MSF 72:18:32) MODE 01 Lead-out
28 Cache LBA 325233 (MSF 72:18:33) MODE 01 Lead-out
29 Cache LBA 325234 (MSF 72:18:34) MODE 01 Lead-out

Image has following LBAs:
LBA[325222, 0x4f666], MSF[72:18:22], mode 1
LBA[325223, 0x4f667], MSF[72:18:23], mode 1
LBA[325224, 0x4f668], MSF[72:18:24], mode 1
LBA[325225, 0x4f669], MSF[72:18:25], mode 1 User data vs. ecc/edc doesn't match
LBA[325228, 0x4f66c], MSF[72:18:28], mode 1
LBA[325229, 0x4f66d], MSF[72:18:29], mode 1

325226 and 325227 are missing.
325228 and 325229 are lead out sectors.

It looks like data is copied from wrong cache sectors.

46

(3,497 replies, posted in General discussion)

        nLBA = pDisc->SCSI.nAllLength;

                if (!ExecReadCD(pExtArg, pDevice, lpCmd, nLBA - 1, aBuf,
                    CD_RAW_SECTOR_SIZE, _T(__FUNCTION__), __LINE__)
                    || byScsiStatus >= SCSISTAT_CHECK_CONDITION) {
                }

Ok. I didn't see this line smile

Anyway I have some good news. After some coding and experimenting with F1 command I can enable reading more sectors from cache.

Current situation:
1) You call ExecReadCD with nLBA -1 which read single sector into cache.

I have extended F1 command function to show the cache:

static int lineno = 0;
static int cacheline = 0;

BOOL ReadCacheForLgAsus(
    PEXT_ARG pExtArg,
    PDEVICE pDevice,
    PDISC pDisc,
    INT nLBA
    ) {
    //DWORD dwSize = 0xb00;
    DWORD dwSize = 0xb00 * 1;
    LPBYTE lpBuf = NULL;
    if (!GetAlignedCallocatedBuffer(pDevice, &pDisc->lpCachedBuf,
        (UINT)dwSize, &lpBuf, _T(__FUNCTION__), __LINE__)) {
        return FALSE;
    }
    // http://forum.redump.org/post/72629/#p72629
    // F1 06 xx xx xx xx yy yy yy yy
    // xx - address to read
    // yy - length of data to return
    //
    // 0x000-0x92F - Main Channel (Scrambled)
    // 0x930-0x98F - P-W Subchannel
    // 0x990-0x99F - Q Subchannel
    // 0x9A0-0x9A3 - (unknown)
    // 0x9A4-0xAC9 - C2 Error Bits
    // 0xACA-0xB00 - (unknown)
    CDB::_CDB10 cdb = {};
    cdb.OperationCode = 0xf1;
    cdb.Reserved1 = 3;

    //nLBA = 0;

    cdb.LogicalBlockByte0 = BYTE((0xb00 * nLBA >> 24) & 0xff);
    cdb.LogicalBlockByte1 = BYTE((0xb00 * nLBA >> 16) & 0xff);
    cdb.LogicalBlockByte2 = BYTE((0xb00 * nLBA >> 8) & 0xff);
    cdb.LogicalBlockByte3 = BYTE(0xb00 * nLBA & 0xff);
    //cdb.LogicalBlockByte0 = BYTE((nLBA >> 24) & 0xff);
    //cdb.LogicalBlockByte1 = BYTE((nLBA >> 16) & 0xff);
    //cdb.LogicalBlockByte2 = BYTE((nLBA >> 8) & 0xff);
    //cdb.LogicalBlockByte3 = BYTE(nLBA & 0xff);
    //cdb.TransferBlocksLsb = 0x0b;
    //cdb.Control = 0x00;
    cdb.Reserved2 = BYTE((dwSize >> 24) & 0xff);
    cdb.TransferBlocksMsb = BYTE((dwSize >> 16) & 0xff);
    cdb.TransferBlocksLsb = BYTE((dwSize >> 8) & 0xff);
    cdb.Control = BYTE(dwSize & 0xff);
#ifdef _WIN32
    INT direction = SCSI_IOCTL_DATA_IN;
#else
    INT direction = SG_DXFER_FROM_DEV;
#endif
    BYTE byScsiStatus = 0;
    if (!ScsiPassThroughDirect(pExtArg, pDevice, &cdb, CDB10GENERIC_LENGTH
        , lpBuf, direction, dwSize, &byScsiStatus, _T(__FUNCTION__), __LINE__)
        || byScsiStatus >= SCSISTAT_CHECK_CONDITION) {
        return FALSE;
    }

    FILE *a = fopen("f1cache", "wb");
    fwrite(lpBuf, dwSize, 1, a);
    fclose(a);

    UCHAR sync[] = {0, 0xFF, 0xFF, 0xFF, 0xFF, 0xFF, 0xFF, 0xFF, 0xFF, 0xFF, 0xFF ,0};
    for(DWORD x = 0; x < dwSize - 16; ++x) {
        if(!memcmp(sync, lpBuf + x, sizeof(sync))) {
            // 1 80 0 60
            UCHAR m = lpBuf[x + 0xC] ^ 0x1;
            UCHAR s = lpBuf[x + 0xD] ^ 0x80;
            UCHAR f = lpBuf[x + 0xE] ^ 0;
            UCHAR mode = lpBuf[x + 0xF] ^ 0x60;

            UCHAR md = BcdToDec(m);
            UCHAR sd = BcdToDec(s);
            UCHAR fd = BcdToDec(f);

            ULONG lsn = fd + 75 * (sd + 60 * md) - 150;

            if(!cacheline) {
                cacheline = lsn;
            } else if(lsn != cacheline + 1) {
                fprintf(stdout, "=====================================\n");
                fprintf(stdout, "Cache SIZE: %lu\n", lineno);
                fprintf(stdout, "=====================================\n");

                cacheline = lsn;

                Sleep(3000);
            } else {
                cacheline = lsn;
            }

            fprintf(stdout, "%lu Cache MSF: %02x %02x %02x %lu %06lu\n", lineno++, m, s, f, mode, lsn);
            OutputDiscLog("%lu Cache MSF: %02x %02x %02x %lu %06lu\n", lineno, m, s, f, mode, lsn);
        }
    }

    //    OutputCDMain(fileMainInfo, lpBuf, nLBA, dwSize);
    return TRUE;
}

and in caller function I call it like this:

DWORD ct = 10;

OutputDiscLog("Reading %lu - %lu INTO CACHE\n", nLBA - 1 - ct, nLBA - 1);
fprintf(stdout, "Reading %lu - %lu INTO CACHE\n", nLBA - 1 - ct, nLBA - 1);

for(DWORD x = nLBA - 1 - ct; x <= nLBA - 1; ++x) {
    if(!ExecReadCD(pExtArg, pDevice, lpCmd, x, aBuf,
        CD_RAW_SECTOR_SIZE, _T(__FUNCTION__), __LINE__)
        || byScsiStatus >= SCSISTAT_CHECK_CONDITION) {
    }
}

DWORD xx = 0;
for(; xx < 10000; ++xx) {
    if(!ReadCacheForLgAsus(pExtArg, pDevice, pDisc, xx)) {
        break;
    }
}

Result:

Reading 326657 - 326657 INTO CACHE
0 Cache MSF: 72 37 30 1 326655
1 Cache MSF: 72 37 31 1 326656
=====================================
Cache SIZE: 2
=====================================
2 Cache MSF: 00 02 00 1 000000
3 Cache MSF: 00 02 01 1 000001
4 Cache MSF: 00 02 02 1 000002

So you get 2 sectors into cache none of which are related to Lead-Out.

However when you read more sectors into cache (change 'ct' to for example 10) things get more interesting:

Reading 326637 - 326657 INTO CACHE
0 Cache MSF: 72 37 10 1 326635
1 Cache MSF: 72 37 11 1 326636
2 Cache MSF: 72 37 12 1 326637
3 Cache MSF: 72 37 13 1 326638
4 Cache MSF: 72 37 14 1 326639
5 Cache MSF: 72 37 15 1 326640
6 Cache MSF: 72 37 16 1 326641
7 Cache MSF: 72 37 17 1 326642
8 Cache MSF: 72 37 18 1 326643
9 Cache MSF: 72 37 19 1 326644
10 Cache MSF: 72 37 20 1 326645
11 Cache MSF: 72 37 21 1 326646
12 Cache MSF: 72 37 22 1 326647
13 Cache MSF: 72 37 23 1 326648
14 Cache MSF: 72 37 24 1 326649
15 Cache MSF: 72 37 25 1 326650
16 Cache MSF: 72 37 26 1 326651
17 Cache MSF: 72 37 27 1 326652
18 Cache MSF: 72 37 28 1 326653
19 Cache MSF: 72 37 29 1 326654
20 Cache MSF: 72 37 30 1 326655
21 Cache MSF: 72 37 31 1 326656
22 Cache MSF: 72 37 32 1 326657
23 Cache MSF: 72 37 33 1 326658
24 Cache MSF: 72 37 34 1 326659
25 Cache MSF: 72 37 35 1 326660
26 Cache MSF: 72 37 36 1 326661
27 Cache MSF: 72 37 37 1 326662
28 Cache MSF: 72 37 38 1 326663
29 Cache MSF: 72 37 39 1 326664
30 Cache MSF: 72 37 40 1 326665
31 Cache MSF: 72 37 41 1 326666
32 Cache MSF: 72 37 42 1 326667
=====================================
Cache SIZE: 33
=====================================
33 Cache MSF: 00 02 31 1 000031
34 Cache MSF: 00 02 32 1 000032
35 Cache MSF: 00 02 33 1 000033
36 Cache MSF: 00 02 34 1 000034

33 sectors are read from cache until it wraps. Lead out starts at entry no 23.


When you specify 'ct' = 1000, even more sectors are read into cache:

992 Cache MSF: 72 37 22 1 326647
993 Cache MSF: 72 37 23 1 326648
994 Cache MSF: 72 37 24 1 326649
995 Cache MSF: 72 37 25 1 326650
996 Cache MSF: 72 37 26 1 326651
997 Cache MSF: 72 37 27 1 326652
998 Cache MSF: 72 37 28 1 326653
999 Cache MSF: 72 37 29 1 326654
1000 Cache MSF: 72 37 30 1 326655
1001 Cache MSF: 72 37 31 1 326656
1002 Cache MSF: 72 37 32 1 326657
1003 Cache MSF: 72 37 33 1 326658 Lead out
1004 Cache MSF: 72 37 34 1 326659
1005 Cache MSF: 72 37 35 1 326660
1006 Cache MSF: 72 37 36 1 326661
1007 Cache MSF: 72 37 37 1 326662
1008 Cache MSF: 72 37 38 1 326663
1009 Cache MSF: 72 37 39 1 326664
1010 Cache MSF: 72 37 40 1 326665
1011 Cache MSF: 72 37 41 1 326666
1012 Cache MSF: 72 37 42 1 326667
1013 Cache MSF: 72 37 43 1 326668
1014 Cache MSF: 72 37 44 1 326669
1015 Cache MSF: 72 37 45 1 326670
1016 Cache MSF: 72 37 46 1 326671
1017 Cache MSF: 72 37 47 1 326672
1018 Cache MSF: 72 37 48 1 326673
1019 Cache MSF: 72 37 49 1 326674
1020 Cache MSF: 72 37 50 1 326675
1021 Cache MSF: 72 37 51 1 326676

The results differ from run to run. You have to parse the cache buffer and manually extract data from there (skipping wrong cache entries). I saw that after few hundreds cache reads device's buffer wraps up and starts giving data from the beginning (it looks like cyclic buffer).

The critical thing here is to read sectors in batch to fill the cache. I think ct = 20 looks like a sweet spot and allows to read discs with big offsets.

Please implement the changes.

47

(3,497 replies, posted in General discussion)

ASUS F1 command:
"Only 1 sector is overread if combined offset is plus, so offset +588 or more has not supported yet"

I think it'd be best if you aborted the DIC in case disc has bigger offset because ATM it created wrong dumps.

I checked source code and have few questions:

ReadCDForCheckingReadInOut:

ReadCacheForLgAsus(pExtArg, pDevice, pDisc, 1)

Why are you reading LBA 1 into cache? Shouldn't it be last LBA?

ReadCacheForLgAsus:

DWORD dwSize = 0xb00 * 4;

CDB::_CDB10 cdb = {};
cdb.OperationCode = 0xf1;
cdb.Reserved1 = 3;
cdb.LogicalBlockByte0 = BYTE((0xb00 * nLBA >> 24) & 0xff);
cdb.LogicalBlockByte1 = BYTE((0xb00 * nLBA >> 16) & 0xff);
cdb.LogicalBlockByte2 = BYTE((0xb00 * nLBA >> 8) & 0xff);
cdb.LogicalBlockByte3 = BYTE(0xb00 * nLBA & 0xff);
//cdb.TransferBlocksLsb = 0x0b;
//cdb.Control = 0x00;
cdb.Reserved2 = BYTE((dwSize >> 24) & 0xff);
cdb.TransferBlocksMsb = BYTE((dwSize >> 16) & 0xff);
cdb.TransferBlocksLsb = BYTE((dwSize >> 8) & 0xff);
cdb.Control = BYTE(dwSize & 0xff);

This way you can read more sectors (4)?

ReadCDAll:

    if (pDevice->by0xF1Drive && pDisc->SCSI.nAllLength <= nLBA) {
    memcpy(pDiscPerSector->data.current, pDisc->lpCachedBuf, 2352);
    memcpy(pDiscPerSector->data.current + 2352, pDisc->lpCachedBuf + 0x9A4, 294);
    memcpy(pDiscPerSector->data.current + 2352 + 294, pDisc->lpCachedBuf + 2352, 96);
    AlignRowSubcode(pDiscPerSector->subcode.current, pDisc->lpCachedBuf + 2352);

lpCachedBuff should be indexed with nLBA * 0xB00?

Last question:
You read LBA 1 into cache and now you access this buffer when trying to use this data for nLBA (lead out). It this correct?

I have disc with offset +1611 and can't dump it correctly. Please fix smile

48

(3,497 replies, posted in General discussion)

Sarami, I just got ASUS BW-16D1HT and tried to rip disc with big positive offset: 1611. Last sector of last track is different than Plextor 760. Is it expected? What's the biggest positive offset that ASUS is able to handle?

49

(10 replies, posted in General discussion)

All my plextors spit these C2 errors and none of my non-plextor drives do so. In such cases I use data command from two different non-plextor drives and manually patch & compare the tracks. It's unfixable on plextors.

Many Polish discs from 2000-2002 with -153 write offset suffer from this bug.

50

(10 replies, posted in General discussion)

Check c2 file. If the pattern is F0F0F0 and 0F0F0F it means it's known Plextor firmware bug. Use different drive to get the data and replace it with hex editor.