Yep, I'll chime in. The short answer is that it was a "bug" in MFC-Edit. I quote the "bug" because it was intentionally coded that way, but based on incorrect or outdated information. MFC-Edit is very strict about what it will and will not ingest. The Mk I/II dumps are not the same size or content as the Mk III dumps, further complicated by the contents of 3.0, 3.1,3.2,3.5,3.6 and 3.7 being different content. MFC-Edit checks the Equipment Model and the Firmware version to know how to extract the data from the dump. I had learned some time ago that after 3.0 there'd be no new firmware features for the Mark I/II, so MFC_Edit did not test for FW 3.5 and above on the Mk I/II. So it misidendified the data as invalid because it as a Mk I/II dump but with a 3.7 FM and rejected it as invalid. While I wasn't up to speed on the new firmware for the Mark I/II, I commend FAS for continuing to keep it FW current with the Mark III.
I've come up with some additional checks that I can add to the code so that it doesn't rely solely on the Model and Firmware information to determine which data stream version it is looking at. It might slow down the opening of a sysexdump by a millisecond or two but well worth it to save users the grief that Mike just endured.
It may be a week or two - I really need to test it with a lot of combinations of Model/FW before the new version is available.
I've come up with some additional checks that I can add to the code so that it doesn't rely solely on the Model and Firmware information to determine which data stream version it is looking at. It might slow down the opening of a sysexdump by a millisecond or two but well worth it to save users the grief that Mike just endured.
It may be a week or two - I really need to test it with a lot of combinations of Model/FW before the new version is available.