I apologize in advance for this post likely being confusing to read, as I'm not sure the best way to get everything across.
TL;DR, I have a disc that, while matching across many dumps, will still have many non-matching dumps. Each dump has 0 C2 errors, and (except for the very first dump I attempted) no subcode desyncs, either, nor did they need to be refined. Each dump appears to have some sections that are 0x55'd that the other dumps don't, and vice versa. If I split all of the dumps with --leave-unchanged, they will all match each other, regardless of whether they were matching before. The disc is protected with Safedisc (SafeDisc 1.50.020), but I have no idea if this is relevant at all.
In more detail:
I'm attempting to dump the original, non-sourcenext version of http://redump.org/disc/89816/. My disc has the same safedisc version as well in case it's relevant, SafeDisc 1.50.020. I dumped it 2 times on my ASUS, and 3 times on my 4824. It never produced errors on any of them, but it kept producing different dumps; and when i compare them against each other in a hex editor, every dump has a section that is errored out that isn't in one of the other dumps. It is protected, but with safedisc, which redumper correctly doesn't refine, and none of the non matching sections are anywhere near it anyways. I did get the same hash between both asus dumps and my third 4824 dump, but as mentioned, it has errored out sections that aren't errored out in the other 2 plextor dumps. The disc certainly isn't pristine and has some scratching, but nothing that visibly seems like it would guarantee errors; either way, I'd assume that the errors should they happen at least manifest in the form of c2 errors or subcode desyncs. There was one small subcode desync on the first asus dump, but not on any of the others.
What i mean about the non matching sections being in all dumps:
(in both screenshots, ASUS/ASUS2/PLEX3 is on the left, crc32 ff5eb198, PLEX2 on the right, crc32 24933b5b)
I tried the latest release of DiC as well, and it got the same hash as ASUS/ASUS2/PLEX3 on both my asus and my 4824.
My redumper dumps were done using redumper v2024.05.06 build_325 [May 6 2024, 01:13:23], so I dumped it one more time on the latest release, redumper v2024.05.27 build_371 [May 27 2024, 14:06:13], to confirm the issue was still present. It is, and it produced a unique hash to all my other existing dumps, which likewise also has some sections in it that are 0x55 that aren't in the others and has some sections in it that aren't 0x55'd that are in others.
However, if i split my dumps again with --leave-unchanged, they all match each other, resulting in a matching hash, no matter what the original hash was when dumping. Unfortunately, I can't submit this to redump or provide a final hash, as I don't know of any way to split specifically only the part past the safedisc sectors, since the safedisc sectors should obviously be left as 0x55.
Please let me know what additional information needs to be clarified, what additional information/files need to be provided, and what additional things I need to try. I apologize again for this issue likely containing excessive or superfluous information.
I apologize in advance for this post likely being confusing to read, as I'm not sure the best way to get everything across.
TL;DR, I have a disc that, while matching across many dumps, will still have many non-matching dumps. Each dump has 0 C2 errors, and (except for the very first dump I attempted) no subcode desyncs, either, nor did they need to be refined. Each dump appears to have some sections that are 0x55'd that the other dumps don't, and vice versa. If I split all of the dumps with --leave-unchanged, they will all match each other, regardless of whether they were matching before. The disc is protected with Safedisc (SafeDisc 1.50.020), but I have no idea if this is relevant at all.
In more detail:
I'm attempting to dump the original, non-sourcenext version of http://redump.org/disc/89816/. My disc has the same safedisc version as well in case it's relevant, SafeDisc 1.50.020. I dumped it 2 times on my ASUS, and 3 times on my 4824. It never produced errors on any of them, but it kept producing different dumps; and when i compare them against each other in a hex editor, every dump has a section that is errored out that isn't in one of the other dumps. It is protected, but with safedisc, which redumper correctly doesn't refine, and none of the non matching sections are anywhere near it anyways. I did get the same hash between both asus dumps and my third 4824 dump, but as mentioned, it has errored out sections that aren't errored out in the other 2 plextor dumps. The disc certainly isn't pristine and has some scratching, but nothing that visibly seems like it would guarantee errors; either way, I'd assume that the errors should they happen at least manifest in the form of c2 errors or subcode desyncs. There was one small subcode desync on the first asus dump, but not on any of the others.
nobunaga.log nobunagaASUS.zip
nobunaga.log nobunagaASUS2.zip
nobunaga.log nobunagaPLEX.zip
nobunaga.log nobunagaPLEX2.zip
nobunaga.log nobunagaPLEX3.zip
What i mean about the non matching sections being in all dumps: (in both screenshots, ASUS/ASUS2/PLEX3 is on the left, crc32 ff5eb198, PLEX2 on the right, crc32 24933b5b)
I tried the latest release of DiC as well, and it got the same hash as ASUS/ASUS2/PLEX3 on both my asus and my 4824.
DiC_nobunagaASUS.zip
DiC_nobunagaPLEX.zip
My redumper dumps were done using redumper v2024.05.06 build_325 [May 6 2024, 01:13:23], so I dumped it one more time on the latest release, redumper v2024.05.27 build_371 [May 27 2024, 14:06:13], to confirm the issue was still present. It is, and it produced a unique hash to all my other existing dumps, which likewise also has some sections in it that are 0x55 that aren't in the others and has some sections in it that aren't 0x55'd that are in others.
nobunaga.log nobunaga_371_PLEX.zip
However, if i split my dumps again with --leave-unchanged, they all match each other, resulting in a matching hash, no matter what the original hash was when dumping. Unfortunately, I can't submit this to redump or provide a final hash, as I don't know of any way to split specifically only the part past the safedisc sectors, since the safedisc sectors should obviously be left as 0x55.
Please let me know what additional information needs to be clarified, what additional information/files need to be provided, and what additional things I need to try. I apologize again for this issue likely containing excessive or superfluous information.