[Investigation] Internal Media Type Agnostic

[mnadareski]

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.

[mnadareski]

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]

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]

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]

As of 2e9970e, 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

[Deterous]

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]

As of 89145df, 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