Read REAL channels wider than 128 bits as raw bytes instead of failing to open the file

[Enricoftw]

Problem

I have MDF 4.00 files from a measurement system that store a whole array (thousands of float32 values) as one REAL channel without a CA block, e.g. cn_bit_count = 115200. That is not spec conforming, but because of these channels the whole file can't be opened, although all other channels are fine:

TypeError: data type '<f14400' not understood

get_fmt_v4 returns f"<f{size // 8}" for such a channel. Integer channels wider than 64 bits are already caught and read as raw bytes (f"({size // 8},)u1").

Change

• get_fmt_v4: REAL channels wider than 128 bits (wider than any numpy float type) now get the same raw byte format as wide integer channels. REAL channels up to 128 bits keep their numeric dtypes, so float128 on platforms that have it and REAL channels with a bit offset behave as before.
• I return raw bytes rather than guessing an element type (float32 or float64?). Conversions still apply as usual; get(..., raw=True) returns the bytes unchanged.
• COMPLEX is left out on purpose, because 128-bit complex is valid and needs the numeric path.
• New regression test test_real_channel_wider_than_128_bits: it writes a byte array channel of 400 bytes per record and sets its cn_data_type to REAL (Intel and Motorola) in the file. It fails without the fix. With the fix the file opens, the other channel reads correctly and the payload comes back byte for byte. It also checks the 128-bit boundary in get_fmt_v4.

Verification

• My real files open, and every channel reads the same as with the workaround I used so far.
• I couldn't build the C extension locally, so I ran the library tests against the 8.8.27 wheel with this patch (get_fmt_v4 is identical on development). The only failures are two tests for fixes that exist only on development. ruff format and ruff check are clean.

get_fmt_v3 has the same pattern for MDF 3. I left it unchanged because I have no such file, but I'm happy to extend it if you like.

Thanks for asammdf!

Background: I vibe-coded a Python app with Claude Opus 5.5 that reads MDF files with asammdf. Opus found this issue while we were building it, and I asked it to prepare the fix and report it here for me. Fable 5.1 and GPT-6 Astra (via Codex) cross-reviewed the change. All tests and measurements were run locally on my machine.