search

saramibreak / DiscImageCreator

This is the disc (CD, GD, DVD, HD-DVD, BD, GC/Wii, XBOX, XBOX 360) and disk (Floppy, MO, USB etc) image creation tool
http://forum.redump.org/topic/10483/discimagecreator/
Apache License 2.0
513 stars 45 forks source link

Feature Request - DVD mode - Customizable filler byte pattern for /ps #203

Closed ehw closed 1 year ago

ehw commented 1 year ago

Is your feature request related to a problem? Please describe. Currently DIC supports two filler byte values - 0x00 and 0xAA, for when errors occur that have to be substituted with filler bytes. This is great, but the problem is that the filler byte can be confused with actual user data in a 2048 byte sector as its common to have byte patterns on certain disc that are nothing but stretches of 00s or a specific byte value.

Describe the solution you'd like My solution would be to introduce a second val to the /ps parameter, /ps 2, where if /ps 2 is used the user can specify a string that can be used as a repeatable pattern to fill the sector with when errors go bad. This way errors can be easily identifiable to the user when they go to review a dump when its done. It will also make debugging read issues with sectors a bit easier to locate.

So for instance, a byte pattern of "YAKITORI" can be used by the user like /ps 2 "YAKITORI" so that when an error occurs, the sector is filled with a byte pattern of YAKITORI that spans over the entire 2048 byte sector. If the pattern size exceeds a number that can be easily divisible into a 2048 byte sector, just cut the string off.

Describe alternatives you've considered Add more values for /ps that are more distinct?

saramibreak commented 1 year ago

the filler byte can be confused with actual user data in a 2048 byte sector as its common to have byte patterns on certain disc that are nothing but stretches of 00s or a specific byte value.

With all logs, it's no problem. At least I don't confuse.

ehw commented 1 year ago

With logs it can help providing they're accurate. At least for us, it'd be great to have the ability to set the byte pattern because we can develop scripts that parse the images themselves for filled sectors based on a custom byte pattern we set at dump time. At the very least, 0x00 and 0xAA are just too common byte patterns.

saramibreak commented 1 year ago

At the very least, 0x00 and 0xAA are just too common byte patterns.

I can implement 256 pattern from /ps 0x00 to /ps 0xff. If /ps 0xff is used, sectors is padded by 0xff. If /ps 0x55 is used, sectors is padded by 0x55 etc.

ehw commented 1 year ago

At the very least, 0x00 and 0xAA are just too common byte patterns.

I can implement 256 pattern from /ps 0x00 to /ps 0xff. If /ps 0xff is used, sectors is padded by 0xff. If /ps 0x55 is used, sectors is padded by 0x55 etc.

That would be good. :)