BRR files have no file header, meaning that there is a high chance that any random binary file is likely to be detected as BRR sample even though it shouldn't be. Hence OpenMPT verifies the integrity of the BRR sample blocks before allowing the file to load. Some of those checks are stricter than what the real hardware requires, and it is known that there are a few samples out there which won't pass this test. In particular, otherwise valid BRR files may get rejected if sample block indicates that the sample should be looped, and then a later sample block claims that the sample shouldn't be looped. This is what causes those files to be rejected.

While real SNES hardware won't care about this inconsistency (it only matters if the last sample block has the loop bit set), this test greatly helps with rejecting files that would otherwise be detected as BRR samples but in reality are just raw data or some other binary sample format. I would be very hesitant to remove this check as these BRR files are just not structurally sound for whatever reason (could be both a bug in the authoring tool or in whatever was used to extract them).

I was able to relax the file rejection heuristics a bit for files that only set the loop bit for frames that are inside the loop, so these files will load in the next OpenMPT version.