You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
If an offset shift occurs on a disc (not including the leadin "Track 0" or leadout "Track A", just Tracks 1-whatever) add a Comment explaining which type of dump it is (as both regular and fixed dumps are permissible in redump).
Example, a fixed dump (as dumped with redump parameter "--correct-offset-shift") could generate a comment such as:
An offset shift occurs in the disc on Track # at Sector #, this is a "fixed dump" which corrects the offset shift.
A regular dump with such discs could generate a comment such as:
An offset shift occurs in the disc on Track # Sector # , this dump does not correct the shift and therefore dumped sectors are scrambled from the affected sector until the remainder of the dump.
Why this is important: Currently there's no system for identifying such discs without digging through the logs. This could lead to confusion and prevent people from taking the step of dumping a "fixed dump" (useable, whereas the unfixed disc image is unusable).
@7Seventy7 Is this a Redumper-specific feature request? Do you know if DIC detects offset shifts at all, or if DIC dumps match Redumper non-fixed dumps? I guess only Redumper logs will mention offset shifts, and only Redumper can "fix" them?
dumping a "fixed dump"
As far as I'm aware, --correct-offset-shift only affects redumper split, so there is no need for two dumps: just access to the .scram file from the first dump, then you can run just the split with the option.
I think it might make sense to parse the redumper log for this information. If warning: offset shift detected, to apply correction please use an option is found in the logs, then we know its a non-fixed dump. If offset shift correction applied: is found in the logs, then it is a fixed dump.
The issue is in how MPF should be outputting this information. For non-fixed dumps, the only useful info is that an offset shift was detected, perhaps it can be added to comments. For fixed dumps, I suggest outputting each of the fixed disc offsets into the comments, i.e. LBA: {:6}, offset: {:+} gets turned into something like <b>Offset Shift Fixed</b>: X at LBA Y
--
Further, if the offset shift occurs after the last LBA of the last track (i.e. in the leadout), then it can be ignored (this can occur for some enhanced discs, for example).
Given the scope of the discs that this applies to as well as the relatively complex logic required to check to see if the offset shift is something that we need to care about, I am going to be leaving this request open for a while. If someone else picks up the work needed for this in the meantime, I would be appreciative, but I will likely not be doing the work on this for a while.
If an offset shift occurs on a disc (not including the leadin "Track 0" or leadout "Track A", just Tracks 1-whatever) add a Comment explaining which type of dump it is (as both regular and fixed dumps are permissible in redump).
Example, a fixed dump (as dumped with redump parameter "--correct-offset-shift") could generate a comment such as:
An offset shift occurs in the disc on Track # at Sector #, this is a "fixed dump" which corrects the offset shift.
A regular dump with such discs could generate a comment such as:
An offset shift occurs in the disc on Track # Sector # , this dump does not correct the shift and therefore dumped sectors are scrambled from the affected sector until the remainder of the dump.
Why this is important: Currently there's no system for identifying such discs without digging through the logs. This could lead to confusion and prevent people from taking the step of dumping a "fixed dump" (useable, whereas the unfixed disc image is unusable).
An example of such a disc and both sets of logs: http://forum.redump.org/post/118477/#p118477
This is a phenomenon that has been spotted in multiple Video CD discs.
Thank you.
The text was updated successfully, but these errors were encountered: