2 ms·
Seems like the bitrot is kicking in already. The main JPEG appears to have bitflip errors: http://totallynormalwebsite.ddns.net/megafloppy.jpg http://totallynor
by Retr0id 4y ago
Seems like the bitrot is kicking in already. The main JPEG appears to have bitflip errors: http://totallynormalwebsite.ddns.net/megafloppy.jpg http://totallynormalwebsite.ddns.net/megafloppy.jpg
This is what I get, when I download the full image and convert to PNG: https://i.imgur.com/JF4wtMg.png https://i.imgur.com/JF4wtMg.png
During the conversion (with imagemagick), I get these errors:
convert: Corrupt JPEG data: premature end of data segment `megafloppy.jpg' @ warning/jpeg.c/JPEGWarningHandler/403.
convert: Corrupt JPEG data: found marker 0x74 instead of RST1 `megafloppy.jpg' @ warning/jpeg.c/JPEGWarningHandler/403.
convert: Corrupt JPEG data: 206 extraneous bytes before marker 0xfb `megafloppy.jpg' @ warning/jpeg.c/JPEGWarningHandler/403.
convert: Corrupt JPEG data: found marker 0xfb instead of RST2 `megafloppy.jpg' @ warning/jpeg.c/JPEGWarningHandler/403.
convert: Unsupported marker type 0xfb `megafloppy.jpg' @ warning/jpeg.c/JPEGErrorHandler/345.
Looking closer, all bytes between offset 0x115C00 and 0x11F800 have been set to 0xf6, and all bytes from there until 0x11FC00 have been set to 0.
Bytes from 0x2EFC00 to 0x2F5C00 have been set to 0, followed by 0xf6's all the way until 0x2FFC00.
I'd be curious to know what failure mode(s) conjured the 0xf6's into existence.
Edit: Original version is here https://web.archive.org/web/20220715175852if_/http://totallynormalwebsite.ddns.net/megafloppy.jpg https://web.archive.org/web/20220715175852if_/http://totally...
- kop316 4y agoheh, that's even worse than when I saw it: https://i.imgur.com/Z2HwkwY.jpeg https://i.imgur.com/Z2HwkwY.jpeg
- game-of-throws 4y agoI managed to grab a (hopefully) uncorrupted version somehow. I'm putting it somewhere other than imgur so they don't recompress the image. MD5 d30fcc384a8e2de4fab3056bde42b00b. [EDIT: Removed dead link, use archive.org instead] > I'd be curious to know what failure mode(s) conjured the 0xf6's into existence. Today's fun fact: The MS-DOS `format` command fills the disk with 0xf6, not 0x00. Though this is linux running on Mac hardware, reading a disk that should have actual data, so maybe that isn't the reason.
- Retr0id 4y agoPerhaps the read head seeked (sought?) to the wrong offset, causing empty blocks to be read.
- birdyrooster 4y agoThe link you gave is deleted.
- game-of-throws 4y agoThanks, edited. I guess they didn't like all the traffic. Luckily archive.org has a copy too.
- shakna 4y ago> Today's fun fact: The MS-DOS `format` command fills the disk with 0xf6, not 0x00. Another fun fact: That character is ö under Windows-1252, the codepage in use by Windows since about Windows 2.0, and some late MS-DOS.
- therein 4y agoWow that explains the öööööööö I remember seeing back in the day when I first ever downloaded a hex editor and opened a drive I had raw.
- inDigiNeous 4y agoFunny co-incidence, in the Finnish language when you don't know what to say, you can say "Ööh". Data not found.
- q1w2 4y agohmm... is it possible to correct those errors? I have some old images with errors, and I've always wondered if it were possible to fix the individual corrupted bytes to restore at least the remainder of the photos.
- upwardbound 4y agoYes it's possible, the SpaceX subreddit community did that to recover imagery from one of the early rocket landings which was corrupted due to poor antenna alignment between the transmitter on the landing barge and the remote receiver.