sarami, is it normal to have a separate set of (Subs indexes) where everything is the same as in primary TOC based split?
Logs: https://www.dropbox.com/s/4clypf96lu0zq … OR.7z?dl=0
Asking because my verification has identical (Subs indexes) but doesn't match what we have in the DB: https://redump.info/disc/15537/
I compared both dumps and the new data track is 1 sector more padded with zeroes and audio track is 1 sector less comparing to the DB one.
reentrant wrote:Hi,
Yes, I remember that disc. It was not possible to get consistent dump. If you look at scm file you'll notice that some bytes at discguard locations are always different. It's some kind of 'weak data' protection.
Such dumps need manual fixing. But you need to know the data to fix with. In my case it was easy as these weak bytes happened in the middle of a sector (surrounded by zeroes).
Neon Beast wrote:Hi, how can I fix my DiscGuard discs? Thanks.
my understanding based on what @reentrant is saying is that you need:
1. identify the "weak bytes", i.e. those bytes that are different on every dump due to the protection
2. try to "guess" what is the correct value of each "weak byte"- in case of @reentrant dump it was looking like 00000XX00000 and so it was easy to guess that XX=00
however, in your case it could be not that easy to guess the "weak byte" value.
Last edited by matura713 on Tue Sep 07, 2021 9:00 am, edited 1 time in total.
/s 2 didn't help.
My primary concern is that in my new dump the split is 1 sector earlier comparing to what we have in the DB.
e.g. in the new dump the data track last sector is audio track but in the DB it's not and it seems more correct. I have to identify which dump is correct, old or new.
