Page 1 of 2

Jackal is altering dumps before adding?

Posted: Sun Aug 26, 2018 2:49 am
by F1ReB4LL
https://redump.info/disc/54329/ -- why was it altered? Do you understand the fixable error there isn't a read error? How many other fixed submissions do we have?

Re: Jackal is altering dumps before adding?

Posted: Sun Aug 26, 2018 11:19 am
by Jackal
I don't think that error should be there, but we will see when TeamEurope redumped the disc. I don't remember any similar cases.

Re: Jackal is altering dumps before adding?

Posted: Sun Aug 26, 2018 11:30 am
by F1ReB4LL
If any of the dumpers remember a dump with no c2 errors that was changed some way after submitting - please, write here.

Re: Jackal is altering dumps before adding?

Posted: Sun Aug 26, 2018 11:50 am
by Jackal
Or ask iR0b0t to make a report that shows any dumps with modified clrmame data compared to the original submission?

Re: Jackal is altering dumps before adding?

Posted: Mon Sep 03, 2018 12:34 pm
by Jackal
https://redump.info/disc/54329/ can't be redumped because the disc was returned to the guy who sent them.

Similar issue from same dumper/same drive: /viewtopic.php?p=24753#p24753

Hopefully sarami can find out the cause of this issue. In any case I think the 0 error dumps are more trustworthy.

Re: Jackal is altering dumps before adding?

Posted: Mon Sep 03, 2018 6:11 pm
by F1ReB4LL
I still think it could be some kind of mastering error and in any case dumps without c2 errors shouldn't be blindly fixed.

Re: Jackal is altering dumps before adding?

Posted: Mon Sep 03, 2018 11:49 pm
by Jackal
I don't think we have any similar cases were a normal drive/dump produces a valid data sector, but a d8 plextor dump gives invalid sectors that are preferred instead? I wonder if it's even possible to master a mode1 sector where ECC/EDC doesnt match and it also isnt any protection or end-of-datatrack mastering error. If we found such cases before, the dumps were deemed suspicious and needed to be redumped: /viewtopic.php?t=12070 … to-redump/ so I'm still convinced that it's some kind of firmware/drive bug.

Re: Jackal is altering dumps before adding?

Posted: Tue Sep 04, 2018 12:42 am
by F1ReB4LL
https://redump.info/disc/55052/ -- oops, you did it again? Image

Re: Jackal is altering dumps before adding?

Posted: Tue Sep 04, 2018 11:47 am
by Jackal
F1ReB4LL wrote:https://redump.info/disc/55052/ -- oops, you did it again? Image
sarami wrote:
Jackal wrote:Another issue where DIC gives 3 errors (2 discs give the same dump), but a CloneCD dump from non-plextor drive gives 0 errors.

Can you check what's wrong?
mainError

Code: Select all

0900 : 7D A4 4D 62 45 A3 B0 63  20 29 7D 4A 9B E6 87 CC   }.MbE..c )}J....
0910 : 98 12 82 C1 B0 21 D7 BB  00 FF FF FF FF FF FF FF   .....!..........
0920 : FF FF FF 00 08 95 16 61  00 9B D5 CB A3 0A E1 A3   .......a........
LBA[041491, 0x0a213]: Track[01]: Invalid sync. Skip descrambling
========== LBA[041491, 0x0a213]: Main Channel ==========
       +0 +1 +2 +3 +4 +5 +6 +7  +8 +9 +A +B +C +D +E +F
0000 : AA 83 EC 83 12 E2 67 09  6A 0A 88 8C 8A 20 2E 86   ......g    j.... ..
0010 : 23 01 3D AF 2F 45 EF 35  73 52 F8 2F 48 0D 05 18   #.=./E.5sR./H...
Sync exists, but it's slided behind 24 bytes. Perhaps drive's cache is broken (or firmware/drive/dic bugs?). It maybe is fixed if rereading (but it's not supported yet in this case).
Same dumper, same drive, same problems. Non-plextor dump is good. Why do you keep mistrusting me?

Re: Jackal is altering dumps before adding?

Posted: Tue Sep 04, 2018 8:42 pm
by sarami
If I remember rightly, some Sega Saturn discs (perhaps +588/+1176 offsets?) have duplicate sector in the pregap of track 1.
Or some FM Towns discs are same. /viewtopic.php?t=11837 … new-dumps/
These pattern can't recognize at 0xbe (non-plextor drive) ripping. Is TeamEurope disc similar pattern? I don't know now... It needs to dump by other drive and other disc.

As a result, you maybe are right. But you shouldn't have fixed it without consultation and discussion, should you?
At least, I think you shouldn't add the disc which is suspicious of the error in the db directly, for reliable db.