MPF icon indicating copy to clipboard operation
MPF copied to clipboard

[Request] Ignore useless volume labels

Open Deterous opened this issue 1 year ago • 1 comments

Currently MPF outputs ISO volume labels that are useless, e.g. [T:VOL] Young, YOUNG (ISO) or [T:VOL] LIVINGFACTORY (ISO), LivingFactory (Joliet)

TODO: Add logic to delete useless volume labels. Compare them after removing spaces/underscores and normalising case. Drop empty volume labels after this. And ensure that if only one volume label is left, don't add the brackets

e.g. the output after this should be [T:VOL] Young and ``[T:VOL] LivingFactory`

Deterous avatar Sep 03 '24 15:09 Deterous

Strongly request a toggle in options to include them anyway. I'd like to still have them and having it off by default will let the mods be happy.

PurpleNekoNova avatar Sep 05 '24 03:09 PurpleNekoNova

Is there a preferred order to the "accepted" labels? Like does Windows always take precedence over Joliet? Or if they match (ignoring case), is it always the one that includes at least one lower-case character?

mnadareski avatar Oct 10 '24 15:10 mnadareski

Windows > UDF > ISO > Joliet Windows probably is UDF anyway. Honestly I've only seen bad results from the joliet label. Maybe it's coded wrong for DIC log parsing..? (my fault if so)

Deterous avatar Oct 10 '24 15:10 Deterous

The current formatting code doesn't take into account where the labels are coming from when formatting. It just assumes that they're organized properly. That is, there is no actual distinction between UDF, ISO, and Joliet when the formatting happens. If we go with the hierarchy, that will require special checking cases. Also worth noting that it actually doesn't do any sort of comparisons between labels at the moment.

mnadareski avatar Oct 10 '24 16:10 mnadareski

As discussed in Discord, part of the issue here is needing to rebuild the current mapping dictionary based on the "correct" labels. For a human user, this is nearly trivial to point out, regardless of what the source of the label is. For a computer, it's a bit harder, since either the key in the dictionary needs to be normalized OR a separate mapping needs to be made from the key to the "real label". Neither of these are trivial to implement and neither scales particularly well.

mnadareski avatar Oct 10 '24 17:10 mnadareski

Currently, labels exists as a mapping of actual volume labels to zero or more filesystem names ("ISO", "Joliet", "UDF", "UNKNOWN") It should be possible to compare the volume labels and pick the one with the better filesystem. There is no need to determine which is better through heuristics (which has case sensitivity, etc).

For example: labels = a mapping of "EXAMPLE_DISC" = (ISO, Joliet) and "Example Disc" = (UDF)

  1. Drop all underscores, spaces, and unicode (foreign language characters) from both labels
  2. Compare without case sensitivity string.Equals(a, b, StringComparison.OrdinalIgnoreCase)
  3. If they are equal, look at the filesystems that the labels are attached to and drop the one that is lower in the heirarchy, in this case UDF is kept over ISO+Joliet. If a label does not have a filesystem, that one is chosen (i.e. it is the Windows one).
  4. Repeat for all remaining labels in the mapping

Note: this logic should occur here: https://github.com/SabreTools/MPF/blob/83a189a5d399ae81a8accc77eed2419073e3911d/MPF.Frontend/Tools/SubmissionGenerator.cs#L414 i.e. after checking that at least one label exists, but before the check for only one label.

Deterous avatar Oct 11 '24 03:10 Deterous

You're proposing a static readonly list that defines the hierarchy. It also seems like you're suggesting the "highest ranked" out of each set of label sources would be considered.

mnadareski avatar Oct 11 '24 11:10 mnadareski

Another request as part of this: don't put any volume labels in submissionInfo for Xbox/Xbox360.

Deterous avatar Oct 23 '24 14:10 Deterous

Initial filtering has been added. Additional, smarter filtering taking the source into account is needed.

mnadareski avatar Dec 15 '24 00:12 mnadareski

#780 / #781 has implemented what I wanted, so I'm closing this issue. A TODO remains in the code if someone wants to do this "properly", but the cases where the current implementation falls short are currently rare and will not occur with Redumper logs at all.

In cases where the ISO9660 volume label is superficially different, it will no longer appear in the submission info, but the Redumper .log file still has the ISO9660 volume label if this is ever desired.

Deterous avatar Dec 15 '24 03:12 Deterous