[Request] Include full datfile snippet for Xbox 360 variable files (SS, PFI, DMI) #525

New Issue

claunia · 2026-01-29T16:17:59Z

claunia commented

2026-01-29 16:17:59 +00:00

Originally created by @mariomadproductions on GitHub (Apr 19, 2023).

Originally assigned to: @mnadareski on GitHub.

Request: Include full datfile snippet for Xbox 360 variable files (SS, PFI, DMI) in the comments, like with the audio CD overflow data in the Audio CD comments. This would be more robust the CRC32, and would allow for datfiles to be made, like with the audio cd overflow data.

Originally created by @mariomadproductions on GitHub (Apr 19, 2023). Originally assigned to: @mnadareski on GitHub. Request: Include full datfile snippet for Xbox 360 variable files (SS, PFI, DMI) in the comments, like with the audio CD overflow data in the Audio CD comments. This would be more robust the CRC32, and would allow for datfiles to be made, like with the audio cd overflow data.

claunia added the enhancement label 2026-01-29 16:17:59 +00:00

claunia closed this issue

2026-01-29 16:17:59 +00:00

claunia commented

2026-01-29 16:18:00 +00:00

@mnadareski commented on GitHub (Apr 19, 2023):

The reason that only the CRC is output is that Redump only accepts that value for the comments. All of this information is in the logfiles and can be parsed out separately. Since the aim of this comment seems to be to make DATs, that's something that would need to be done by a third party anyway, so they could probably just parse out the log data themselves. If Redumpe ever starts caring about the other hashes, I'll gladly start including them.

@mnadareski commented on GitHub (Apr 19, 2023): The reason that only the CRC is output is that Redump only accepts that value for the comments. All of this information is in the logfiles and can be parsed out separately. Since the aim of this comment seems to be to make DATs, that's something that would need to be done by a third party anyway, so they could probably just parse out the log data themselves. If Redumpe ever starts caring about the other hashes, I'll gladly start including them.

claunia commented

2026-01-29 16:18:00 +00:00

@mnadareski commented on GitHub (Apr 19, 2023):

Additionally, you can always ask the developer(s) of the dumping programs if they are willing to put the hashes for auxiliary files (such as SS.bin and .img) into a separate file for easier consumption. At the moment, DIC in particular puts the formatted hashes in otherwise unformatted files, leading to some issues in parsing in general.

@mnadareski commented on GitHub (Apr 19, 2023): Additionally, you can always ask the developer(s) of the dumping programs if they are willing to put the hashes for auxiliary files (such as `SS.bin` and `.img`) into a separate file for easier consumption. At the moment, DIC in particular puts the formatted hashes in otherwise unformatted files, leading to some issues in parsing in general.

claunia commented

2026-01-29 16:18:01 +00:00

@mariomadproductions commented on GitHub (Apr 19, 2023):

The reason that only the CRC is output is that Redump only accepts that value for the comments. All of this information is in the logfiles and can be parsed out separately. Since the aim of this comment seems to be to make DATs, that's something that would need to be done by a third party anyway, so they could probably just parse out the log data themselves. If Redumpe ever starts caring about the other hashes, I'll gladly start including them.

Yeah true if log storage becomes organised more widespread that could be a solution.

Additionally, you can always ask the developer(s) of the dumping programs if they are willing to put the hashes for auxiliary files (such as SS.bin and .img) into a separate file for easier consumption. At the moment, DIC in particular puts the formatted hashes in otherwise unformatted files, leading to some issues in parsing in general.

Good idea, will make a DIC issue about that.

@mariomadproductions commented on GitHub (Apr 19, 2023): > The reason that only the CRC is output is that Redump only accepts that value for the comments. All of this information is in the logfiles and can be parsed out separately. Since the aim of this comment seems to be to make DATs, that's something that would need to be done by a third party anyway, so they could probably just parse out the log data themselves. If Redumpe ever starts caring about the other hashes, I'll gladly start including them. Yeah true if log storage becomes organised more widespread that could be a solution. > Additionally, you can always ask the developer(s) of the dumping programs if they are willing to put the hashes for auxiliary files (such as `SS.bin` and `.img`) into a separate file for easier consumption. At the moment, DIC in particular puts the formatted hashes in otherwise unformatted files, leading to some issues in parsing in general. Good idea, will make a DIC issue about that.

claunia commented

2026-01-29 16:18:02 +00:00

@mnadareski commented on GitHub (Apr 24, 2023):

I'm going to close the issue from this side as the discussion seems to have run its course and resulted in DIC changes.

@mnadareski commented on GitHub (Apr 24, 2023): I'm going to close the issue from this side as the discussion seems to have run its course and resulted in DIC changes.

Sign in to join this conversation.

1 Participants

Notifications

Due Date

No due date set.

Dependencies

No dependencies set.

Reference: SabreTools/MPF#525