Here you go!

  https://gist.github.com/tenderlove/25853f50ab46a58738ff2cc22d682f2b

I ran both files through xxd then diffed them. I've literally changed every piece of hardware (at no small cost). "premature to immediately blame Apple" seems a bit off.

▲ jjcob 7 days ago | parent | next [-]

I tried running the file segments through a binary diff with Hex Fiend

As far as I can tell:

- 0x7800 bytes were replaced at file offset 0x00aa0000

- 0x2200 bytes were replaced at file offset 0x00aa8000

I can't tell if the replacement data came from a different part of the file, or somewhere totally different. Race condition somewhere sounds plausible.

▲

nickcw 7 days ago | parent [-]

gcd(0x2200,0x7800) = 512

So some part of the chain with 512 byte buffer size corrupted the data.

It doesn't look like a memory corruption but if this were my computer I'd run the equivalent of memtest86 on it.

It looks like a filing system corruption to me. Running `diskutil info` on the main harddisk and the sd card might be interesting to see if the block sizes match.

Running a disk tester on the sd card and the main disk might be a good idea too. Here is one I wrote: https://github.com/ncw/stressdisk

	▲	borisgolovnev 7 days ago \| parent [-]
		It's a shame APFS does nothing to ensure file integrity.

▲ daemin 7 days ago | parent | prev [-]

This is the kind of stuff that makes me wish my Binary Diff Tool was already completed, but unfortunately I'm still working on it. Can't tell much what's wrong with the differences in the bytes without knowing what the structure behind it is.