I believe I found a bug in the DNG converter (v184.108.40.2064/Mac with compatibility set to latest - ACR 7.1). Would post it through Adobe's bug reporting form but it doesn't seem to cover DNG converter (not on the list of apps), so I'm posting it here in the hope that somebody relevant will read it.
When converting Sony ARW-files (tested with Sony A7/ILCE-7 with ARW v2.3.1), DNG converter seems to be truncating the proprietary information it's copying over into the DNGPrivateData tag. Specifically, It's writing two Adobe-specific sections into the tag
- Sony MakerNote (Adobe-tag "MakN"): This seems to be fine
- Sony SR2-IFD, referenced from DNGPrivateData tag in ARW (Adobe-tag "SR2 "): Here DNG converter seems to truncate the SR2SubIFD (checked with hex-editor and Exiftool also refuses to parse it)
Context on the latter: Sony uses the DNGPrivateData tag in the ARW to reference an "SR2"-IFD (114 bytes in my case), which in turn references multiple sub-IFDs (known data structure is here: Sony Tags), the relevant of which seems to be the SR2SubIFD (tags 0x7200, 0x7201, 0x7220 in the SR2-structure give offset, length and encryption key). The SR2SubIFD (56958 bytes in my case) follows directly the SR2-IFD in the file structure.
DNG-converter seems to mean to copy the SR2-IFD and the SR2SubIFD into the Adobe-"SR2 " section of the DNG-DNGPrivateData tag. However, it seems to take the length of the SR2SubIFD and apply it to both structures (Adobe's "SR2 " length specified is 56964 in my case which is the SR2SubIFD length plus 4 bytes for the offset-filed and 2 bytes for the byte-order field), thereby truncating the SR2SubIFD by 114 bytes at the end (due to starting at the SR2-IFD in the beginning). I validated that the binary data seems to be identical between ARW and DNG for most of the SR2SubIFD and begins to diverge 114 bytes before its end.
Two possible solutions:
1) Fix DNG-converter to write the full SR2SubIFD. The SR2-IFD-length is not specified but can be deduced between its offset and the SubIFD offset (in case it's not always 114). Downside: the SR2-IFD contains pointers to other data-blocks (IDC_IFD, MRWinfo) which are not copied. Maybe not relevant but strictly speaking, having offsets to data outside the copied block is against the DNG-spec (although it's current behaviour)
2) Change DNG-converter behaviour and only copy the SR2SubIFD (introducing a new Adobe-tag). Would require additionally saving the encryption key from the SR2-IFD. Downside: changes current behaviour (and maybe other information in the SR2-block is relevant - there are some tags that are not publicly known/decoded yet)
Would appreciate some kind of acknowledgment in the comments that this is recognised (or correction if I'm wrong).