51 Reply by scsi_wuzzy

(33 replies, posted in General discussion)

Jackal wrote:

Try clonecd with a non-plextor drive. It should read single errors and the error sectors are 5 sectors apart, or a multiple of 5 sectors IIRC. That's how you'll know if the dump is correct.

I got hold of an Optiarc drive, and I'm currently dumping the disc with that. Right now I'm using Alcohol, but I plan to try CloneCD and probably CD Manipulator as well.

Right now it looks there's...kind of a pattern? Maybe multiple patterns separated by larger groups of good sectors? It starts off with 3 bad sectors, 8 good sectors, 3 bad sectors.

But then there're 23 good sectors and a pattern starts with 3 good, 3 bad, 3 good.

Then 23 good sectors and a pattern of 3 bad, 13 good, 3 bad, 8 good, 3 bad, 3 good...

There's definitely some kinda pattern. I'll look at it in more detail once it's done and post an update. And, as I said, I'll dump in other software as well.

Edit: The Alcohol read got done. Errors look like they're always groups of three, and lots of sectors that were reported as "bad" by my Asus weren't reported bad here. Based on the description here, though, it sounds like maybe the Asus rip is good? At initial glance, it looks like all the Asus errors are in groups of 5, 10, or 15 sectors. So, if they're meant to be a multiple of 5, that sounds right. But then the Optiarc has substantially fewer errors...all groups of 3 with varying distances between them.

Edit 2: Here is the list of bad sectors from CDMage for both the Asus and the Optiarc: https://www.dropbox.com/s/8eu918bz0jg07 … 20.7z?dl=0. The Asus has 3779 bad sectors, in groups of 5, 10, or 15. The Optiarc has 2281 bad sectors, in groups of 3.

Edit 3: If I look at one of the sectors that the Asus errors on but the Optiarc doesn't, like sector 2464 for example, the data section is all 0. If I look at one near there that they both read successfully, like 2466, it's all 0 also.

Edit 4: Using CD Manipulator, I got 2,274 errors. I think each error is a three sector block. 2,274 / 3 = 758, which is the number of errors for one of the European releases of Tropico: http://redump.org/disc/53929/. Is that just a coincidence, though?

Go to forum: General discussion

52 Reply by scsi_wuzzy

(3 replies, posted in General discussion)

reentrant wrote:

I have few discs which have misaligned audio data. You see it because Plextor with help of D8 command can detect data offset within disc (remember that all cds are just audio with "pasted" data + ecc on top of it) and it properly aligns audio data following data track.

For non Plextor drives depending on read offset you might see it or not. Drives with bigger / smaller read offets can mask it so you won't see it.

Anyway looks like "mastering issue"...

Thanks, I kinda suspected something along those lines. I ended up comparing the audio by concatenating all the raw files from CUERipper and offsetting it to where the audio is located in the .img file. That made the track offset problem disappear.

It turned out the audio matched except for a couple bits at the very end, and I suspect that's a drive offset issue (probably one of the drives dropped off the last few samples due to the sample offset). So, looks like it's a good dump.

The disc itself definitely seems like it's not the highest quality master. The mastering ring doesn't have anything except the text "IFPI.CO-02" -- strangest ring I've seen.

Go to forum: General discussion

53 Topic by scsi_wuzzy

(3 replies, posted in General discussion)

I'm doing some troubleshooting on a disc that for some reason is nearly unreadable on all my Plextor drives (despite it being in what appears to be perfectly fine condition). It dumps just fine with Alcohol on my LG drives, but the PX-760A and both the PX-716AL drives just rattle and can't read it. The Premium can read it, but it struggles a lot and often crashes DIC.

The disc is a copy of the PC game "Rollcage." I found it second hand ages ago, and I don't even know what region it is. It indicates on the disc that it's in English, so it's probably not a North American release (most of my CDs are), but it also doesn't seem to match the Europe copies in the database. It has 9 tracks like the ASUS OEM release, and the data track matches, but none of the audio tracks match and the mastering ring / serial is different.

I was finally able to get a dump from the Premium. Since it struggled severely, I wanted to be paranoid and check the dumped audio against what the LG dumped using CUERipper. So, I converted the first audio track from CUERipper to raw signed 16 bit audio (via ffmpeg), and I opened up both the DIC bin output of the first audio track and my converted file in HxD. Based on the leading zeroes in both files (as seen in HxD), I used the hex editor to manually adjust the offset in the CUERipper track to match the DIC one. I also truncated the CUERipper track to the length of the track output by DIC (the lengths of the tracks were different both before and after padding to correct the offset). After that, the files matched (compared with fc.exe).

Cool, looks like probably the first audio track was dumped correctly despite the Plextor's struggles. So I move on to the second, expecting to go through the same set of steps. However, when I load up the second audio track from DIC in HxD, there's obviously samples from the first audio track at the beginning of the second one, before the 2 second silence. Importing the raw audio in Audacity shows that, indeed, there's a very short click of audio on the track before the 2 second silence. The CUERipper files don't seem to have any of this overlap (but it looks like there's instead overlap of the pregap).

I expected the offsets to be different between CUERipper and DIC (though, honestly, I'm not sure why except I gather it has something to do with offsetting the audio relative to the data track, whereas CUERipper is just concerned with offsetting the audio samples so that it matches other drives when dumping audio data). However, I didn't expect to find samples from the end of the previous audio track at the beginning of the next. Is this normal? Is it something I need to investigate further, or is it maybe just a common mastering error where some number of samples are misaligned?

Forgive me if this is an extremely obvious question to the more experienced rippers, but I've been dumping PC games and relatively few of them have been "enhanced" CDs, so I haven't looked into it previously. I may try to follow the old dumping guide to see if I get the same results as DIC (http://wiki.redump.org/index.php?title= … acks_(Old)), but all the images in the guide are dead so some of it isn't entirely clear to me.

Go to forum: General discussion

54 Reply by scsi_wuzzy

(4 replies, posted in General discussion)

This actually helped me out when I was curious about the second-hand Plextor I got a while back. I didn't know QPxTool had this information. FYI, it looks like the "discs loaded" counter stops at 100,000. Either that or it was just coincidentally the 100,000 disc, but I doubt it.

Is there any rule of thumb for how many hours the OPU should last? I think the drive is at only about 500 hours of reading or so, IIRC (don't have it in front of me right now), despite having been fed so many discs.

Go to forum: General discussion

55 Reply by scsi_wuzzy

(33 replies, posted in General discussion)

LoStraniero91 wrote:

I've only dealt with CodeLock once, and I can tell you it's a weird one: it's a mixture of both LaserLock (due of the rings) and SafeDisc (due of the errors being in a pattern instead of all bunched up together like your everyday ring protection).
Your best bet to dump a CodeLock protected game is to use CloneCD with a non-Plextor drive.

I think Jackal will be able to assist you even better.

Thanks, this is helpful! It turns out there are actually some details I missed in the redump Wiki about CodeLock as well. I think I must've searched for "Code Lock" (with a space) previously, since that's what Burnout calls it, but the Wiki has some details buried in an article on CodeLock.

Indeed, based on what the Wiki says, Plextors are known to have issues with this protection. I've ordered a cheap Optiarc drive, since it sounds like maybe they're a good bet for this type of protection. Hopefully it won't still take 18 hours of reading to work like my LG did, lol!

Go to forum: General discussion

56 Reply by scsi_wuzzy

(33 replies, posted in General discussion)

Nexy wrote:

I gave up trying to dump discs with these protections as the results are inconsistent and we have no way of knowing if the dump is good or not.

I don't know anything about Laserlock or CD Ring Protect, but I'm kinda getting the feeling that, for this disc, it would probably be best to just completely ignore every sector on which the protected file exists and replace those with 0x55 sectors in the image file. I'm not convinced there's any real data in that region at all. I may build such an image and see if it works to satisfy the CD check in a disc emulator. Such an image wouldn't be "archival" quality, I guess (although, if there's not any real data there anyway, maybe it is?).

In any case, right now I'm just dumping for my own purposes and not submitting my dumps to the database, so "working" is probably good enough. I've come across a few of my personal discs where I couldn't get "archival" quality dumps, but I think this is the first one that's due to the copy protection and not just due to the disc being damaged.

Go to forum: General discussion

57 Topic by scsi_wuzzy

(33 replies, posted in General discussion)

I've got a copy of Tropico for PC that I'm having issues dumping. I believe it's a US copy, but it doesn't appear to match the copy in the database.

BurnOut says the disc has "Code Lock" copy protection. I couldn't find anything about that protection online, but it seems to be similar to SafeDisc in that there are a number of intentional bad sectors on the disc. One thing that is bizarre about this disc, that I've never seen with any of the other discs I've dumped, is that you can physically see where the error sectors are on the disc. There's a line, maybe about 2mm wide, where the silver is a completely different color. It's maybe 3-4mm from the start of the data on the disc. I've ripped tons of discs with SafeDisc, etc. and I've never seen one before where I could physically see the defects, so this is something new for me. It looks similar to...you know how some manufactured discs you can see a line where the data ends? It's like that, except in the data and very narrow. I know it sounds like some kind of disc rot or something, but I really don't think it is. The disc looks good and all the files can be copied without issue.

So far, I've tried to dump the disc with DiscImageCreator on a PX-760A and a PX-716AL and with Alcohol 120% on an ASUS BD drive and a LG BD drive. DIC reports that there is in fact a protected file, and the 716 and 760 both report C2 errors, though not with a consistent number of bits (in contrast to SafeDisc where you generally see 312 bit C2 errors). Here's what is in the C2 log from the 716AL: https://pastebin.com/DQntkqMr

Also note that this list of errors is different between rips. The number of C2 bits is different, but also the reported list of sectors is different (e.g., the above list includes LBA 10022, but other times I rip that sector won't be there). Here it is when I ripped with the 716AL again (at a different speed): https://pastebin.com/tvQnSVt9

The the list is also different between rips when I use the 760A -- neither can produce a consistent image.

The even bigger problem, though, is that the resulting image produced by DIC is unusable. Despite the fact that it looks like all the reported C2 errors are intentional, if I open the image with CDMage, it reports that the "Data track has errors in the file system" and none of the files are present. However, the disc itself is in fairly good shape, and, as I mentioned previously, I'm able to copy all the files off without issue.

Additionally, I was able to image the disc with Alcohol 120%, and it produced an image with no filesystem errors (just errors corresponding to the protection sectors). However, it looks like even Alcohol 120% probably won't be able to reliably image the disc. I've just started imaging on another drive (it takes like 16+ hours to image the disc due to the errors -- I started it one night before I went to bed, expecting to see the results in the morning, but it was still running when I got up and for most of the rest of the day), and so far the reported error sectors don't look like they map to what is present in the image I already made.

Does anyone have any experience / advice on how to properly dump this disc?

On another note, Alcohol sometimes reports "Disc read error" and sometimes reports "Read data examination error." Does anyone know the difference between these two errors?

Edit: I forgot to link the log files! Here are the logs from the 716AL ripping at 8x: https://www.dropbox.com/s/xjmwh5diirdkr … gs.7z?dl=0. ECCEDC reports a mix of bad MSF, user data doesn't match, and invalid sync for the protected sectors.

Go to forum: General discussion

58 Reply by scsi_wuzzy

(12 replies, posted in General discussion)

Nextria wrote:

Hey,

If you can open up Your 716, and look at the laser head. There should be a part number.
Maybe it’s the same as for the 708.

Unfortunately, it's not. Nobody seems to even know with certainty who made the laser for the 716. The part number is SRU 3541. There's a brief discussion about it on Myce https://club.myce.com/t/replacement-for … a/314376/8, and the basically the verdict at that time was that if your 716 needs a laser, throw it in the trash or keep in the closet in hopes somebody, someday, finds a source for them.

I've been avoiding 716 units ever since I learned that, as even if they have some advantages, I'd rather have units that have parts available. They're apparently also quite fragile -- lots of complaints online about how short the life of the 716 is. It was apparently even an issue back when they were new -- one person on Myce or somewhere else went through multiple warranty replacements on his new unit, as the lasers kept dying. That could be an outlier case, of course, but it seems like they're pretty unreliable.

Go to forum: General discussion

59 Reply by scsi_wuzzy

(12 replies, posted in General discussion)

wiggy2k wrote:

I finally got around to testing my pile of plextors. (like ~25 drives) the other day.

by far the biggest failure rate was from the PX-708A and PX-716A drives that i had piled up.
100% failure from the PX-708A   (1/1 drives faulty)
50% failure rate from the PX-716A (3 of 6 were completely knackered)

but then again the one PX-716UF I have has been a really stable drive.

I'm, unfortunately, not surprised. I wasn't familiar with the durability issues of the 700-series drives until I purchased my troubled PX-716AL drives, but it's apparently a somewhat known issue. I noticed that someone added a warning to the Redump Wiki about these drives:

The Plextors in the 700 range that can read DVDs have firmware bugs and the lasers can go bad easily.

It's a shame, because the 716 was quite well received in its day, AFAIK. Even now, my barely working 716AL sometimes has more accurate C2 reporting than the 760 I use as my main ripper. I had multiple discs recently that exhibited no C2 errors but had defective sectors from the 760. The 716 reported C2 errors on the same sectors and successfully re-read. But, I think replacement lasers for the 755/760 are widely available, while nobody seems to be able to source one for the 716.

Go to forum: General discussion

60 Topic by scsi_wuzzy

(8 replies, posted in General discussion)

I've on-and-off thought for some time about the possibility of modifying firmwares to enable scrambled reads on other models of drives.

It seems like it should be possible in theory, as a number of drives don't have any kind of firmware signature and can seemingly be freely modified (e.g., all the RPC-1 hacks, riplock removal hacks, etc. for a bunch of TSST and other MediaTek drives). Hell, there might be some firmware out there in some drive that has the scramble table easily accessible in the firmware, in which case it might be possible to just zero out the table and have a drive that can only do scrambled reads.

I'm curious if anyone is looking into this / has looked into this in the past? I've been going through a lot of Plextor drives, so I'm mostly wondering aloud if anyone feels like an alternative might one day exist. It's neat that some newer drives (like the BW-16D1HT) can do scrambled reads, but it seems as though they still pale in comparison compared to the Plextor drives (issues finding offset, etc.).

Go to forum: General discussion

61 Reply by scsi_wuzzy

(12 replies, posted in General discussion)

Nextria wrote:

Hello,

I know you looking for a fix in the UK, but for the PX-708(UF) i bought
a new laser aliexpress https://nl.aliexpress.com/item/32964380 … 4c4dT8bKnV

I can confirm they working great, i bought my 708 and it came with a dead laser,
Replaced it and it is working great again!

for 10 euro you can not go wrong.

Does anyone know if a replacement laser / OPU is available for the 716 anywhere? I recall a thread on MyCE some years back where several were lamenting being unable to find 716 parts, but I haven't kept up to see if anything has changed in recent times. I've two 716AL that are working except the OPU seems to be nearly dead and (more and more frequently) they decide they'd rather just not read anymore.

Also, what the hell happened to Plextor with the 700 series drives? It seems like my Ultraplex 40 will last until the end of days, but it seems like I'm going to have a bin of dead 716 and 760 drives by the time I'm done with my dumping.

Go to forum: General discussion

62 Topic by scsi_wuzzy

(1 replies, posted in Guests & account requests)

I'm requesting a Wiki account. I'm submitting games from the "Undumped Games" lists, and I'd like to be able to remove them as I go.

Thanks. Let me know if you need anything else.

Go to forum: Guests & account requests

63 Reply by scsi_wuzzy

(6 replies, posted in General discussion)

F1ReB4LL wrote:

It is different, hence the "R" (reprint/revised/whatever).

wiggy2k wrote:

they might have actually fixed the issue with cold booting the console with BUG! in the drive.

I've compared both images before and, IIRC, the only thing that was fixed is the serial number in the header (GM-81004 was fixed to MK-81004). But it's still quite an interesting change to be preserved smile

Yeah, I converted both versions into 2048 sector images, and a binary compare indicates only two bytes different, and it is in fact a G changing to an M and a M changing to a K. Just as you remembered.

In any case, I'll hopefully get a change to submit it later in the week.

Go to forum: General discussion

64 Reply by scsi_wuzzy

(6 replies, posted in General discussion)

iR0b0t wrote:

It is supposed to make 5 loops and will finish reading at some point for sure.

F1ReB4LL wrote:

It reads the disc subs 5 times, then combines the results and tries to reread the damaged sectors. You can open the logfile with Far Manager or similar and watch the process in real time.


Thanks for the responses! Sure enough, I was just impatient. It stopped after 5 passes.


On another note, it looks like the SATURN81004R version of Bug! is actually different from the variant in the database. Track 1 is same size, but CRC differs. Track 2 and many others are a different size. However, build date and version number match http://redump.org/disc/20332/ I'm gonna do some additional checking before I submit, though, so I don't make an ass of myself.

Go to forum: General discussion

65 Topic by scsi_wuzzy

(6 replies, posted in General discussion)

I've got a couple of the undumped NA discs that I want to dump (Bug! with the SATURN81004R ring code, Gridrunner, etc.)

So far I've tried dumping two discs, both in what appears to be good condition. While DIC reports "No C2 errors" for both, DICUI launches subdump.exe after DIC, and subdump.exe seems to run forever, dumping the subs over and over again. I end up with a number of "[title]_subdump_1.sub", "[title]_subdump_2.sub", "[title]_subdump_3.sub", etc files all the same size (but not with matching hashes).

Is this normal? Looking at the log, it looks like subdump is convinced there are some reading errors, and it's re-reading over and over. But, like I said, these discs are in quite good condition, and DIC reports no C2 errors, so I find this a bit odd.

Drive: PX-760A
Subdump Log (for Bug!): https://www.dropbox.com/s/o7nftgipf184j … p.log?dl=0
Other logs (for Bug!): https://www.dropbox.com/s/6ojbd8b42ijtiqj/BUG.7z?dl=0


Subdump was actually still running when I copied its log file.

Go to forum: General discussion

66 Reply by scsi_wuzzy

(6 replies, posted in General discussion)

Sorry for the triple post, but it appears to have been a bug with DIC. I copied the new DIC executable over top of the version included in DICUI, and the hash for disc 1 now matches what's in the DB.

Now I gotta go see what else I need to redump.


Edit: If anyone wants to see the logs for the new dumps and compare with the old, let me know. I can upload them.

Go to forum: General discussion

67 Reply by scsi_wuzzy

(6 replies, posted in General discussion)

Landcross wrote:

A few days ago I had some problems with SecuROM and my Plextor 760A. Jackal posted about it here: http://forum.redump.org/post/62811/#p62811

I don't know very much about this stuff, but maybe it was the same problem as you have. The issue has been fixed (at least in my case) in the newest DIC. Try updating DIC to the newest version and see if that fixes the issue. The newest version can be downloaded here: https://github.com/saramibreak/DiscImag … g/20180828

If you're already on that version, than you need someone with actual knowledge about this stuff, not me wink

Thanks for the heads up. I'll drop in the new DIC into the DICIUI folder. Hopefully I don't have to go back and redump a bunch of stuff.

Edit: Apparently dropping in the newest CSS / DiscImageCreator / EDCECC causes DICUI to now crash after the dump, when it's collecting data for the submissioninfo file. Interesting.

Edit2: Looks like the crash is probably unrelated to the change in DIC. I think DICUI just crashes with that disc. Just installed VS Community to troubleshoot.

Go to forum: General discussion

68 Reply by scsi_wuzzy

(6 replies, posted in General discussion)

user7 wrote:

Can you post your logs for the example you referred to: http://redump.org/disc/12832/

I've compressed everything from the dump except the actual data. I was just going to post on Pastebin or similar, but some logs (like the EdcEcc output) are huge. https://www.dropbox.com/s/578x418z8712h … _1.7z?dl=0

reentrant wrote:

ECC checker should not replace sectors for such discs with 0x55. For most cases it's just different mode sector perfectly readable by optical drive. Are you sure the differences stem from that single sector near the end of the disc?

It's possible I was getting some parts of SafeDisc and SecuROM confused in my discussion. However, there are in fact sectors getting replaced with 0x55 in this dump. I dumped it again, and the hashes for both the raw scrambled data and descrambled data matched. Initially I thought maybe that, if there are read errors (though I would expect C2 errors if that was the case, and there aren't any), maybe the hashes were just matching because the error sectors were being replaced with identical data between reads. However, since the raw scrambled data matches, I believe this means that the reads are consistent.

The disc looks good, in terms of condition. I'm wondering if there are some weird mastering/manufacturing errors, perhaps.

Go to forum: General discussion

69 Topic by scsi_wuzzy

(6 replies, posted in General discussion)

I've been going through and dumping all my PC games, and I've noticed that a number of SecuROM protected discs don't end up with hashes matching the ones in the database. For multi-disc games, this often only happens for the SecuROM protected discs. For example, I just dumped Aliens Versus Predator 2, and my Disc 1 (which has SecuROM) has a matching size but not a matching hash when compared with http://redump.org/disc/12832/. Disc 2 (which doesn't have SecuROM) has a matching size and hash. While it's certainly possible it's just a pressing difference (my Disc 1 is manufactured by TECHNICOLOR just like the one in the database, and has the same IFPI number, but some parts of the mastering ring differ), I've seen this with several discs so I wanted to inquire. I know that the current DICUI releases run the ECC checker and it replaces the bad sectors (SecuROM sectors) with dummy data. Is it possible that some entries predate this dummy data replacement, or that maybe some other dummy data was used? Or is this definitely a pressing difference?

My setup: Dumping with DICUI and a Plextor PX-760A. I've tried redumping discs that don't match, and I've always gotten identical hashes between the two dumps. No unintentional C2 errors reported by the drive. When checking hashes, I'm using the "!submissioninfo" file generated by DICUI. I've also hashed with 7-ZIP and got the same thing.


Edit: I think this was a bug with DIC. I updated to the newest release and got a matching hash.

Go to forum: General discussion

70 Reply by scsi_wuzzy

(3,497 replies, posted in General discussion)

sarami wrote:

I bought a 1210S and tested and confirmed that offsets was different in 0xd8(subch 02[main+sub] and 08[main+c2+sub])
Coded.

What SCSI card are you using? I've tried two different Adaptec card models, and at least two different 1210S drives, and every combination suffers from repeated bus resets in Windows 7. In contrast, things work fine in Windows XP or Debian Linux under the same configurations. That's why many of my 1210S tests were performed under Windows XP. The 40TS behaves nicely in Windows 7.

Go to forum: General discussion

71 Reply by scsi_wuzzy

(3 replies, posted in General discussion)

mock wrote:

That's not the lead-in, that's the track 1 pregap. The lead-in comes before that.

I guess I'm confused then. When we refer to a drive's ability to over-read into lead-in, are we actually talking about pregap? For example, the DAE Features site refers to drives which can over-read into Lead-In, Lead-Out, or Both. Can any drives actually return all the raw, scrambled sectors from the lead-in and lead-out, or are we always talking about gaps? It seems like my Plextor drives won't return the whole lead-in, anyway, because I can't get anywhere near the proper number of sectors prior to the first track. At least, not using px_d8.

Basically what I'm trying to figure out is if it's useful at all that this old SAF drive can read scrambled sectors that no other drives I've tested have been able to read. I think the perfect drive would be able to dump raw, scrambled sectors (with subcodes) all the way from the lead-in to the lead-out, but I'm not sure any drive can actually do that.

Edit: So it looks like Truman's Cdtool can read all the way back to sector #1 on the PX716AL, so I guess the limitation in reading lead-in is just present when using the 0xD8 read command?

And we can read subchannel data from the lead-in, too, which means we can actually just dump raw TOC data from the subchannel, right? Is there some advantage that cuesheets have over raw TOC data dumps from the lead-in subchannel data?

Go to forum: General discussion

72 Topic by scsi_wuzzy

(3 replies, posted in General discussion)

Is it possible that some drives support reading further into the lead-in than others? My understanding is that the lead-in is 150 sectors (2 seconds), but all the Plextor drives I've tested using px_d8 1.0 won't read any sectors lower than -75. However, today I discovered that an old Smart & Friendly brand drive supports scrambled reads (using px_d8) to -127 on my Nights into Dreams (USA) disc.

Specifically, the lowest sector I can read with the PX-716AL is the one with preamble:

00FFFFFFFFFFFFFFFFFFFF0001807361

But the SAF can fetch:

00FFFFFFFFFFFFFFFFFFFF0001801961

Are there any discs which need sectors dumped from lower addresses than Plextors can do? If so, it looks like SAF drives might work.

Go to forum: General discussion

73 Reply by scsi_wuzzy

(3,497 replies, posted in General discussion)

sarami wrote:
scsi_wuzzy wrote:
px_d8 i 0
px_d8 i 0 2
px_d8 i 0 1

How about the result of px_d8 details in 1210S and other plextor?
  Sector: ??
  MSF: ??:??:??
  Combined offset: ??? bytes / ??? samples

Sorry, I was unclear. I was running the original px_d8 utility and looking at the raw sector data, just to verify the same data is returned regardless of whether a sector is read with or without subcodes, with no change in offset:

px_d8 i 0:
3C6751EABC4F31F414474F72B425B75B
36BB56F37EC5E053083DC69192EC6D8D
EDA58DBB25B35B35FB57037E81E06048
28369E96E86ECEAC547DFF618028601E
A8087E86A062F829829EE1A8487EB6A0
76F826C29AD1AB1C7F49E036C816D68E
DEE4584B7AB76336A9D6FEDEC058503A
BC1331CDD4559F7F28201E98086A86AF
22FC1981CAE057083E869062EC298DDE
E5984B2AB75F36B816F28EC5A4533B7D
D3619DE8698EAEE47C4B61F76846AEB2
FC7581E7204A98372A969F2EE81C4E89
F466C76AD2AF1DBC09B1C6F452C77D92
A1ADB87DB2A1B5B87732A695BAEF330C
15C5CF13140DCF4594332F55DC3F19D0
0ADC0719C28AD1A71C7A89E326C9DAD6
DB1EDB485B76BB66F36AC5EF130C0DC5
C593132DCDDD9599AF2AFC1F01C80056
803EE010480C3685D6E31EC9C856D6BE
DEF058443AB35335FDD7019E8068602E
A81C7E89E066C82AD69F1EE8084E86B4
62F76986AEE2FC4981F6E046C832D695
9EEF284C1EB5C87716A68EFAE4430B71
C76452AB7DBF61B028741EA7487AB6A3
36F9D6C2DED1985C6AB9EF32CC1595CF
2F141C0F49C436D356DDFED9805AE03B
0813468DF2E5858B232759DABADB331B
55CB7F17600EA8047E836061E8284E9E
B468776EA6AC7AFDE30189C066D02ADC
1F19C80AD6871EE28849A6B6FAF6C306
D1C2DC5199FC6AC1EF104C0C35C5D713
1E8DC86596AB2EFF5C4039F012C40D93
45ADF33D85D1A31C79C9E2D6C99ED6E8
5ECEB85472BF65B02B341F57483EB690
76EC26CDDAD59B1F2B481F768826E69A
CAEB170F4E8434635769FEAEC07C5021
FC1841CAB057343E97506EBC2C71DDE4
598B7AE7630AA9C73ED2905DAC39BDD2
F19D8469A36EF9EC42CDF195846F236C
19EDCACD9715AE8F3C6411EB4C4F75F4
27075A82BB21B35875FAA7033A81D320
5DD8399A92EB2D8F5DA439BB52F37D85
E1A30879C6A2D2F99D82E9A18EF86442
AB71BF64702B641F6B482F769C26E9DA
CEDB145B4F7B74236759EABACF331415
CF4F14340F57443EB35075FC2701DA80
5B203B58137A8DE32589DB26DB5ADB7B
1B634B69F76EC6AC52FDFD8181A06078
28229E99A86AFEAF007C0021C018500A
BC0731C29451AF7C7C21E1D8485AB6BB
36F356C5FED3005DC0399012EC0D8DC5
A5933B2DD35D9DF9A982FEE180486036
A816FE8EC064502B7C1F61C828569EBE
E8704EA4347B57637EA9E07EC8205698
3EEA904F2C341DD7499EB6E876CEA6D4
7ADF631829CA9ED7285E9EB86872AEA5
BC7B31E35449FF76C026D01ADC0B19C7
4AD2B71DB689B6E6F6CAC6D712DE8D98
65AAAB3F3F50103C0C11C5CC5315FDCF
0194006F402C301DD4099F46E832CE95
946F2F6C1C2DC9DD96D9AEDAFC5B01FB
40437031E4144B4F777426A75AFABB03
3341D5F05F0438035281FDA041B83072
9425AF5B3C3B51D37C5DE1F98842E6B1
8AF467076A82AF21BC1871CAA4573B7E
93606DE82D8E9DA469BB6EF36C45EDF3
0D85C5A31339CDD2D59D9F29A81EFE88
4066B02AF41F074802B681B6E076C826
D69ADEEB184F4AB437375696BEEEF04C
4435F35705FE830061C028501EBC0871
C6A452FB7D8361A1E8784EA2B479B762
F6A986FEE2C0499036EC16CDCED5945F
2F781C2289D9A6DAFADB031B41CB7057
643EAB507F7C2021D8185A8ABB27335A
95FB2F035C01F9C042D0319C1469CF6E
D42C5F5DF8398292E1AD887DA6A1BAF8
7302A5C1BB10734C25F5DB071B428B71
A7647AAB633F69D02EDC1C59C9FAD6C3
1ED1C85C56B9FEF2C04590332C15DDCF
19940AEF470C3285D5A31F39C812D68D
9EE5A84B3EB75076BC26F1DAC45B137B
4DE37589E726CA9AD72B1E9F486836AE
96FC6EC1EC504DFC3581D7205E98386A
92AF2DBC1DB1C9B456F77EC6A052F83D
8291A1AC787DE2A189B866F2AAC5BF13
300DD4059F432831DE94586F7AAC233D
D9D19ADC6B19EF4ACC3715D68F1EE408
4B46B772F6A586FB22C35991FAEC430D
F1C58453237DD9E19AC86B16AF4EFC34
41D7705EA4387B52A37DB9E1B2C87596
A72EFA9C4329F1DEC458537ABDE33189
D466DF6AD82F1A9C0B29C75ED2B85DB2
B9B5B2F735869722EE998C6AE5EF0B0C
0745C2B311B5CC7715E68F0AE4070B42
8771A2A479BB62F36985EEE30C49C5F6
D306DDC2D9919AEC6B0DEF458C3325D5
DB1F1B480B768766E2AAC9BF16F00EC4
0453437DF1E184486376A9E6FECAC057
103E8C1065CC2B15DF4F18340A97472E
B29C75A9E73ECA90572C3E9DD0699C2E
E9DC4ED9F45AC77B12A34DB9F5B2C735
92972DAE9DBC69B1EEF44C4775F2A705
BA833321D5D85F1AB80B328755A2BF39
B012F40D8745A2B339B5D2F71D8689A2
E6F98AC2E7118A8C6725EA9B0F2B441F
734825F69B06EB42CF7194246F5B6C3B
6DD36D9DEDA98DBEE5B04B34375756BE
BEF0704424335B55FB7F036001E8004E
80346017680EAE847C6361E9E84ECEB4
54777F66A02AF81F028801A6807AE023
0819C68AD2E71D8A89A726FA9AC32B11
DF4C5835FA97032E81DC6059E83ACE93
146DCF6D942DAF5DBC39B1D2F45D8779
A2A2F9B982F2E185886326A9DAFEDB00
5B403B7013640DEB458F732425DB5B1B
7B4B637769E6AECAFC5701FE80406030
32407802486436AB56FF7EC020A544C9
0A91C72C529DFDA981BEE0704824369B
56EB7ECF6054283F5E90386C12ADCDBD
95B1AF347C1761CEA8547EBF60702824
1E9B486B76AF66FC2AC1DF10580C3A85
D3231DD9C99AF817B445485436BF56F0
3EC410A762C9F5D1871C6289E9A6CEFA
D4431F71C824569B7EEB604F68342E97
5C6EB9EC72CDE5958B2F275C1AB9CB32
D7559EBF28701EA4087B46A372F9E582
CB2197586EBAAC733DE5D18B28CF85ED
B6CF36D416DF4ED834F4977B2EA35C79
F9E2C2C99196EC6ECDEC558DFF25CACB
7C9257BB6377A321B9D872DAA59B3B2B
535F7DF821820804E22BA776A0BF780C
2285D9A31AF9CB02D7419EB068742EA7
5C7A95BEDE8E38D1F273D81C5A89FB26
C35AD1FB1C4349F1F6C48A43145F4F24
00FFFFFFFFFFFFFFFFFFFF0001817361
0028001E80086006A802FE8180606028
281E9E886866AEAAFC7F01E000480036
8016E00EC80456837EE1E0484836B696
F6EEC6CC52D5FD9F01A8007E80206018
280A9E8728629EA9A87EFEA040783022
9419AF4AFC3701D6805EE0384812B68D
B6E5B6CB36D756DEBED8705AA43B3B53
537DFDE181886066A82AFE9F0068002E
801C6009E806CE82D4619F68682EAE9C
7C69E1EEC84C56B5FEF700468032E015
880F26841AE34B09F746C6B2D2F59D87
29A29EF9A842FEB180746027681AAE8B
px_d8 i 0: 1
3C6751EABC4F31F414474F72B425B75B
36BB56F37EC5E053083DC69192EC6D8D
EDA58DBB25B35B35FB57037E81E06048
28369E96E86ECEAC547DFF618028601E
A8087E86A062F829829EE1A8487EB6A0
76F826C29AD1AB1C7F49E036C816D68E
DEE4584B7AB76336A9D6FEDEC058503A
BC1331CDD4559F7F28201E98086A86AF
22FC1981CAE057083E869062EC298DDE
E5984B2AB75F36B816F28EC5A4533B7D
D3619DE8698EAEE47C4B61F76846AEB2
FC7581E7204A98372A969F2EE81C4E89
F466C76AD2AF1DBC09B1C6F452C77D92
A1ADB87DB2A1B5B87732A695BAEF330C
15C5CF13140DCF4594332F55DC3F19D0
0ADC0719C28AD1A71C7A89E326C9DAD6
DB1EDB485B76BB66F36AC5EF130C0DC5
C593132DCDDD9599AF2AFC1F01C80056
803EE010480C3685D6E31EC9C856D6BE
DEF058443AB35335FDD7019E8068602E
A81C7E89E066C82AD69F1EE8084E86B4
62F76986AEE2FC4981F6E046C832D695
9EEF284C1EB5C87716A68EFAE4430B71
C76452AB7DBF61B028741EA7487AB6A3
36F9D6C2DED1985C6AB9EF32CC1595CF
2F141C0F49C436D356DDFED9805AE03B
0813468DF2E5858B232759DABADB331B
55CB7F17600EA8047E836061E8284E9E
B468776EA6AC7AFDE30189C066D02ADC
1F19C80AD6871EE28849A6B6FAF6C306
D1C2DC5199FC6AC1EF104C0C35C5D713
1E8DC86596AB2EFF5C4039F012C40D93
45ADF33D85D1A31C79C9E2D6C99ED6E8
5ECEB85472BF65B02B341F57483EB690
76EC26CDDAD59B1F2B481F768826E69A
CAEB170F4E8434635769FEAEC07C5021
FC1841CAB057343E97506EBC2C71DDE4
598B7AE7630AA9C73ED2905DAC39BDD2
F19D8469A36EF9EC42CDF195846F236C
19EDCACD9715AE8F3C6411EB4C4F75F4
27075A82BB21B35875FAA7033A81D320
5DD8399A92EB2D8F5DA439BB52F37D85
E1A30879C6A2D2F99D82E9A18EF86442
AB71BF64702B641F6B482F769C26E9DA
CEDB145B4F7B74236759EABACF331415
CF4F14340F57443EB35075FC2701DA80
5B203B58137A8DE32589DB26DB5ADB7B
1B634B69F76EC6AC52FDFD8181A06078
28229E99A86AFEAF007C0021C018500A
BC0731C29451AF7C7C21E1D8485AB6BB
36F356C5FED3005DC0399012EC0D8DC5
A5933B2DD35D9DF9A982FEE180486036
A816FE8EC064502B7C1F61C828569EBE
E8704EA4347B57637EA9E07EC8205698
3EEA904F2C341DD7499EB6E876CEA6D4
7ADF631829CA9ED7285E9EB86872AEA5
BC7B31E35449FF76C026D01ADC0B19C7
4AD2B71DB689B6E6F6CAC6D712DE8D98
65AAAB3F3F50103C0C11C5CC5315FDCF
0194006F402C301DD4099F46E832CE95
946F2F6C1C2DC9DD96D9AEDAFC5B01FB
40437031E4144B4F777426A75AFABB03
3341D5F05F0438035281FDA041B83072
9425AF5B3C3B51D37C5DE1F98842E6B1
8AF467076A82AF21BC1871CAA4573B7E
93606DE82D8E9DA469BB6EF36C45EDF3
0D85C5A31339CDD2D59D9F29A81EFE88
4066B02AF41F074802B681B6E076C826
D69ADEEB184F4AB437375696BEEEF04C
4435F35705FE830061C028501EBC0871
C6A452FB7D8361A1E8784EA2B479B762
F6A986FEE2C0499036EC16CDCED5945F
2F781C2289D9A6DAFADB031B41CB7057
643EAB507F7C2021D8185A8ABB27335A
95FB2F035C01F9C042D0319C1469CF6E
D42C5F5DF8398292E1AD887DA6A1BAF8
7302A5C1BB10734C25F5DB071B428B71
A7647AAB633F69D02EDC1C59C9FAD6C3
1ED1C85C56B9FEF2C04590332C15DDCF
19940AEF470C3285D5A31F39C812D68D
9EE5A84B3EB75076BC26F1DAC45B137B
4DE37589E726CA9AD72B1E9F486836AE
96FC6EC1EC504DFC3581D7205E98386A
92AF2DBC1DB1C9B456F77EC6A052F83D
8291A1AC787DE2A189B866F2AAC5BF13
300DD4059F432831DE94586F7AAC233D
D9D19ADC6B19EF4ACC3715D68F1EE408
4B46B772F6A586FB22C35991FAEC430D
F1C58453237DD9E19AC86B16AF4EFC34
41D7705EA4387B52A37DB9E1B2C87596
A72EFA9C4329F1DEC458537ABDE33189
D466DF6AD82F1A9C0B29C75ED2B85DB2
B9B5B2F735869722EE998C6AE5EF0B0C
0745C2B311B5CC7715E68F0AE4070B42
8771A2A479BB62F36985EEE30C49C5F6
D306DDC2D9919AEC6B0DEF458C3325D5
DB1F1B480B768766E2AAC9BF16F00EC4
0453437DF1E184486376A9E6FECAC057
103E8C1065CC2B15DF4F18340A97472E
B29C75A9E73ECA90572C3E9DD0699C2E
E9DC4ED9F45AC77B12A34DB9F5B2C735
92972DAE9DBC69B1EEF44C4775F2A705
BA833321D5D85F1AB80B328755A2BF39
B012F40D8745A2B339B5D2F71D8689A2
E6F98AC2E7118A8C6725EA9B0F2B441F
734825F69B06EB42CF7194246F5B6C3B
6DD36D9DEDA98DBEE5B04B34375756BE
BEF0704424335B55FB7F036001E8004E
80346017680EAE847C6361E9E84ECEB4
54777F66A02AF81F028801A6807AE023
0819C68AD2E71D8A89A726FA9AC32B11
DF4C5835FA97032E81DC6059E83ACE93
146DCF6D942DAF5DBC39B1D2F45D8779
A2A2F9B982F2E185886326A9DAFEDB00
5B403B7013640DEB458F732425DB5B1B
7B4B637769E6AECAFC5701FE80406030
32407802486436AB56FF7EC020A544C9
0A91C72C529DFDA981BEE0704824369B
56EB7ECF6054283F5E90386C12ADCDBD
95B1AF347C1761CEA8547EBF60702824
1E9B486B76AF66FC2AC1DF10580C3A85
D3231DD9C99AF817B445485436BF56F0
3EC410A762C9F5D1871C6289E9A6CEFA
D4431F71C824569B7EEB604F68342E97
5C6EB9EC72CDE5958B2F275C1AB9CB32
D7559EBF28701EA4087B46A372F9E582
CB2197586EBAAC733DE5D18B28CF85ED
B6CF36D416DF4ED834F4977B2EA35C79
F9E2C2C99196EC6ECDEC558DFF25CACB
7C9257BB6377A321B9D872DAA59B3B2B
535F7DF821820804E22BA776A0BF780C
2285D9A31AF9CB02D7419EB068742EA7
5C7A95BEDE8E38D1F273D81C5A89FB26
C35AD1FB1C4349F1F6C48A43145F4F24
00FFFFFFFFFFFFFFFFFFFF0001817361
0028001E80086006A802FE8180606028
281E9E886866AEAAFC7F01E000480036
8016E00EC80456837EE1E0484836B696
F6EEC6CC52D5FD9F01A8007E80206018
280A9E8728629EA9A87EFEA040783022
9419AF4AFC3701D6805EE0384812B68D
B6E5B6CB36D756DEBED8705AA43B3B53
537DFDE181886066A82AFE9F0068002E
801C6009E806CE82D4619F68682EAE9C
7C69E1EEC84C56B5FEF700468032E015
880F26841AE34B09F746C6B2D2F59D87
29A29EF9A842FEB180746027681AAE8B
41010100000000000200283200000000
px_d8 i 0: 2
3C6751EABC4F31F414474F72B425B75B
36BB56F37EC5E053083DC69192EC6D8D
EDA58DBB25B35B35FB57037E81E06048
28369E96E86ECEAC547DFF618028601E
A8087E86A062F829829EE1A8487EB6A0
76F826C29AD1AB1C7F49E036C816D68E
DEE4584B7AB76336A9D6FEDEC058503A
BC1331CDD4559F7F28201E98086A86AF
22FC1981CAE057083E869062EC298DDE
E5984B2AB75F36B816F28EC5A4533B7D
D3619DE8698EAEE47C4B61F76846AEB2
FC7581E7204A98372A969F2EE81C4E89
F466C76AD2AF1DBC09B1C6F452C77D92
A1ADB87DB2A1B5B87732A695BAEF330C
15C5CF13140DCF4594332F55DC3F19D0
0ADC0719C28AD1A71C7A89E326C9DAD6
DB1EDB485B76BB66F36AC5EF130C0DC5
C593132DCDDD9599AF2AFC1F01C80056
803EE010480C3685D6E31EC9C856D6BE
DEF058443AB35335FDD7019E8068602E
A81C7E89E066C82AD69F1EE8084E86B4
62F76986AEE2FC4981F6E046C832D695
9EEF284C1EB5C87716A68EFAE4430B71
C76452AB7DBF61B028741EA7487AB6A3
36F9D6C2DED1985C6AB9EF32CC1595CF
2F141C0F49C436D356DDFED9805AE03B
0813468DF2E5858B232759DABADB331B
55CB7F17600EA8047E836061E8284E9E
B468776EA6AC7AFDE30189C066D02ADC
1F19C80AD6871EE28849A6B6FAF6C306
D1C2DC5199FC6AC1EF104C0C35C5D713
1E8DC86596AB2EFF5C4039F012C40D93
45ADF33D85D1A31C79C9E2D6C99ED6E8
5ECEB85472BF65B02B341F57483EB690
76EC26CDDAD59B1F2B481F768826E69A
CAEB170F4E8434635769FEAEC07C5021
FC1841CAB057343E97506EBC2C71DDE4
598B7AE7630AA9C73ED2905DAC39BDD2
F19D8469A36EF9EC42CDF195846F236C
19EDCACD9715AE8F3C6411EB4C4F75F4
27075A82BB21B35875FAA7033A81D320
5DD8399A92EB2D8F5DA439BB52F37D85
E1A30879C6A2D2F99D82E9A18EF86442
AB71BF64702B641F6B482F769C26E9DA
CEDB145B4F7B74236759EABACF331415
CF4F14340F57443EB35075FC2701DA80
5B203B58137A8DE32589DB26DB5ADB7B
1B634B69F76EC6AC52FDFD8181A06078
28229E99A86AFEAF007C0021C018500A
BC0731C29451AF7C7C21E1D8485AB6BB
36F356C5FED3005DC0399012EC0D8DC5
A5933B2DD35D9DF9A982FEE180486036
A816FE8EC064502B7C1F61C828569EBE
E8704EA4347B57637EA9E07EC8205698
3EEA904F2C341DD7499EB6E876CEA6D4
7ADF631829CA9ED7285E9EB86872AEA5
BC7B31E35449FF76C026D01ADC0B19C7
4AD2B71DB689B6E6F6CAC6D712DE8D98
65AAAB3F3F50103C0C11C5CC5315FDCF
0194006F402C301DD4099F46E832CE95
946F2F6C1C2DC9DD96D9AEDAFC5B01FB
40437031E4144B4F777426A75AFABB03
3341D5F05F0438035281FDA041B83072
9425AF5B3C3B51D37C5DE1F98842E6B1
8AF467076A82AF21BC1871CAA4573B7E
93606DE82D8E9DA469BB6EF36C45EDF3
0D85C5A31339CDD2D59D9F29A81EFE88
4066B02AF41F074802B681B6E076C826
D69ADEEB184F4AB437375696BEEEF04C
4435F35705FE830061C028501EBC0871
C6A452FB7D8361A1E8784EA2B479B762
F6A986FEE2C0499036EC16CDCED5945F
2F781C2289D9A6DAFADB031B41CB7057
643EAB507F7C2021D8185A8ABB27335A
95FB2F035C01F9C042D0319C1469CF6E
D42C5F5DF8398292E1AD887DA6A1BAF8
7302A5C1BB10734C25F5DB071B428B71
A7647AAB633F69D02EDC1C59C9FAD6C3
1ED1C85C56B9FEF2C04590332C15DDCF
19940AEF470C3285D5A31F39C812D68D
9EE5A84B3EB75076BC26F1DAC45B137B
4DE37589E726CA9AD72B1E9F486836AE
96FC6EC1EC504DFC3581D7205E98386A
92AF2DBC1DB1C9B456F77EC6A052F83D
8291A1AC787DE2A189B866F2AAC5BF13
300DD4059F432831DE94586F7AAC233D
D9D19ADC6B19EF4ACC3715D68F1EE408
4B46B772F6A586FB22C35991FAEC430D
F1C58453237DD9E19AC86B16AF4EFC34
41D7705EA4387B52A37DB9E1B2C87596
A72EFA9C4329F1DEC458537ABDE33189
D466DF6AD82F1A9C0B29C75ED2B85DB2
B9B5B2F735869722EE998C6AE5EF0B0C
0745C2B311B5CC7715E68F0AE4070B42
8771A2A479BB62F36985EEE30C49C5F6
D306DDC2D9919AEC6B0DEF458C3325D5
DB1F1B480B768766E2AAC9BF16F00EC4
0453437DF1E184486376A9E6FECAC057
103E8C1065CC2B15DF4F18340A97472E
B29C75A9E73ECA90572C3E9DD0699C2E
E9DC4ED9F45AC77B12A34DB9F5B2C735
92972DAE9DBC69B1EEF44C4775F2A705
BA833321D5D85F1AB80B328755A2BF39
B012F40D8745A2B339B5D2F71D8689A2
E6F98AC2E7118A8C6725EA9B0F2B441F
734825F69B06EB42CF7194246F5B6C3B
6DD36D9DEDA98DBEE5B04B34375756BE
BEF0704424335B55FB7F036001E8004E
80346017680EAE847C6361E9E84ECEB4
54777F66A02AF81F028801A6807AE023
0819C68AD2E71D8A89A726FA9AC32B11
DF4C5835FA97032E81DC6059E83ACE93
146DCF6D942DAF5DBC39B1D2F45D8779
A2A2F9B982F2E185886326A9DAFEDB00
5B403B7013640DEB458F732425DB5B1B
7B4B637769E6AECAFC5701FE80406030
32407802486436AB56FF7EC020A544C9
0A91C72C529DFDA981BEE0704824369B
56EB7ECF6054283F5E90386C12ADCDBD
95B1AF347C1761CEA8547EBF60702824
1E9B486B76AF66FC2AC1DF10580C3A85
D3231DD9C99AF817B445485436BF56F0
3EC410A762C9F5D1871C6289E9A6CEFA
D4431F71C824569B7EEB604F68342E97
5C6EB9EC72CDE5958B2F275C1AB9CB32
D7559EBF28701EA4087B46A372F9E582
CB2197586EBAAC733DE5D18B28CF85ED
B6CF36D416DF4ED834F4977B2EA35C79
F9E2C2C99196EC6ECDEC558DFF25CACB
7C9257BB6377A321B9D872DAA59B3B2B
535F7DF821820804E22BA776A0BF780C
2285D9A31AF9CB02D7419EB068742EA7
5C7A95BEDE8E38D1F273D81C5A89FB26
C35AD1FB1C4349F1F6C48A43145F4F24
00FFFFFFFFFFFFFFFFFFFF0001817361
0028001E80086006A802FE8180606028
281E9E886866AEAAFC7F01E000480036
8016E00EC80456837EE1E0484836B696
F6EEC6CC52D5FD9F01A8007E80206018
280A9E8728629EA9A87EFEA040783022
9419AF4AFC3701D6805EE0384812B68D
B6E5B6CB36D756DEBED8705AA43B3B53
537DFDE181886066A82AFE9F0068002E
801C6009E806CE82D4619F68682EAE9C
7C69E1EEC84C56B5FEF700468032E015
880F26841AE34B09F746C6B2D2F59D87
29A29EF9A842FEB180746027681AAE8B
80C08080808080C080808080808080C0
80808080808080C08080808080808080
80808080808080808080808080808080
80808080808080808080808080808080
808080808080C0808080808080808080
8080C080C08080808080C0C08080C080

I now also checked the newer px_d8 1.01.

For the 1210S the Nights disc gives:

C:\Documents and Settings\User\Desktop\px_d8_1.01A>px_d8 i 0
Sector: 0
MSF: 00:01:73
Combined offset: +6848 bytes / +1712 samples

And the 716AL gives:

C:\Documents and Settings\User\Desktop\px_d8_1.01A>px_d8 g 0
Sector: 0
MSF: 00:01:73
Combined offset: +6576 bytes / +1644 samples

I also manually counted the offset between the 716AL and the 1210S by fetching a sector from each drive with px_d8 1.0. The relative offset of the two is 272 bytes, which matches what px_d8 1.01 says.

Go to forum: General discussion

74 Reply by scsi_wuzzy

(3,497 replies, posted in General discussion)

sarami wrote:

It may be this.
DiscImageCreator\Doc\KnownIssue.txt

. Reading with/without subcode, differ offset. (firmware bug?)
  PLEXTOR PX-W2410TA: +686(with), +98(without)
  PLEXTOR PX-320A   : +686(with), +98(without)

fixed: reading a subcode on ReadCDForSearchingOffset().
If my thought is right, "Combined Offset (Byte)" of disclog.txt increases 2352(0x930) byte in your 1210S. If so, to get right "CD offset", it needs to fix driveOffset.txt manually for these drives .

I think maybe there's some other issue? If I understand correctly, for some drives the offset changes depending on if subcode reading is on or off. If that were the case, these px_d8 commands would result in differing data:

px_d8 i 0
px_d8 i 0 2
px_d8 i 0 1

However, the actual sector data is the same among all of them, and the only difference is the subcode data. If the offset changed, I think it should be seen in the sector data?

I tried manually changing the offset in the text file to +686 or -490 (+/- 2352 bytes), but that didn't alter the resulting image (hashes were the same). Perhaps I've misunderstood something.

Go to forum: General discussion

75 Reply by scsi_wuzzy

(3,497 replies, posted in General discussion)

sarami wrote:

I found this page.
https://msdn.microsoft.com/en-us/librar … s.85).aspx
And I understood that 1210S didn't support ReadBufferCapacity according to your drivelog.

    FeatureRealTimeStreaming
                StreamRecording: No
            WriteSpeedInGetPerf: No
               WriteSpeedInMP2A: Yes
                     SetCDSpeed: Yes
        ReadBufferCapacityBlock: No

Uploaded. But I don't know why SetCDSpeed fails on 1210S...

EDIT: remove some declspec(align(4) in struct.h. changed message when it failed re-read.
EDIT: I had made a silly mistake regarding reread from 20150227. fixed it.

1210S works with this release, but I've just noticed that its hashes don't match the other drives. It didn't in the last version either, but I didn't notice it then.

It looks like some kind of offset problem? First row in HxD when I load the .scm file produced by the 40TS is

00 FF FF FF FF FF FF FF FF FF FF 00 01 82 00 61

So, that is at offset 0x0 in the 40TS .scm. But, for the 1210S, it occurs at 0x930. Likewise, the data at 0x10 in the 40TS file occurs at 0x940 in the 1210S data. Everything seems to be offset by 0x930.

Ultraplex Logs: https://www.sendspace.com/file/jkiijq

1210S Logs: https://www.sendspace.com/file/zfqvcc

On another note, C2 error re-reading does indeed seem to work properly on this version.

Edit: Just realized 0x930 = 2352 bytes = 1 sector.

Go to forum: General discussion