I have encountered flash recovery cases where internal tables or markers were corrupted. Reading certain blocks via the normal card interface would return garbage or zeroes, but reading the flash chip and reconstructing the translation layer produced workable data.
Another possible cause (already mentioned) is a card with several flash chips, where one chip has a bad connection. The card might reach ready state on the other flash chip, and will return garbage or zeroes when reading data from the disconnected flash chip.
In both cases, the controller chip fails to retrieve data for certain LBA's and returns 'invented' data.
Advice for the original poster:
You could try analyzing the clone you made from the card. If parts of the file system look overwritten by garbage or zeroes, see if you can find a repeating pattern in that corruption. For example, corruption might always come in blocks of 16KB (or another power of 2). Or the same garbage pattern shows up in many different places. Those are telltale signs of a controller that fails to read the original data.
On the other hand: If the original data is lost because it is overwritten, the filesystem should contain information (artefacts / artifacts, choose your continent

that that match that scenario, like files with recent creation dates and/or deleted dir entries (assuming FAT32).
Good luck,
Erik