feat: MXF index table infrastructure and restripe optimization

[nathanpbutler]

Summary

• Phase 1: Direct-Write Optimization - Removes unnecessary read/seek pattern from restripe operations, reducing I/O by ~50% per System packet
• Phase 2: Index Table Infrastructure - Adds PartitionPack and MxfIndex models for parsing MXF partition packs and index tables, enabling future frame-level seeking
• Adds Index/HasIndex properties to MXF class with stub for index loading from footer partition

Changes

• lib/Handlers/MXFHandler.cs - Optimized restripe methods, moved timebase validation to once-per-file
• lib/Core/PartitionPack.cs - New model for parsing MXF partition pack data (big-endian)
• lib/Core/MxfIndex.cs - New model for CBE/VBE index table offset calculations
• lib/Keys.cs - Added partition pack and index table key constants
• lib/Formats/MXF.cs - Added Index/HasIndex properties and LoadIndexTable stub

Test Plan

• All 390 existing tests pass
• New multi-frame restripe verification test
• PartitionPack parsing tests (valid data, short data, zero footer)
• MxfIndex offset calculation tests (CBE, VBE, bounds checking)

In general, to fix generic catch clauses, identify the set of exceptions that are realistically expected from the operations in the try block and catch those explicitly, possibly grouped by base type (e.g., IOException). Avoid catching non-CLS or catastrophic exceptions, and optionally rethrow unknown exceptions. This makes the intent clear and avoids silently handling unexpected errors.

For LoadIndexTable in lib/Formats/MXF.cs, the risky operations are: seeking and reading from a Stream (Input.Seek, Input.Read), allocating arrays, reading BER length, and parsing the partition pack (PartitionPack.Parse). The most appropriate categories of expected exceptions here are IOException (and derived types like EndOfStreamException) for stream problems and FormatException (or some parsing-related exception) for invalid partition/BER data. We want to preserve the current behavior of “on any expected error, just return null”, but we should not silently catch everything.

The best minimal-change fix is:

• Replace the bare catch with one or more specific catch clauses, e.g.:
  • catch (IOException) for IO-related failures.
  • catch (FormatException) for malformed data during parsing/BER decoding.
• Optionally, keep a final catch (Exception) that rethrows (throw;) if you want stricter behavior. However, that would change the method’s external behavior by no longer always returning null on unexpected errors. To avoid changing functionality, we should not add such a rethrow here.
• Since there are no System.IO or System imports shown in the snippet, and IOException / FormatException live in System and System.IO, we must add using System; and using System.IO; at the top of MXF.cs.

Concretely:

• In LoadIndexTable, replace:

        try
        {
            ...
        }
        catch
        {
            return null; // Graceful fallback on any error
        }

with:

        try
        {
            ...
        }
        catch (IOException)
        {
            return null; // Graceful fallback on I/O errors
        }
        catch (FormatException)
        {
            return null; // Graceful fallback on malformed MXF structures
        }

• At the top of MXF.cs, add using System; and using System.IO; above or among the existing using declarations.

This keeps the method’s visible behavior (returning null on expected failures) while eliminating the generic catch clause.

[claude]

Code review

No issues found. Checked for bugs and CLAUDE.md compliance.