[Investigation] Internal Media Type Agnostic #805

New Issue

claunia · 2026-01-29T16:22:32Z

claunia commented

2026-01-29 16:22:32 +00:00

Originally created by @mnadareski on GitHub (Feb 11, 2025).

Originally assigned to: @mnadareski on GitHub.

Investigate whether or not it is feasible for internals to be media type agnostic across the various dumping programs. Of the 3 dumping programs internal to MPF, only DIC actually "cares" about the media type. The other processors are all consistent in which media formats are supported.

The motivation behind this investigation is to allow for the dumping programs to deal with auto-detection of media type where possible and then just pull the information based on the system and any available files.

The outcome of this could be that multiple media type dependent pieces less expensive to maintain in terms of dev hours and allow only the "full set of outputs" to be considered. The likely outcome is that all programs except for DIC may be able to have this change done. The priority should be put on Redumper due to the still-growning userbase and default program status.

Originally created by @mnadareski on GitHub (Feb 11, 2025). Originally assigned to: @mnadareski on GitHub. Investigate whether or not it is feasible for internals to be media type agnostic across the various dumping programs. Of the 3 dumping programs internal to MPF, only DIC actually "cares" about the media type. The other processors are all consistent in which media formats are supported. The motivation behind this investigation is to allow for the dumping programs to deal with auto-detection of media type where possible and then just pull the information based on the system and any available files. The outcome of this could be that multiple media type dependent pieces less expensive to maintain in terms of dev hours and allow only the "full set of outputs" to be considered. The likely outcome is that all programs except for DIC may be able to have this change done. The priority should be put on Redumper due to the still-growning userbase and default program status.

claunia added the enhancement label 2026-01-29 16:22:32 +00:00

claunia commented

2026-01-29 16:22:33 +00:00

@mnadareski commented on GitHub (May 1, 2025):

Since opening this, Redumper moved toward a unified disc command for dumping, which basically means that all media types are treated identically on input. This doesn't solve the issue of checking for output files, but it is a step in the direction that I was hoping to achieve.

@mnadareski commented on GitHub (May 1, 2025): Since opening this, Redumper moved toward a unified `disc` command for dumping, which basically means that all media types are treated identically on input. This doesn't solve the issue of checking for output files, but it is a step in the direction that I was hoping to achieve.

claunia commented

2026-01-29 16:22:33 +00:00

@mnadareski commented on GitHub (Jun 17, 2025):

As an update to this investigation, I have a few more findings:

2 of the 3 dumping programs now require no prior knowledge of the media type in order to function properly (Redumper and Aaru)
Redump itself is the main limiter, due to differences in the expected data between CD/GD and DVD/BD/HD-DVD. Unfortunately, some things only appear for certain media types when submitting.
The internal checks for these things can be simplified a little, since many actually boil down to the existence of certain files and aren't actually locked to a particular media type.

With the above, I will likely be trying to reduce the number of media-specific checks, but the dream of being entirely agnostic (or entirely reliant on program outputs to determine the media type) are not likely to happen soon.

@mnadareski commented on GitHub (Jun 17, 2025): As an update to this investigation, I have a few more findings: - 2 of the 3 dumping programs now require no prior knowledge of the media type in order to function properly (Redumper and Aaru) - Redump itself is the main limiter, due to differences in the expected data between CD/GD and DVD/BD/HD-DVD. Unfortunately, some things only appear for certain media types when submitting. - The internal checks for these things _can_ be simplified a little, since many actually boil down to the existence of certain files and aren't actually locked to a particular media type. With the above, I will likely be trying to reduce the number of media-specific checks, but the dream of being entirely agnostic (or entirely reliant on program outputs to determine the media type) are not likely to happen soon.

claunia commented

2026-01-29 16:22:33 +00:00

@mnadareski commented on GitHub (Jul 18, 2025):

As an update here:

All processing code either doesn't care about the media type or is able to deal with getting the appropriate media type itself
MPF.Check no longer requires any media type, just the system

Until there is a way for DIC to have an agnostic dumping command, it will be nearly impossible to have the dumping step also be media type agnostic. This is an unfortunate reality that cannot be fixed from the side of MPF.

@mnadareski commented on GitHub (Jul 18, 2025): As an update here: - All processing code either doesn't care about the media type or is able to deal with getting the appropriate media type itself - MPF.Check no longer requires any media type, just the system Until there is a way for DIC to have an agnostic dumping command, it will be nearly impossible to have the dumping step also be media type agnostic. This is an unfortunate reality that cannot be fixed from the side of MPF.

claunia commented

2026-01-29 16:22:33 +00:00

@mnadareski commented on GitHub (Jul 18, 2025):

As of 2e9970ee6a, the processors are now fully decoupled from the dumping step. No matter what is selected in the UI, the output files will be trusted instead. This removes many of the biggest concerns around trusting user input.

This leaves the following open issues:

Lack of a generic dump command for DiscImageCreator
Unsure of how to support per-media-type dumping speed defaults if the media type is not available in the UI

@mnadareski commented on GitHub (Jul 18, 2025): As of https://github.com/SabreTools/MPF/commit/2e9970ee6a58e6caf7af02bb8c212618589060c9, the processors are now fully decoupled from the dumping step. No matter what is selected in the UI, the output files will be trusted instead. This removes many of the biggest concerns around trusting user input. This leaves the following open issues: - Lack of a generic `dump` command for DiscImageCreator - Unsure of how to support per-media-type dumping speed defaults if the media type is not available in the UI

claunia commented

2026-01-29 16:22:33 +00:00

@Deterous commented on GitHub (Jul 19, 2025):

Unsure of how to support per-media-type dumping speed defaults if the media type is not available in the UI

Maybe keep current media detection logic just for setting the dumping speed. Users can change it after of course, and media detection is still needed for DIC.

@Deterous commented on GitHub (Jul 19, 2025): > Unsure of how to support per-media-type dumping speed defaults if the media type is not available in the UI Maybe keep current media detection logic just for setting the dumping speed. Users can change it after of course, and media detection is still needed for DIC.

claunia commented

2026-01-29 16:22:34 +00:00

@Deterous commented on GitHub (Sep 29, 2025):

As of 89145df0fa, the media type box is now hidden unless DiscImageCreator is selected.
More of the code should be made MediaType-agnostic where possible, with the MediaType field only used for calling DiscImageCreator.
Preferably MPF.Check and MPF.CLI also only requiring MediaType when using DIC processor

@Deterous commented on GitHub (Sep 29, 2025): As of 89145df0fab2627a08e7943450f42a79aa3eb0bf, the media type box is now hidden unless DiscImageCreator is selected. More of the code should be made MediaType-agnostic where possible, with the MediaType field only used for calling DiscImageCreator. Preferably MPF.Check and MPF.CLI also only requiring MediaType when using DIC processor

Sign in to join this conversation.

1 Participants

Notifications

Due Date

No due date set.

Dependencies

No dependencies set.

Reference: SabreTools/MPF#805