C2 file appears to never correlate to the log file or .scm file

[ehw]

Version
20220909

Describe the bug
(Note - this is a long description, so if you want to jump to the actual issue, go to where it says "Bug description starts here" in bold)

There are a number of weird discrepancies when you try to correlate the .c2 file, the .scm, and the C2 log file together that doesn't seem to make any sense. The c2 error log file that DiscImageCreator generates indicates offsets (for individual bits in the .c2 file for that given LBA, presumably) but those offsets never actually correlate to the location of the actual error bits in the .c2 file. Likewise, the error bits in the .c2 file never seem to correlate to the .scm file either.

I'm not exactly sure why this is, but it might have something to do with the possibility that some Plextor DVD drives have different C2 offsets which are not sector aligned (http://forum.redump.org/post/99760/#p99760). There might also be something else at play here that I'm unsure of.

Although, maybe there's something I'm missing as there's not a lot of documentation on the .c2 file or its logs, so my understanding of this issue is based on what I think I understand of how it works. Please forgive me if I'm mistaken.

This is how I expect the .c2 file and C2 log file to work:
According to the documentation, the C2 file contains a series of bytes where 1 = bit inside the .c2 file correlates to 1 byte in the .scm file. If any bit inside the .c2 file is set to 1, this means that the equivalent byte in the .scm file is marked as "erroneous". For instance, if the byte at $810 is set to $80 (1000 0000), then that means that $810 * 8 (bytes) = $4080 in the .scm file. Therefore, $4080 is the location of the equivalent erroneous byte in the .scm file for the bit at $810 in the .c2 file. However, the location doesn't point to the right spot it seems. (See example below)

The C2 log is a different story. When errors are detected by DiscImageCreator, the LBA of the location of the error is displayed (both in decimal and hexadecimal, for some reason), followed by a list of what I assume to be the offsets to the individual bits in the .c2 file that make up the erroneous bytes for that specific LBA, in hexadecimal. For instance, if DiscImageCreator detects an error at ofs $290 for LBA 6, I should be able to find the erroneous byte in the .scm file by finding the physical address of the LBA (6*2352=$D3EC), then multiply the offset of the bit offset to get the offset of the byte itself ($290 * 8 = $1480), then add the offset to the physical address of LBA 6 to find the location of the affected byte in the .scm file ($D3EC + $1480 = $E86C). DiscImageCreator will then print the number of bit-errors it finds in decimal (with a max value of 2532 bits, for the entire sector).

However, neither the .c2 file nor the C2 log file seem to be accurate at all. The issues can be made apparent by following this example (see the included files to follow along):
Bug description starts here
Inside the .7z, there are two Dumps made from the same CD-R, Dump 5 and Dump 7. Both were dumped using a drive that has the ASUS BW-16D1HT 3.02 firmware.
Consider the .c2 file in Dump 5:
$6E4 is the start of LBA 6, we know that the c2 is 294 bytes per sector ($126) - so $126 * 6 gives us $6E4
$732 is the location of the first non zero byte, indicating an error on the bits that are set to 1. In this case, the byte at $732 is set to $80 (1000 0000), therefore, the most significant bit (MSB) indicates an erroneous bit with "ofs" (offset) $4E.

However, the bug becomes apparent when you look at the C2 log file. According to the log file, it says that the first damaged byte for LBA 6 is located at bit $290 (I assume?). To translate this to the address of the byte inside the .c2 file, if you divide $290 / 8, you get $52, which is 4 bytes away from the original calculated offset - $4E. Is this right or wrong?

Accordng to superg, the author of redumper, the ASUS ASUS BW-16D1HT has a C2 offset of 0x0 (no offset), but a drive offset of +6. Could this be an indicator some implied offset?
https://github.com/superg/redumper/blob/f98fa8d4c9201ec3fc23d02c21ff5dd82c5738e2/drive.cc#L107

I included Dump 7 as well, as LBA 6 in that dump is free from any errors.

Screenshots
N/A
Disc title
Any CD title that will generate C2 errors that can't be corrected.

Log file
(Note: I had to upload the .scm file because it might be the only way to help illustrate the issue)
https://www.mediafire.com/file/nviicq1sg0ftg1e/DIC+C2+Issue.7z/file

[saramibreak]

Both were dumped using a drive that has the ASUS BW-16D1HT 3.02 firmware.

Is there a same problem when plextor is used?

[ehw]

Hey Sarami, thanks for getting back.

There definitely seems to a problem even when a Plextor is used as well. See attached for a dump in a Plextor PX-W4012TA
https://www.mediafire.com/file/51yfe9nelcaykuz/Dump+8.7z/file

In comparison to Dump 8, LBA 7 has an error on ofs 92f which should be affecting the last byte in sector 7. This offset is not affected in Dump 7. However, when comparing the two .scms and .c2 files together, assuming my math is right...

7*2352 = $4050
$4050 + $92F = $497F
Therefore, the corrupt byte that ofs 92f from the C2 file correlates to for LBA 7 is at $497F in the .scm file. However...

(Dump 8 vs Dump 7)

There are no byte differences, despite there being a bad byte in Dump 8 at ofs 92f in lba 7 that isn't present in Dump 7 at the same offset for the same LBA.

For the .c2 files...

LBA 7's location in the .c2 file is determined as:
7*$126=$80A

Since each LBA in the .c2 file is represented with $126 bytes, ofs 92f should be located at the last byte for this lba, which should be at $92F in the .c2 file. However...

In the picture above, the highlighted byte ($92F) is 00, indicating no error for both dumps. Even most of the bytes around this offset have no error. There should be a non-zero byte at this address for Dump 8, and a zero byte in Dump 7 at this address too. But both are set to $00, indicating no issues, which contradicts the .c2 log.

Here's another set of scm only dumps where one is dumped with an ASUS drive and another with a W4012TA. I haven't had time to look at it, but I'm sure the same issue occurs there.
https://www.mediafire.com/file/f21pvppxec7gf34/%5BBAD+DUMP%5D+2-12-98+Version+3.1+v+Preview+v+Sony+v+Alpha+VR+Baseball+99.7z/file

I hope this help! Let me know if you need anything else.

[saramibreak]

changed: .c2 file is not shifted by the combined offset.
DiscImageCreator_test.zip

[ehw]

Hey Sarami, this looks fixed! I dumped some discs with my PX-760a and things look okay so far. It even fixed a bug I forgot to mention where the last sector's c2 error data was missing from the .c2 file. I'll do some more testing and see if anything comes up with other drives. Maybe this is good to commit?

There remains one issue, though. Although the log is correlating to the c2 file now, the log file and .c2 file don't seem to correlate to the .scm. For example:
https://www.mediafire.com/file/xdcncwa2wtu3wz8/DIC+C2+Issue+-+Example+2.7z/file

In dump 1 & 2 of this Shaolin disc, LBA 191624 has errors in both dumps. Both dumps were done using a Plextor PX-W4012TA using a UGREEN adapter. However, the affected offsets in both dumps are different:

Dump 1:

                 ofs: 318, 345, 34c, 34e, 479, 47b, 482, 4a4, 4b5, 4b6, 60b, 618, 619, 61b, 63f, 644, 64e, 64f, 771, 778, 77a, 780, 7a6, 7a7, 7ac, 7af, 7b5, 
 LBA[191624, 0x2ec88] Detected C2 error 27 bit

Dump 2:

                 ofs: 470, 472, 47b, 482, 4a4, 4ae, 4af, 4b6, 518, 51b, 520, 54d, 54e, 55d, 55e, 5f2, 5f8, 5fa, 601, 626, 634, 635, 636, 789, 791, 792, 79b, 7bc, 7be, 7c5, 891, 893, 899, 8c5, 8ce, 8cf, 8d5, 8d6, 
 LBA[191624, 0x2ec88] Detected C2 error 38 bit

When the .scm from both dumps are compared side by side with Beyond Compare, the differences become clear (Dump 1 left, Dump 2 right):

Here are what the .c2 files look like compared side by side for this LBA (191624*$126=$35BA430, Dump 1 left Dump 2 right):

As you can see in the C2 image, there is an error an error at $35BA493 for this LBA in Dump 1 with a value of $80 (1000 0000). The bit set to 1 in this byte for this LBA can be found at ofs $318, which confirms that the log and the .c2 file both correlate to each other (with the version you provided fixes with). Note, ofs $318 is not corrupt in Dump 2, and is completely fine.

However, the problem becomes apparent when you use the location of ofs $318 to find the equivalent affected byte in the .scm file. In theory, because 1 bit in the c2 file = 1 byte in the .scm file, since the ofs in the c2 log are for the bits in the c2 file, simply adding the offsets to the physical address at the start of a given LBA will give you the exact physical address to the affected erroneous byte in the .scm file. So in this case, since LBA 191624 begins at $1ADD2180 in the .scm (because 191624*2352=$1ADD2180), if you add $318 to it, the affected byte for ofs $318 should be located at $1ADD2498. However, this is not correct. Look at the image of the .scm images closely, and you'll see that the corrupt byte is actually located at $1ADD2304. In other words, **the ofs should be $184, NOT $318. ** I think this is a bug, but I could be wrong. Can you look into/explain this?

Aside from the issue above with the .c2 offsets and .scm not correlating with each other, there's one more bug I think I found:

Sometimes DIC will return this message along with the offsets which looks very strange:

 LBA[223042, 0x36742] Detected C2 error "00 F0 F0 F0 00 00 00 0F 0F 0F 00"
This error can't be fixed by plextor drive. Needs to dump it by non-plextor drive and replace it
                  ofs: 26e, 277, 278, 279, 27a, 27b, 280, 281, 282, 283, 288, 289, 28a, 28b, 290, 291, 292, 293, 298, 299, 29a, 29b, 2a0, 2a1, 2a2, 2a3, 2a8, 2a9, 2aa, 2ab, 2ac, 2ad, 2ae, 2af, 2b0, 2b1, 2b2, 2b3, 2b4, 2b5, 2b6, 2b7, 2b8, 2b9, 2ba, 2bb, 2bc, 2bd, 2be, 2bf, 2c0, 2c1, 2c2, 2c3, 2c4, 2c5, 2c6, 2c7, 2c8, 2c9, 2ca, 2cb, 2cc, 2cd, 2ce, 2cf, 2d0, 2d1, 2d2, 2d3, 2d4, 2d5, 2d6, 2d7, 2d8, 2d9, 2da, 2db, 2dc, 2dd, 2de, 2df, 2e0, 2e1, 2e2, 2e3, 2e4, 2e5, 2e6, 2e7, 2e8, 2e9, 2ea, 2eb, 2ec, 2ed, 2ee, 2ef, 2f0, 2f1, 2f2, 2f3, 2f4, 2f5, 2f6, 2f7, 2f8, 2f9, 2fa, 2fb, 2fc, 2fd, 2fe, 2ff, 300, 301, 302, 303, 304, 305, 306, 307, 308, 309, 30a, 30b, 30c, 30d, 30e, 30f, 310, 311, 312, 313, 314, 315, 316, 317, 318, 319, 31a, 31b, 31c, 31d, 31e, 31f, 320, 321, 322, 323, 324, 325, 326, 327, 328, 329, 32a, 32b, 32c, 32d, 32e, 32f, 330, 331, 332, 333, 334, 335, 336, 337, 338, 339, 33a, 33b, 33c, 33d, 33e, 33f, 340, 341, 342, 343, 344, 345, 346, 347, 348, 349, 34a, 34b, 34c, 34d, 34e, 34f, 350, 351, 352, 353, 354, 355, 356, 357, 358, 359, 35a, 35b, 35c, 35d, 35e, 35f, 360, 361, 362, 363, 364, 365, 366, 367, 368, 369, 36a, 36b, 36c, 36d, 36e, 36f, 370, 371, 372, 373, 374, 375, 376, 377, 378, 379, 37a, 37b, 37c, 37d, 37e, 37f, 380, 381, 382, 383, 384, 385, 386, 387, 388, 389, 38a, 38b, 38c, 38d, 38e, 38f, 390, 391, 392, 393, 394, 395, 396, 397, 398, 399, 39a, 39b, 39c, 39d, 39e, 39f, 3a0, 3a1, 3a2, 3a3, 3a4, 3a5, 3a6, 3a7, 3a8, 3a9, 3aa, 3ab, 3ac, 3ad, 3ae, 3af, 3b4, 3b5, 3b6, 3b7, 3bc, 3bd, 3be, 3bf, 3c4, 3c5, 3c6, 3c7, 3cc, 3cd, 3ce, 3cf, 3d4, 3d5, 3d6, 3d7, 3dc, 3dd, 3de, 3df, 3f8, 3f9, 3fa, 3fb, 400, 401, 402, 403, 408, 409, 40a, 40b, 410, 411, 412, 413, 418, 419, 41a, 41b, 420, 421, 422, 423, 428, 429, 42a, 42b, 42c, 42d, 42e, 42f, 430, 431, 432, 433, 434, 435, 436, 437, 438, 439, 43a, 43b, 43c, 43d, 43e, 43f, 440, 441, 442, 443, 444, 445, 446, 447, 448, 449, 44a, 44b, 44c, 44d, 44e, 44f, 450, 451, 452, 453, 454, 455, 456, 457, 458, 459, 45a, 45b, 45c, 45d, 45e, 45f, 460, 461, 462, 463, 464, 465, 466, 467, 468, 469, 46a, 46b, 46c, 46d, 46e, 46f, 470, 471, 472, 473, 474, 475, 476, 477, 478, 479, 47a, 47b, 47c, 47d, 47e, 47f, 480, 481, 482, 483, 484, 485, 486, 487, 488, 489, 48a, 48b, 48c, 48d, 48e, 48f, 490, 491, 492, 493, 494, 495, 496, 497, 498, 499, 49a, 49b, 49c, 49d, 49e, 49f, 4a0, 4a1, 4a2, 4a3, 4a4, 4a5, 4a6, 4a7, 4a8, 4a9, 4aa, 4ab, 4ac, 4ad, 4ae, 4af, 4b0, 4b1, 4b2, 4b3, 4b4, 4b5, 4b6, 4b7, 4b8, 4b9, 4ba, 4bb, 4bc, 4bd, 4be, 4bf, 4c0, 4c1, 4c2, 4c3, 4c4, 4c5, 4c6, 4c7, 4c8, 4c9, 4ca, 4cb, 4cc, 4cd, 4ce, 4cf, 4d0, 4d1, 4d2, 4d3, 4d4, 4d5, 4d6, 4d7, 4d8, 4d9, 4da, 4db, 4dc, 4dd, 4de, 4df, 4e0, 4e1, 4e2, 4e3, 4e4, 4e5, 4e6, 4e7, 4e8, 4e9, 4ea, 4eb, 4ec, 4ed, 4ee, 4ef, 4f0, 4f1, 4f2, 4f3, 4f4, 4f5, 4f6, 4f7, 4f8, 4f9, 4fa, 4fb, 4fc, 4fd, 4fe, 4ff, 500, 501, 502, 503, 504, 505, 506, 507, 508, 509, 50a, 50b, 50c, 50d, 50e, 50f, 510, 511, 512, 513, 514, 515, 516, 517, 518, 519, 51a, 51b, 51c, 51d, 51e, 51f, 520, 521, 522, 523, 524, 525, 526, 527, 528, 529, 52a, 52b, 52c, 52d, 52e, 52f, 530, 531, 532, 533, 534, 535, 536, 537, 538, 539, 53a, 53b, 53c, 53d, 53e, 53f, 540, 541, 542, 543, 544, 545, 546, 547, 548, 549, 54a, 54b, 54c, 54d, 54e, 54f, 550, 551, 552, 553, 554, 555, 556, 557, 558, 559, 55a, 55b, 55c, 55d, 55e, 55f, 560, 561, 562, 563, 564, 565, 566, 567, 568, 569, 56a, 56b, 56c, 56d, 56e, 56f, 570, 571, 572, 573, 574, 575, 576, 577, 578, 579, 57a, 57b, 57c, 57d, 57e, 57f, 580, 581, 582, 583, 584, 585, 586, 587, 588, 589, 58a, 58b, 58c, 58d, 58e, 58f, 590, 591, 592, 593, 594, 595, 596, 597, 598, 599, 59a, 59b, 59c, 59d, 59e, 59f, 5a0, 5a1, 5a2, 5a3, 5a4, 5a5, 5a6, 5a7, 5a8, 5a9, 5aa, 5ab, 5ac, 5ad, 5ae, 5af, 5b0, 5b1, 5b2, 5b3, 5b4, 5b5, 5b6, 5b7, 5b8, 5b9, 5ba, 5bb, 5bc, 5bd, 5be, 5bf, 5c0, 5c1, 5c2, 5c3, 5c4, 5c5, 5c6, 5c7, 5c8, 5c9, 5ca, 5cb, 5cc, 5cd, 5ce, 5cf, 5d0, 5d1, 5d2, 5d3, 5d4, 5d5, 5d6, 5d7, 5d8, 5d9, 5da, 5db, 5dc, 5dd, 5de, 5df, 5e0, 5e1, 5e2, 5e3, 5e4, 5e5, 5e6, 5e7, 5e8, 5e9, 5ea, 5eb, 5ec, 5ed, 5ee, 5ef, 5f0, 5f1, 5f2, 5f3, 5f4, 5f5, 5f6, 5f7, 5f8, 5f9, 5fa, 5fb, 5fc, 5fd, 5fe, 5ff, 600, 601, 602, 603, 604, 605, 606, 607, 608, 609, 60a, 60b, 60c, 60d, 60e, 60f, 610, 611, 612, 613, 614, 615, 616, 617, 618, 619, 61a, 61b, 61c, 61d, 61e, 61f, 620, 621, 622, 623, 624, 625, 626, 627, 628, 629, 62a, 62b, 62c, 62d, 62e, 62f, 630, 631, 632, 633, 634, 635, 636, 637, 638, 639, 63a, 63b, 63c, 63d, 63e, 63f, 640, 641, 642, 643, 644, 645, 646, 647, 648, 649, 64a, 64b, 64c, 64d, 64e, 64f, 650, 651, 652, 653, 654, 655, 656, 657, 658, 659, 65a, 65b, 65c, 65d, 65e, 65f, 660, 661, 662, 663, 664, 665, 666, 667, 668, 669, 66a, 66b, 66c, 66d, 66e, 66f, 670, 671, 672, 673, 674, 675, 676, 677, 678, 679, 67a, 67b, 67c, 67d, 67e, 67f, 680, 681, 682, 683, 684, 685, 686, 687, 688, 689, 68a, 68b, 68c, 68d, 68e, 68f, 690, 691, 692, 693, 694, 695, 696, 697, 698, 699, 69a, 69b, 69c, 69d, 69e, 69f, 6a0, 6a1, 6a2, 6a3, 6a4, 6a5, 6a6, 6a7, 6a8, 6a9, 6aa, 6ab, 6ac, 6ad, 6ae, 6af, 6b4, 6b5, 6b6, 6b7, 6bc, 6bd, 6be, 6bf, 6c4, 6c5, 6c6, 6c7, 6cc, 6cd, 6ce, 6cf, 6d4, 6d5, 6d6, 6d7, 6dc, 6dd, 6de, 6df, 6f8, 6f9, 6fa, 6fb, 700, 701, 702, 703, 708, 709, 70a, 70b, 710, 711, 712, 713, 718, 719, 71a, 71b, 720, 721, 722, 723, 728, 729, 72a, 72b, 72c, 72d, 72e, 72f, 730, 731, 732, 733, 734, 735, 736, 737, 738, 739, 73a, 73b, 73c, 73d, 73e, 73f, 740, 741, 742, 743, 744, 745, 746, 747, 748, 749, 74a, 74b, 74c, 74d, 74e, 74f, 750, 751, 752, 753, 754, 755, 756, 757, 758, 759, 75a, 75b, 75c, 75d, 75e, 75f, 760, 761, 762, 763, 764, 765, 766, 767, 768, 769, 76a, 76b, 76c, 76d, 76e, 76f, 770, 771, 772, 773, 774, 775, 776, 777, 778, 779, 77a, 77b, 77c, 77d, 77e, 77f, 780, 781, 782, 783, 784, 785, 786, 787, 788, 789, 78a, 78b, 78c, 78d, 78e, 78f, 790, 791, 792, 793, 794, 795, 796, 797, 798, 799, 79a, 79b, 79c, 79d, 79e, 79f, 7a0, 7a1, 7a2, 7a3, 7a4, 7a5, 7a6, 7a7, 7a8, 7a9, 7aa, 7ab, 7ac, 7ad, 7ae, 7af, 7b0, 7b1, 7b2, 7b3, 7b4, 7b5, 7b6, 7b7, 7b8, 7b9, 7ba, 7bb, 7bc, 7bd, 7be, 7bf, 7c0, 7c1, 7c2, 7c3, 7c4, 7c5, 7c6, 7c7, 7c8, 7c9, 7ca, 7cb, 7cc, 7cd, 7ce, 7cf, 7d0, 7d1, 7d2, 7d3, 7d4, 7d5, 7d6, 7d7, 7d8, 7d9, 7da, 7db, 7dc, 7dd, 7de, 7df, 7e0, 7e1, 7e2, 7e3, 7e4, 7e5, 7e6, 7e7, 7e8, 7e9, 7ea, 7eb, 7ec, 7ed, 7ee, 7ef, 7f0, 7f1, 7f2, 7f3, 7f4, 7f5, 7f6, 7f7, 7f8, 7f9, 7fa, 7fb, 7fc, 7fd, 7fe, 7ff, 800, 801, 802, 803, 804, 805, 806, 807, 808, 809, 80a, 80b, 80c, 80d, 80e, 80f, 810, 811, 812, 813, 814, 815, 816, 817, 818, 819, 81a, 81b, 81c, 81d, 81e, 81f, 820, 821, 822, 823, 824, 825, 826, 827, 828, 829, 82a, 82b, 82c, 82d, 82e, 82f, 830, 831, 832, 833, 834, 835, 836, 837, 838, 839, 83a, 83b, 83c, 83d, 83e, 83f, 840, 841, 842, 843, 844, 845, 846, 847, 848, 849, 84a, 84b, 84c, 84d, 84e, 84f, 850, 851, 852, 853, 854, 855, 856, 857, 858, 859, 85a, 85b, 85c, 85d, 85e, 85f, 860, 861, 862, 863, 864, 865, 866, 867, 868, 869, 86a, 86b, 86c, 86d, 86e, 86f, 870, 871, 872, 873, 874, 875, 876, 877, 878, 879, 87a, 87b, 87c, 87d, 87e, 87f, 880, 881, 882, 883, 884, 885, 886, 887, 888, 889, 88a, 88b, 88c, 88d, 88e, 88f, 890, 891, 892, 893, 894, 895, 896, 897, 898, 899, 89a, 89b, 89c, 89d, 89e, 89f, 8a0, 8a1, 8a2, 8a3, 8a4, 8a5, 8a6, 8a7, 8a8, 8a9, 8aa, 8ab, 8ac, 8ad, 8ae, 8af, 8b0, 8b1, 8b2, 8b3, 8b4, 8b5, 8b6, 8b7, 8b8, 8b9, 8ba, 8bb, 8bc, 8bd, 8be, 8bf, 8c0, 8c1, 8c2, 8c3, 8c4, 8c5, 8c6, 8c7, 8c8, 8c9, 8ca, 8cb, 8cc, 8cd, 8ce, 8cf, 8d0, 8d1, 8d2, 8d3, 8d4, 8d5, 8d6, 8d7, 8d8, 8d9, 8da, 8db, 8dc, 8dd, 8de, 8df, 8e0, 8e1, 8e2, 8e3, 8e4, 8e5, 8e6, 8e7, 8e8, 8e9, 8ea, 8eb, 8ec, 8ed, 8ee, 8ef, 8f0, 8f1, 8f2, 8f3, 8f4, 8f5, 8f6, 8f7, 8f8, 8f9, 8fa, 8fb, 8fc, 8fd, 8fe, 8ff, 900, 901, 902, 903, 904, 905, 906, 907, 908, 909, 90a, 90b, 90c, 90d, 90e, 90f, 910, 911, 912, 913, 914, 915, 916, 917, 918, 919, 91a, 91b, 91c, 91d, 91e, 91f, 920, 921, 922, 923, 924, 925, 926, 927, 928, 929, 92a, 92b, 92c, 92d, 92e, 92f, 
 LBA[223042, 0x36742] Detected C2 error 1554 bit

For some reason, instead of the bit size of the error, sometimes DIC will return "00 F0 F0 F0 00 00 00 0F 0F 0F 00", or something similar instead initially. Then it'll print the other affected offsets that I guess can be fixed. Then for the same LBA, it tell you the error size. However, what seems to be happening is DIC will print the byte values for the errors in the .c2 file that can't be fixed, and doesn't list them as "ofs" in the list of erroneous bit offsets. However, the C2 file will have the "00 F0 F0 F0 00 00 00 0F 0F 0F 00" sequence in the .c2 file anyway. It just doesn't seem to be logged properly. Is this a bug or intentional? I noticed this similar error popping up once in a while for some reason.

Here's the dump this error came from if you want to take a look:
https://www.mediafire.com/file/gsqppceyvv7z6vi/DIC+C2+Issue+-+Detected+C2+error+bug.7z/file

Please let me know if you have any questions. Always willing to help out. :)

[Feathered-Serpent]

I wonder if this makes all previously made dumps with c2 files corrupt?

[saramibreak]

So in this case, since LBA 191624 begins at $1ADD2180 in the .scm (because 191624*2352=$1ADD2180),

It's true.

if you add $318 to it, the affected byte for ofs $318 should be located at $1ADD2498.

It's not so. Because the ofs of the c2 error log contains the combined offset, while .scm is already shifted by the combined offset. In other words, The offset of the .scm is 0.

However, this is not correct. Look at the image of the .scm images closely, and you'll see that the corrupt byte is actually located at $1ADD2304. In other words, **the ofs should be $184, NOT $318. **

According to your log, the combined offset is 404 (194h). Then 318h - 194h = 184h

[ehw]

I wonder if this makes all previously made dumps with c2 files corrupt?

The .c2 files I think were in this case. But the actual .scm dumps have always been fine. DIC doesn't seem to use the .c2 files for anything at the moment, so it's mostly for information about the dump at this point I think...

So in this case, since LBA 191624 begins at $1ADD2180 in the .scm (because 191624*2352=$1ADD2180),

It's true.

if you add $318 to it, the affected byte for ofs $318 should be located at $1ADD2498.

It's not so. Because the ofs of the c2 error log contains the combined offset, while .scm is already shifted by the combined offset. In other words, The offset of the .scm is 0.

However, this is not correct. Look at the image of the .scm images closely, and you'll see that the corrupt byte is actually located at $1ADD2304. In other words, **the ofs should be $184, NOT $318. **

According to your log, the combined offset is 404 (194h). Then 318h - 194h = 184h

Thanks for the reply! The combined offset makes sense. Once the combined offset was determined, I was able to get the exact address for all the other errors just by applying it to the returned ofs for the c2. This also helps explain why sometimes you have return ofs of "0, 1, 2, 3, etc), but there aren't any bytes affected at those offsets within the current LBA. For instance, if you look at LBA 191680, there's an error at ofs 172. However, there is no erroneous byte at 191680 * 2352 + $172, but there is an erroneous byte at 191680 * 2352 + ($172 - $194), which actually puts you on an erroneous byte in the previous sector at $1ADF23DE.

So now my next question is, does the combined offset value vary from drive to drive then? If a combined offset is determined for one drive, can it be used for every dump for different discs made with that drive with c2 errors? I think I remember determining the offset for another dump done by another drive, and got a different combined offset but never bothered to check if it could be used to find the locations of everything else. Can DIC determine the combined offset by itself? If not, would it be beneficial to start a database of combined offsets to help DIC provide offsets/address for each c2 error in the logs? If so, I can help contribute as I have many Plextor drives to work with.

My other question which I just want to reaffirm is that I noticed that sometimes the erroneous bytes in the .scm sometimes have corrupt bytes in locations immediately around the affected byte. Is this because sometimes error bits can occur across more than one ofs, but the drive only reports it affecting one ofs sometimes? Like take for example 191680 * 2352 + ($172 - $194) = 1ADF23DE. There's an error at 1ADF23DE, but there's also an affected byte right next to it at 1ADF23DF which its offset isn't recorded by the c2 error log.

Thanks once again.

EDIT: It looks like the combined offset varies from disc to disc, not just drive to drive...

[saramibreak]

So now my next question

Combined offset consists of drive offset and write offset of the disc. Drive offset is stored in driveOffset.txt (Original data is accuraterip.com). Write offset is different by discs (see redump.org database).

My other question

I'd understand it, but I don't know the reason. For this reason, I've coded val2 ... val4 in /c2 as app can reread all sector when c2 error reports only 1 bit.

        /c2     Continue reading CD to recover C2 error existing sector
                        val1    value to reread (default: 4000)
                        val2    0: reread sector c2 error is reported (default)
                                1: reread all (or from first to last) sector
                        val3    first LBA to reread (default: 0)
                        val4    last LBA to reread (default: end-of-sector)
                                val3, 4 is used when val2 is 1

As you know, superg says about another c2 offset of plextor DVD model http://forum.redump.org/post/99760/#p99760 , can you verify it if you have plextor DVD model?

[ehw]

Thanks for getting back. :)

Don't have time at the moment to look at these in depth, but if you're curious:
https://www.mediafire.com/file/619yw9jklqovabv/DIC+-+Drive+C2+Offset+tests.7z/file

So what I did was I dumped a disc I had that has consistent issues with a very small amount of sectors, mostly near the very end, twice in three separate drives - a PX-760A (combined offset 464, C2 offset 295), a PX-W4012TA (combined offset 736, C2 offset 294), and a ASUS BW-16D1HT 3.02 (combined offset 368, C2 offset is 0).

Let me know if this helps with figuring out any further issues. If you're still not seeing something, let me know and I'll take a closer look when I have the time.

For instance, this is what LBA 207067 looks like in the .c2 files for the PX-W4012TA (left) and PX-780A (right) when compared in Beyond Compare (pointer is at the start of the sector in each file):

Likewise, here is the .scm file for both compared to side by side:

Ideally, I would like some sort of c2 log or .c2 file (vairant?) that's offset to the .scm itself. That is, taking into consideration both the combined offset and possible c2 offsets too). This way, the C2 log/file is as 1:1 with the errors in the .scm as close as possible.

Hope this helps.

[ehw]

Hey @saramibreak , I'm done with my research on DVD Plextors.

So keep in mind, ideally it'd be great to have a version of the .c2 file and the log file with offsets and addresses that correlate directly to the .scm file as much as possible. That's the goal in my opinion.

So in a nutshell, I was able to confirm what superg has stated in that thread about DVD Plextors having an additional offset when trying to correlate the C2 ofs to the SCM file. Before your change (which I see you've merged), I think DIC was adding the combined offset already to the error bit locations in the .c2 file. This can work for most of the 'good' CD-ROM based Plextors, but DVD Plextors need an additional offset applied which I'm not sure where it comes from. The only thing that can be done is to compare a bad dump's scm file from a particular drive to a good dump that can be confirmed good.

So what I did was took a disc that has a confirmed, good entry in redump.org. I dumped this disc three times in three separate drives to make sure I had a good dump on hand. Then, I purposely introduced a defect to the disc by putting a small piece of tape on the surface of the disc. This way, even though the C2 errors are still inconsistent between reads and different drives, I know that I can expect errors within a general area in the dump. Then I dumped this "defective" disc in as many relevent drives as I could, and came up with the following data:

So as a recap, this is what I'm doing. First, I determine the combined offset from the disc log ("Combined Offset"). Then, I take the reported c2 ofs ("First Reported C2 Offset") and affected lba ("First LBA Error (Numerical)") for the first C2 error and plug it into the sheet, calculating the lba into a physical address ("First LBA Error (Physical Address)"). Then I took the .scm file from the bad dump from the respective drive, and compared it to the good dump of the same disc using Beyond Compare. I went to the very first byte difference in the file and input that into the sheet as well ("First Address of Difference (Error) in SCM"). With this information set in the sheet, I calculated the following:

"Actual C2 Offset For First Error" - This is the actual offset (from the beginning of the reported sector) to the first actual byte difference in the .scm, for that given sector. This is calculated by "First Address of Difference (Error) in SCM" minus "First LBA Error (Physical Address)".

"Correction" - This is the calculated offset to the affected byte in the affected sector if you only took the combined offset into consideration, this way you can see if there's a difference in the actual C2 offset as reported by the SCM file. If a drive requires no additional offset corrections, the value under "Correction" and the value under "Actual C2 Offset For First Error" will be exactly the same. This is calculated by "First Reported C2 Offset" minus "Combined Offset".

"Additional Offset" - This is what you're after. Additional Offset is the necessary value that needs to be added to the combined offset in order for C2 ofs to point to locations in the SCM file directly. This is what you need to make DVD Plextors work with the C2 offset file. This is calculated by taking the difference between "Actual C2 Offset For First Error" and "Correction". If the Additional Offset is 0 or 1, the drive only needs the combined offset to be added to the C2 ofs in order for it correlate to the SCM file. If Additional Offset is 8 or 9, the drive needs the combined offset + 8 in order for it to correlate to the .scm file.

The one thing you might have noticed is that sometimes a drive can report either 0 or 1, or 8 or 9 for it's "Additional Offset". With C2 there is always going to be some kind of margin of error with whatever the drive actually reports for some reason. But most of the time, even when it appears to be off by 1 byte, the additional offset is still either 0 or 8 for certain drives. That's just the nature of C2.

Finally, after all is said and done, I can confirm these additional offset values for the following drives:

- ASUS 16D1HT - 0
- PLEXTOR PREMIUM - 0
**- PLEXTOR PREMIUM 2 ** - 0
- PLEXTOR PX-708A - 0
- PLEXTOR PX-712A - 8
- PLEXTOR PX-716A - 8
- PLEXTOR PX-755A - 8
- PLEXTOR PX-760A - 8
- PLEXTOR PX-W4012TA - 0
- PLEXTOR PX-W4012TS - 0
- PLEXTOR PX-W4824TA - 0
- PLEXTOR PX-W5224A - 0

What I propose:

So this is what I think DIC should do with this information.

DIC should output versions of the .c2 and log files (_corrected.c2 and c2Error_corrected.txt, or something similar) that are corrected to correlate with the .scm as close as possible. Corrected .c2 and log files can only be generated for drives which have confirmed "c2 offsets" (from the table/list above). So for instance, if I dumped something with a Plextor Premium, it'll provide me the corrected .c2 and log files, as well as the original c2/log files without the combined offset. If I dumped something in a Plextor PX-40TSi, which isn't normally supported by DIC, since there is no record of it's C2 offset, it will only output the original c2/log files without the combined offset added.

Unfortunately, since the c2 offset information isn't readily available in a database like accuraterip, we need to calculate it and curate our own database within DIC itself. So DIC would have to include the additional offsets from the table/list above into the program itself in the event the equivalent drives are used.

Hope this helps, let me know if you have any questions or want me to test or look into anything else. :)

[saramibreak]

Ok. Actually, DIC gets 294 bytes of .c2 from the next sector, that is, c2 offset is 294 ("additional offset 0 drive" you say). This is already supported.
c2 offset is 295 for 712A, 716A, 755A and 760A. This is not supported yet.

[saramibreak]

Uploaded. (Not test)
DiscImageCreator_test.zip

"/s 2" is needed if 712A, 716A, 755A and 760A read the last byte of the c2.

[ehw]

Hey Sarami, did some testing with this version.

The c2 log does still correlate to the .c2 file. However, the c2 log for the DVD plextors seems broken. The "Detected C2 error # bit" line doesn't correctly total the amount of bits found. This only affects the DVD plextors, CD-ROM based plextors are fine (see mediafire link). I'm not sure why that is, but it makes most of the total bit sizes 0.

                 ofs: 632, 65e, 65f, 666, 667, 6ea, 716, 717, 71e, 71f, 7a2, 7d6, 7d7, 7e4, 7e5, 870, 89c, 89d, 8a4, 8a5, 928, 
 LBA[015355, 0x03bfb] Detected C2 error 0 bit
                 ofs: 24, 25, 2c, 2d, b0, e4, e5, 
 LBA[015356, 0x03bfc] Detected C2 error 0 bit
                 ofs: 4a2, 4a3, 4aa, 4ab, 4ba, 4bb, 4c3, 4c8, 4d2, 4d3, 4db, 4e0, 4e6, 4fe, 502, 503, 50b, 510, 516, 51a, 51b, 528, 529, 547, 55f, 562, 563, 570, 571, 57b, 580, 588, 589, 593, 598, 59e, 5a0, 5a1, 5b6, 5c3, 5c8, 5ce, 5d0, 5d1, 5e0, 5e1, 5e8, 5e9, 5f8, 5f9, 5ff, 600, 601, 617, 628, 629, 62f, 630, 631, 638, 640, 641, 649, 650, 656, 658, 659, 661, 66e, 680, 686, 688, 689, 691, 698, 699, 6a0, 6a1, 6b0, 6b1, 6b7, 6b8, 6b9, 6cf, 6e0, 6e1, 6e7, 6e8, 6e9, 724, 
 LBA[016102, 0x03ee6] Detected C2 error 0 bit
                 ofs: 1d6, 1d7, 1de, 1df, 1e6, 1ee, 1ef, 1f6, 1f7, 1fe, 24e, 24f, 257, 25c, 25f, 296, 297, 29e, 2a4, 2a5, 2ae, 2af, 2b6, 2bc, 2bd, 30f, 314, 317, 31c, 31d, 356, 35c, 35d, 364, 365, 36e, 374, 375, 37c, 37d, 3cc, 3cf, 3d4, 3d5, 3dd, 414, 415, 41c, 41d, 424, 42c, 42d, 434, 435, 43c, 48c, 48d, 495, 49d, 4d4, 4d5, 4dc, 4ec, 4ed, 4f4, 594, 5ac, 5d2, 5f5, 632, 633, 64a, 64b, 6ea, 6eb, 6f2, 6f3, 702, 703, 70a, 70b, 7a2, 7a3, 7aa, 7ab, 7b2, 7ba, 7bb, 7c2, 7c3, 7ca, 802, 803, 80b, 810, 813, 81a, 81b, 823, 828, 82b, 862, 863, 86a, 870, 871, 87a, 87b, 882, 888, 889, 8c3, 8c8, 8cb, 8d0, 8d1, 922, 928, 929, 
                 ofs: 0, 1, 
 LBA[016329, 0x03fc9] Detected C2 error 2 bit

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.

Here are the dumps from this version (scm only):
https://www.mediafire.com/file/2stinon5p4ctmqu/c2_test_3.7z/file

c2_offset_corrections.xlsx

[saramibreak]

it makes most of the total bit sizes 0.

Fixed
DiscImageCreator_test.zip

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.

It's ideal but It takes time and effort for "bit shifting".

[ehw]

it makes most of the total bit sizes 0.

Fixed DiscImageCreator_test.zip

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.

It's ideal but It takes time and effort for "bit shifting".

Confirmed, has been fixed. Everything looks good now.

Do you need to use /s 2 every time in order to get the last byte for the DVD Plextors? Is there a way to have it on by default for these drives?

[saramibreak]

Is there a way to have it on by default for these drives?

Added.
DiscImageCreator_test.zip

[ehw]

Is there a way to have it on by default for these drives?

Added. DiscImageCreator_test.zip

Works great. I did find one issue, if you use /s to overwrite the automatic set to /s 2 when using a DVD plextor it seems to always set it to /s 2. So if I manually set it to /s 1, it'll always use /s 2 according to the log. It should allow you to force it to use something else for these drives if you want to (especially for Dreamcast stuff, as we'll document someday).

Unless you want to try some form of the corrected .c2/log, even if it wont be 100% exact due to bit shifting, I guess that's it for the issue?

One small thing I was wondering if you wanted to add/change. Right now in the C2 log and verbose it prints [LBA, LBA number in hex] next to each c2 error bit size and retry. It might be useful to print [LBA, LBA translation to SCM address in hex (LBA * 2352), LBA in C2 file (LBA * 294)] instead. It's up to you, I could probably add it myself.

[saramibreak]

[LBA, LBA translation to SCM address in hex (LBA * 2352), LBA in C2 file (LBA * 294)

Added.
DiscImageCreator_test.zip

[ehw]

[LBA, LBA translation to SCM address in hex (LBA * 2352), LBA in C2 file (LBA * 294)

Added. DiscImageCreator_test.zip

Works! Thank you for adding it. :)

The only issue left is that DIC still uses /s 2 even if you manually enter /s 1 or /s 0 for DVD Plextors. User preference should take precedence over the default setting, imo.

H:\Tools\DiscImageCreator>DiscImageCreator.exe cd E MEGAMAN-11-12-test.bin 12 /c2 4096 /q /nl /am /s 1
AppVersion
32 bit, AnsiBuild, 20221112T211241
/c2 val2 was omitted. set [0]
CurrentDirectory
H:\Tools\DiscImageCreator
WorkingPath
Argument: MEGAMAN-11-12-test.bin
FullPath: H:\Tools\DiscImageCreator\MEGAMAN-11-12-test.bin
Drive: H:
Directory: \Tools\DiscImageCreator
Filename: MEGAMAN-11-12-test
Extension: .bin
StartTime: 2022-11-12T10:20:48-0500
Set the drive speed: 2116KB/sec
DiskSize of [H:\Tools\DiscImageCreator]
Total: 2000363188224 bytes
Used: 1963085144064 bytes
---------------------------
Space: 37278044160 bytes
=> There is enough disk space for dumping
[INFO] This drive has 295 offset in the c2. Changed to /s 2.

[saramibreak]

The only issue left is that DIC still uses /s 2 even if you manually enter /s 1 or /s 0 for DVD Plextors. User preference should take precedence over the default setting, imo.

If /c2 is not set, /s 1 or /s 0 for DVD Plextors are enabled.

[ehw]

The only issue left is that DIC still uses /s 2 even if you manually enter /s 1 or /s 0 for DVD Plextors. User preference should take precedence over the default setting, imo.

If /c2 is not set, /s 1 or /s 0 for DVD Plextors are enabled.

Ah okay, no problem.

Feel free to merge your changes and close the issue if you don't have any more changes in the pipeline.

[Sazpaimon]

Hey @saramibreak, I think this change might break GD-ROM mode. If i run the latest code for GD discs, I get 4 bit C2 errors on every sector:

                ofs: 0, 3, 4, 
 LBA[044999, 0x0afc7] Detected C2 error 3 bit
                 ofs: 5, 6, 
 LBA[045000, 0x0afc8] Detected C2 error 2 bit
                 ofs: 2, 3, 4, 7, 
 LBA[045001, 0x0afc9] Detected C2 error 4 bit
                 ofs: 1, 5, 6, 
 LBA[045002, 0x0afca] Detected C2 error 3 bit
                 ofs: 0, 1, 5, 7, 
 LBA[045003, 0x0afcb] Detected C2 error 4 bit
                 ofs: 1, 3, 
 LBA[045004, 0x0afcc] Detected C2 error 2 bit
                 ofs: 1, 4, 7, 
 LBA[045005, 0x0afcd] Detected C2 error 3 bit
                 ofs: 0, 3, 4, 5, 6, 
 LBA[045006, 0x0afce] Detected C2 error 5 bit
                 ofs: 0, 5, 6, 7, 
 LBA[045007, 0x0afcf] Detected C2 error 4 bit
                 ofs: 0, 5, 6, 7, 
 LBA[045008, 0x0afd0] Detected C2 error 4 bit
                 ofs: 0, 5, 6, 7, 
 LBA[045009, 0x0afd1] Detected C2 error 4 bit
                 ofs: 0, 1, 4, 5, 6, 7, 

test_c2Error.txt
test_disc.txt
test_drive.txt

[saramibreak]

All logs are needed when bug is reported.

[Sazpaimon]

Here you go, keep in mind i stopped the dump a few seconds in
test4_volDesc.txt
test4_20221112T211241.txt
test4_c2Error.txt
test4_disc.txt
test4_drive.txt
test4_mainError.txt
test4_mainInfo.txt
test4_subError.txt
test4_subInfo.txt
test4_subReadable.txt

[saramibreak]

Uploaded.
DiscImageCreator_test.zip

[Sazpaimon]

No change
test5_disc.txt
test5_drive.txt
test5_mainError.txt
test5_mainInfo.txt
test5_subError.txt
test5_subInfo.txt
test5_subReadable.txt
test5_volDesc.txt
test5_20221115T135431.txt
test5_c2Error.txt

[saramibreak]

More changed.
DiscImageCreator_test.zip

[Sazpaimon]

Better now, no more 4 bit errors every sector. I'm not able to check a GD disc that has actual C2 errors yet but this looks good to me.

[ehw]

I forgot to mention, not sure if this is a bug or not, but I noticed that sometimes when there are c2 bit errors near the end of the current LBA that sometimes some additional bits are printed, like this:

8f5, 8f6, 8f7, 8f8, 8f9, 8fa, 8fb, 8fc, 8fd, 8fe, 8ff, 900, 901, 902, 903, 904, 905, 906, 907, 908, 909, 90a, 90b, 90c, 90d, 90e, 90f, 910, 911, 912, 913, 914, 915, 916, 917, 918, 919, 91a, 91b, 91c, 91d, 91e, 91f, 920, 921, 922, 923, 924, 925, 926, 927, 928, 929, 92a, 92b, 92c, 92d, 92e, 92f,
ofs: 0, 1, 2, 3, 4, 5, 6, 7,
LBA[207067], LBA translation to SCM address in hex[0x1d075c10], LBA in C2 file[0x3a0eb82] Detected C2 error 1632 bit

Is the ofs: 0, 1, 2, 3, 4, 5, 6, 7, line supposed to be there?

This only affects DVD plextors it seems, but I'm not sure if this is intentional. I assume this is because its reading error bits that go into the next sector, but they're classified as being part of the current sector being read.

See attached for logs.

https://www.mediafire.com/file/9k6y03g325l0zro/c2+-+bug+(not+sure).7z/file

EDIT: This looks like a bug for printing. The ofs 0-7 in the c2 log for lba 207067 are meant for 207068. This is correct for the old c2 log (the one without the date in the filename).

[saramibreak]

If ofs is 7 for plextor dvd drive, it's 92f for plextor cd drive.