Get rid of Carrier Type field

[bitsgalore]

Reasons:

• Current manual entry of carrierType in Iromlab is prone to entry errors,
• For an Iromlab operator, establishing the actual carrier type from the physical media is not always straightforward (e.g. cd-rom vs cd-video; cd-roms that turn out to contain audio, etc.)
• The actual carrier type is already established automatically and unambiguously by cd-info.

If we drop it altogether, volumeNumber sequence will simply cover all carriers that are part of a PPN (no grouping based on carrier type).

Related to:

https://github.com/KBNLresearch/iromlab/issues/67

[bitsgalore]

Addition/correction:

The actual carrier type is already established automatically and unambiguously by cd-info

Not if the carrier is a DVD, which shows up as "CD-ROM with unknown filesystem" in analysis report (CD-ROMs with HFS+ FS also give this result)!! It might be possible to distinguish between these cases heuristically. For instance, for DVDs the cd-info output often contains warning message like:

++ WARN: number of minutes (255) truncated to 99.

But I'm not sure this is sufficiently reliable (does this happen for a DVD with only 600 MB of data?). Or maybe use IsoBuster output:

 <metadata>
     <dc:type>DVD</dc:type>
 </metadata>

So maybe it's better to keep the Carrier Type entry field. The cd-info output could be used in addition to this to refine the entered values or to correct obvious mistakes.

[robdebruin]

Even though the type detection might not be 100% proof, it would at least be useful to give the user a hint. I now find myself checking on a regular basis if an optical carrier is cd-rom or audio.

[bitsgalore]

@robdebruin I think the solution here is that the "final" establishment of the carrier type should be done further down the processing chain (i.e. outside of Iromlab). Typically this would be at the SIP creation stage. For example, the combined values of the containsAudio, containsData, and cdExtra fields (derived from cd-info), and the isoBuster output (if it exists) should allow a SIP creation tool to establish the carrier type pretty much unambiguously for all cases I can think of. If so, there would be no need for the error-prone manual entry. But there might be some weird edge cases I'm overlooking for which a manually added classification would actually be helpful.

[bitsgalore]

Done: https://github.com/KBNLresearch/iromlab/commit/5e8b597016e0a9c8bb7dd580c32f8306fa156710