fix(sony): don't emit a bogus InternalBodySerial for the A7 V

[narrative-donc]

Stack

Sony A7 V metadata — this PR targets #2, which carries the A7 V / A7R VI camera support it depends on.

1. feat: Sony A7R VI (ILCE-7RM6) support + general ARW6 canvas geometry #2 Sony A7R VI (ILCE-7RM6) support + general ARW6 canvas geometry
2. This PR — exclude the A7 V from the Tag9050d InternalBodySerial read ← this PR

Retarget to master if #2 lands first.

Problem

Every frame from a single Sony A7 V reports a different camera body serial. A 12-frame burst from one camera yields twelve distinct serials:

191100288e43, 180010000028, 44100000002, e0000000240,
4022290461,   4089480a0040, 400a0000000, 1c028432014,
a8a860040104, 404088004000, 28a104020012, 8082600

A body serial is constant by definition, so anything keying on camera identity breaks. This surfaced in a scene-clustering consumer that partitions by camera: a 2-second burst that should form one scene was split into twelve, because each frame looked like a different camera.

Root cause

SonyID_ILCE_7M5 is routed to the Tag9050d layout, which reads InternalBodySerial from six bytes at offset 0x38 of the 0x9050 block. Those bytes are not a body serial on this camera.

Measured across two bodies and both shipped firmwares:

Firmware v1.01 — 12-frame burst, twelve distinct values. The whole block is a different format here: it lacks the five-zero-byte prefix the Tag9050d layout carries, and nothing in it decodes. SonyFNumber reads 57511365 against a real f/2.8; ShutterCount ranges 320..8683552 within a two-second burst. Zero of the 256 raw (pre-decipher) bytes are constant across the burst — and since Sony's obfuscation is a fixed byte-substitution permutation, a constant plaintext byte must give a constant ciphertext byte. So no offset in the block holds a body serial for these files.

Firmware v1.00 — 11 samples from a second body. Here the block does carry the prefix and its other fields decode correctly (lens, aperture, ISO all match EXIF). But the six bytes at 0x38 still move between frames — three distinct values across a single session:

File(s)	Time	value
sony_a7_v_01	15:23	2cff0000b108
sony_a7_v_10	15:31	e1fe0000e908
sony_a7_v_20/30/40	15:58–16:12	37ff0000b908

The shape is always XX ff 00 00 YY 08 — a counter, not an identity.

So the field is wrong on v1.01 because the whole block is a different format, and wrong on v1.00 because 0x38 was never the serial there either.

Corroborating: exiftool reports InternalSerialNumber: 00000000 for all 11 v1.00 samples — it reads a different field and finds nothing.

Fix

Exclude the camera from this read, matching the existing idiom in the 9050a branch, which already excludes the NEX-5N, NEX-7 and NEX-VG20 from its own InternalBodySerial read.

Scoped to the serial read alone, not the whole block parse: on v1.00 the rest of 0x9050 decodes correctly, so CurAp, LensMount, LensType2 and ImageCount3 should keep working.

Bodies that do have an identity report it in EXIF BodySerialNumber, which is read elsewhere and is unaffected — the v1.00 samples keep BodySerial 02052278.

Verification

Built the library and ran it against 23 A7 V files from two bodies.

• InternalBodySerial now empty on all 23, across both firmwares.
• BodySerial 02052278 preserved on the six v1.00 samples that carry it.
• Lens, aperture and ISO still decode correctly on v1.00 (FE 50-150mm F2 GM, f/5.0, ISO 50).
• model still correctly ILCE-7M5 throughout.

No regressions on the other fixtures: Canon 5D Mark IV (025021000537), EOS 250D (042070001554), EOS 7D (1130703009), Nikon D5100 (6137104) body serials unchanged; Fuji X20's internal serial preserved; DSLR-A390 ARW unchanged.

Caveats

• The ILCE-7RM6 is deliberately not excluded. It shares the Tag9050d routing, so it was the obvious candidate to include — but two frames from one A7R VI body, 6.5 hours apart on firmware v1.01, both report 49ff00006809. Stable, unlike the A7 V, so it is left alone. (Two files from one body show the value is stable, not that it is genuinely a serial — a model-wide constant would look the same. A second body would settle it.) The ILCE-7RM5 was also checked out of interest: two frames 20 days apart both report d2fe00003b09, though it routes to Tag9050c and is unaffected by this change either way.
• The v1.01 / v1.00 split is a correlation across two sample sets from different sources, not same-body files on both firmwares. The exclusion doesn't depend on that causal claim — the field is unusable on both — but the firmware framing is inference, not proof.
• Related but not addressed here: the 0x9416 handler appears to miss the 7M5/7RM6 cumulative offset shifts, so real_ISO and some lens metadata are wrong for these bodies independently of 0x9050. Separately, on v1.01 files shutter and focal_len are also wrong (constant 1/1250 against a true 1/135–1/157; 200mm against a true 25.8mm).

[Copilot]

Pull request overview

This PR adjusts Sony maker-note parsing to avoid emitting an invalid, frame-varying InternalBodySerial for Sony ILCE-7M5 (A7 V) and ILCE-7RM6 (A7R VI) when the 0x9050 block does not match the expected Tag9050d signature.

Changes:

• Add an early-return gate in process_Sony_0x9050() for ILCE-7M5/7RM6 when the first five raw bytes of the 0x9050 block are not all zero (signature absent).
• Prevent downstream decoding of other Tag9050d fields from the same block in that unsupported/encrypted variant (consistent with the stated intent to avoid emitting garbage).

---

💡 Add a code-review agent skill or configure MCP servers for context-aware, tailored reviews. Learn more in the docs.