ReadMultiplex.com: How the Digital Age Is Erasing Itself—And The 1000 Year Disc That Refuses to Die. ၏ စာသားမှတ်တမ်းအပြည့်အစုံ

And this brings up a really fascinating 00:03:40.639 --> 00:03:42.620 framework from our sources for understanding 00:03:42.620 --> 00:03:45.819 why this happens. Any digital file is essentially 00:03:45.819 --> 00:03:49.340 governed by two competing countdown clocks. Yeah, 00:03:49.400 --> 00:03:52.139 the two clocks framework is essential here because 00:03:52.139 --> 00:03:54.840 it divides this illusion of digital permanence 00:03:54.840 --> 00:03:57.580 into two very distinct factors of failure. So 00:03:57.580 --> 00:03:59.580 the first is what we call the mediums clock, 00:03:59.819 --> 00:04:03.020 which represents pure physics and mechanical 00:04:03.020 --> 00:04:06.110 engineering. OK, break that down for us. Well, 00:04:06.169 --> 00:04:08.250 information has to be inscribed onto a physical 00:04:08.250 --> 00:04:10.830 substrate, right? And that substrate degrades 00:04:10.830 --> 00:04:13.229 over time. Take magnetic tape, for instance. 00:04:13.550 --> 00:04:16.670 Tape was the absolute gold standard for enterprise 00:04:16.670 --> 00:04:20.170 backups for decades. But magnetic tape is governed 00:04:20.170 --> 00:04:25.170 by coercivity. Coercivity. Yeah, it's the tendency 00:04:25.170 --> 00:04:27.350 of the magnetic particles to just lose their 00:04:27.350 --> 00:04:30.410 charge over time or be completely messed up by 00:04:30.410 --> 00:04:33.459 ambient magnetic fields. And furthermore... Tape 00:04:33.459 --> 00:04:35.879 requires an incredibly complex, fast -moving 00:04:35.879 --> 00:04:39.339 mechanical tape deck just to be read. Right. 00:04:39.379 --> 00:04:41.339 And if the manufacturing of those specific tape 00:04:41.339 --> 00:04:44.500 decks stopped like 15 years ago, the tape itself 00:04:44.500 --> 00:04:46.839 just becomes a plastic brick regardless of whether 00:04:46.839 --> 00:04:49.120 the magnetic charge on it is actually still intact. 00:04:50.100 --> 00:04:52.959 Precisely the issue. And we saw this heavily 00:04:52.959 --> 00:04:56.519 with microfilm and microfiche, which were heavily 00:04:56.519 --> 00:04:59.160 relied upon by libraries and institutions between 00:04:59.160 --> 00:05:03.910 roughly 1870 and 1970. The medium's clock for 00:05:03.910 --> 00:05:06.370 microfilm involves the physical decay of the 00:05:06.370 --> 00:05:08.850 film base itself, sometimes resulting in what 00:05:08.850 --> 00:05:12.389 archivists call vinegar syndrome. Vinegar syndrome. 00:05:12.529 --> 00:05:15.410 It sounds awful. It is. It's where the cellulose 00:05:15.410 --> 00:05:18.350 acetate degrades and literally off -gases acetic 00:05:18.350 --> 00:05:21.269 acid, so it smells like vinegar. But the clock 00:05:21.269 --> 00:05:23.629 also involves the optics. You need a very specific 00:05:23.629 --> 00:05:26.550 reader, a really precise focal lens, and a high 00:05:26.550 --> 00:05:29.189 -intensity halogen lamp just to project it. So 00:05:29.189 --> 00:05:30.990 the hardware to read the medium fails before 00:05:30.990 --> 00:05:34.079 the medium itself. Exactly. And a modern hard 00:05:34.079 --> 00:05:36.180 drive is no different. We view them as these 00:05:36.180 --> 00:05:38.639 magic black boxes on our desks, but a hard drive 00:05:38.639 --> 00:05:41.660 is basically a microscopic jet engine. A jet 00:05:41.660 --> 00:05:44.300 engine. I mean, think about it. It consists of 00:05:44.300 --> 00:05:46.660 multiple metallic platters spinning at 7 ,200 00:05:46.660 --> 00:05:49.420 revolutions per minute, with a reed right head 00:05:49.420 --> 00:05:51.759 flying mere nanometers above the surface on a 00:05:51.759 --> 00:05:54.759 cushion of air. It requires these tiny fluid 00:05:54.759 --> 00:05:57.740 dynamic bearings that must not seize up, and 00:05:57.740 --> 00:06:00.220 a delicate actuator arm that absolutely must 00:06:00.220 --> 00:06:03.389 not crash. The medium's clock is relentless because 00:06:03.389 --> 00:06:06.110 basic thermodynamics and friction guarantee that 00:06:06.110 --> 00:06:08.449 complex mechanical systems will eventually fail. 00:06:08.730 --> 00:06:11.550 Okay, so that physical clock makes total sense. 00:06:11.910 --> 00:06:14.670 Everything physical wears out eventually. But 00:06:14.670 --> 00:06:17.290 it's this second clock that feels much more treacherous 00:06:17.290 --> 00:06:19.449 for the average person today, which is the access 00:06:19.449 --> 00:06:22.470 points clock. Right. So the access points clock 00:06:22.470 --> 00:06:25.149 is entirely administrative and bureaucratic. 00:06:25.310 --> 00:06:28.329 In our current era, most people do not hold their 00:06:28.329 --> 00:06:31.470 data. They hold a key to a remote server. Like 00:06:31.470 --> 00:06:34.509 iCloud or Google Drive. Exactly. A cloud object 00:06:34.509 --> 00:06:36.810 depends on an unbroken chain of administrative 00:06:36.810 --> 00:06:39.649 realities. It requires the hosting corporation 00:06:39.649 --> 00:06:43.069 to remain solvent. It requires the service contract 00:06:43.069 --> 00:06:46.149 or the end user license agreement to remain totally 00:06:46.149 --> 00:06:49.930 unchanged. It relies on API endpoints remaining 00:06:49.930 --> 00:06:53.069 active, a valid login credential that hasn't 00:06:53.069 --> 00:06:56.189 been flagged by some automated security algorithm. 00:06:57.040 --> 00:06:59.420 and a credit card that has not expired. That's 00:06:59.420 --> 00:07:02.079 the scary part. If you are hospitalized for three 00:07:02.079 --> 00:07:05.240 months, your credit card expires, and you miss 00:07:05.240 --> 00:07:06.980 the warning emails because you're incapacitated, 00:07:07.079 --> 00:07:09.839 that entire administrative pillar collapses. 00:07:10.319 --> 00:07:13.060 The file hasn't physically degraded. The magnetic 00:07:13.060 --> 00:07:15.560 charges representing your family photos are technically 00:07:15.560 --> 00:07:17.800 still sitting on a server rack in an Amazon or 00:07:17.800 --> 00:07:20.740

Google data center somewhere in Virginia, but 00:07:20.740 --> 00:07:24.139 they are gone to you. Archivists actually refer 00:07:24.139 --> 00:07:27.389 to this as dark data. The bits exist on a physical 00:07:27.389 --> 00:07:30.189 platter somewhere. But functionally, the information 00:07:30.189 --> 00:07:32.750 has vanished from the human record because the 00:07:32.750 --> 00:07:35.029 administrative bridge to reach it has just been 00:07:35.029 --> 00:07:38.269 severed. And we have massive historical precedent 00:07:38.269 --> 00:07:40.790 showing how quickly this administrative clock 00:07:40.790 --> 00:07:44.149 can run out on a truly global scale. Oh, man. 00:07:44.329 --> 00:07:47.050 MySpace is the textbook example of this, isn't 00:07:47.050 --> 00:07:50.550 it? When we look back at the early 2000s, MySpace 00:07:50.550 --> 00:07:52.509 was the epicenter of global Internet culture. 00:07:52.970 --> 00:07:55.170 Millions of musicians used it as their primary 00:07:55.170 --> 00:07:58.509 and often their only distribution platform. Yeah. 00:07:59.069 --> 00:08:03.009 And then in 2019, MySpace issued a rather quiet 00:08:03.009 --> 00:08:05.389 statement confirming that a server migration 00:08:05.389 --> 00:08:09.009 had resulted in the catastrophic loss of essentially 00:08:09.009 --> 00:08:12.310 all music uploaded to the platform between 2003 00:08:12.310 --> 00:08:16.129 and 2015. It's just mind -blowing. We're talking 00:08:16.129 --> 00:08:19.069 about the complete erasure of roughly 50 million 00:08:19.069 --> 00:08:23.370 songs from 14 million artists. Just gone. But 00:08:23.370 --> 00:08:26.089 wait, how does a basic server migration wipe 00:08:26.089 --> 00:08:29.160 out 50 million files? You would assume a tech 00:08:29.160 --> 00:08:32.179 giant has redundancies upon redundancies for 00:08:32.179 --> 00:08:34.240 that sort of thing. You would assume so. But 00:08:34.240 --> 00:08:36.899 in these complex database architectures, the 00:08:36.899 --> 00:08:39.340 data is often separated from the pointers that 00:08:39.340 --> 00:08:42.220 locate it. So during a massive migration from 00:08:42.220 --> 00:08:44.980 old storage arrays to new ones, if the database 00:08:44.980 --> 00:08:47.460 schema linking the user profiles to the specific 00:08:47.460 --> 00:08:50.340 file paths on the storage volumes becomes corrupted, 00:08:50.580 --> 00:08:54.440 those files become orphaned. Oh, wow. So the 00:08:54.440 --> 00:08:56.820 system literally forgets where the files live. 00:08:57.059 --> 00:09:00.419 Exactly. Even if the underlying audio files were 00:09:00.419 --> 00:09:03.100 temporarily still on the old servers, if the 00:09:03.100 --> 00:09:06.080 index is destroyed and the old servers are subsequently 00:09:06.080 --> 00:09:08.340 wiped or decommissioned before the engineering 00:09:08.340 --> 00:09:10.759 team catches the error, the data is irreversibly 00:09:10.759 --> 00:09:14.019 gone. MySpace's later advice to users to

basically 00:09:14.019 --> 00:09:16.960 keep your own backups was this grim admission 00:09:16.960 --> 00:09:19.320 that the platform was never an archive to begin 00:09:19.320 --> 00:09:22.100 with. It was merely a temporary hosting service. 00:09:22.730 --> 00:09:24.889 It wiped out an entire generation's cultural 00:09:24.889 --> 00:09:28.559 output. Just vanished. And then there was the 00:09:28.559 --> 00:09:32.539 photobucket situation. In 2017, they initiated 00:09:32.539 --> 00:09:35.059 what essentially amounted to a hostage situation. 00:09:35.769 --> 00:09:38.070 Because photobucket was the backbone of image 00:09:38.070 --> 00:09:40.269 hosting for thousands of early internet forums. 00:09:40.529 --> 00:09:43.429 eBay listings and personal blogs, right? People 00:09:43.429 --> 00:09:45.409 would upload a photo there and embed the link 00:09:45.409 --> 00:09:48.509 somewhere else. Right, and overnight, photobucket 00:09:48.509 --> 00:09:51.360 just... altered their terms of service, completely 00:09:51.360 --> 00:09:53.779 prohibiting free third -party image hosting. 00:09:54.000 --> 00:09:57.200 They replaced millions of embedded images across 00:09:57.200 --> 00:10:00.620 the entire public web with a generic massive 00:10:00.620 --> 00:10:04.659 banner demanding that users pay a $399 annual 00:10:04.659 --> 00:10:07.240 subscription to unlock their photos. It's wild. 00:10:08.330 --> 00:10:10.509 Relying on modern digital storage under these 00:10:10.509 --> 00:10:13.169 conditions feels exactly like renting an apartment 00:10:13.169 --> 00:10:15.309 where the landlord holds the absolute legal right 00:10:15.309 --> 00:10:17.409 to just arbitrarily change the locks while you 00:10:17.409 --> 00:10:19.940 were at work. They can suddenly triple the rent, 00:10:20.039 --> 00:10:22.220 or they can just demolish the entire building 00:10:22.220 --> 00:10:25.179 while you're on vacation. You don't possess the 00:10:25.179 --> 00:10:27.980 space where your memories live. You are just 00:10:27.980 --> 00:10:30.799 visiting under their temporary grace. The landlord 00:10:30.799 --> 00:10:33.500 analogy is perfectly accurate. You are merely 00:10:33.500 --> 00:10:36.799 a tenant in the cloud ecosystem. If publicly 00:10:36.799 --> 00:10:38.960 traded corporations with massive engineering 00:10:38.960 --> 00:10:42.240 teams are accidentally or... intentionally wiping 00:10:42.240 --> 00:10:45.139 out millions of cultural artifacts, either through 00:10:45.139 --> 00:10:47.240 sheer negligence during a migration or through 00:10:47.240 --> 00:10:50.320 aggressive monetization strategies, we have to 00:10:50.320 --> 00:10:53.159 seriously examine the infrastructure we all rely 00:10:53.159 --> 00:10:56.580 on every single day. We are experiencing what 00:10:56.580 --> 00:10:59.820 data scientists call the great divergence. Okay, 00:10:59.879 --> 00:11:02.679 the great divergence. This is the widening gap 00:11:02.679 --> 00:11:04.600 between the

sheer volume of data we generate 00:11:04.600 --> 00:11:07.240 as a species and the amount we actually retain. 00:11:07.840 --> 00:11:10.000 I really want to dig into the scale of this because 00:11:10.000 --> 00:11:13.340 the numbers are almost hallucinatory. The International 00:11:13.340 --> 00:11:16.000 Data Corporation, the IDC, tracks the global 00:11:16.000 --> 00:11:18.360 creation of data. And their projection for the 00:11:18.360 --> 00:11:21.600 year 2025 is that human civilization will create 00:11:21.600 --> 00:11:26.419 218 .4 zettabytes of data. Which is a number 00:11:26.419 --> 00:11:29.879 so large it loses meaning. To contextualize a 00:11:29.879 --> 00:11:31.899 zettabyte, it really helps to step up the ladder. 00:11:32.080 --> 00:11:35.620 So a gigabyte is roughly a symphony in high fidelity 00:11:35.620 --> 00:11:39.200 audio. A terabyte is a large physical library 00:11:39.200 --> 00:11:43.059 of books. A petabyte is the entire digital archive 00:11:43.059 --> 00:11:46.980 of the Library of Congress. An exabyte is a thousand 00:11:46.980 --> 00:11:50.539 petabytes. We are currently generating roughly 00:11:50.539 --> 00:11:55.700 600 exabytes of data every single day. 600 ,000 00:11:55.700 --> 00:11:58.440 times the digital footprint of the Library of 00:11:58.440 --> 00:12:02.460 Congress every 24 hours. That is genuinely hard 00:12:02.460 --> 00:12:04.519 to wrap my head around. But the critical metric 00:12:04.519 --> 00:12:08.009 here is retention. The IDC reported that in 2020, 00:12:08.289 --> 00:12:11.389 less than 2 % of the data created or replicated 00:12:11.389 --> 00:12:14.490 was actually saved into the following year. So 00:12:14.490 --> 00:12:17.330 98 % of everything digital evaporates almost 00:12:17.330 --> 00:12:20.450 instantly. Now, I have to challenge this slightly. 00:12:20.649 --> 00:12:24.570 I hear that 2 % retention number, but I look 00:12:24.570 --> 00:12:27.700 around. We have more server farms being built 00:12:27.700 --> 00:12:30.299 than ever before in history. Hyperscale data 00:12:30.299 --> 00:12:32.440 centers are consuming significant percentages 00:12:32.440 --> 00:12:35.940 of national power grids. Apple, Google. Microsoft, 00:12:36.159 --> 00:12:38.840 they offer terabytes of cloud storage to consumers 00:12:38.840 --> 00:12:41.809 for the price of a cup of coffee. We clearly 00:12:41.809 --> 00:12:44.769 do not lack the physical capacity to store data. 00:12:45.669 --> 00:12:48.850 So why is the web decaying so rapidly if we have 00:12:48.850 --> 00:12:52.009 seemingly infinite room to store it? Why is link 00:12:52.009 --> 00:12:54.870 rot a worsening crisis? Because while we have 00:12:54.870 --> 00:12:57.250 the capacity, the architecture of the web itself 00:12:57.250 --> 00:13:00.110 is fundamentally antithetical to permanence. 00:13:00.370 --> 00:13:03.289 We really have to examine the nature of a hyperlink. 00:13:03.409 --> 00:13:06.879 A link is not a document. It is not possession. 00:13:07.360 --> 00:13:10.519 A web link is nothing more than a temporary string 00:13:10.519 --> 00:13:13.139 of text pointing to a specific directory on a 00:13:13.139 --> 00:13:15.899 specific server, sitting in a specific geographic 00:13:15.899 --> 00:13:18.960 location operated by a specific company under 00:13:18.960 --> 00:13:22.259 a very specific financial model. So it's a pointer, 00:13:22.320 --> 00:13:24.779 not the thing itself. Exactly. When you click 00:13:24.779 --> 00:13:27.580 a link, your browser makes a DNS request to resolve 00:13:27.580 --> 00:13:30.200 an IP address and basically asks that server 00:13:30.200 --> 00:13:32.850 to hand over a file. If that company goes out 00:13:32.850 --> 00:13:35.210 of business, if they rebrand and change their 00:13:35.210 --> 00:13:37.850 URL structure, or if a systems administrator 00:13:37.850 --> 00:13:40.090 simply moves a file from one folder to another 00:13:40.090 --> 00:13:42.730 without setting up a proper redirect, that citation 00:13:42.730 --> 00:13:46.789 resolves to a 404 error. Link rot is the inevitable 00:13:46.789 --> 00:13:49.289 result of treating temporary network addresses 00:13:49.289 --> 00:13:53.070 as permanent historical citations. The page was 00:13:53.070 --> 00:13:55.149 never in the reader's possession to begin with. 00:13:55.350 --> 00:13:57.730 You essentially memorize the driving directions 00:13:57.730 --> 00:14:00.879 to a library. But the city bulldozed the library 00:14:00.879 --> 00:14:03.659 to build a parking lot. The directions are perfect, 00:14:03.799 --> 00:14:07.240 but the destination is just gone. And the statistics 00:14:07.240 --> 00:14:10.240 on this web decay from our sources are deeply 00:14:10.240 --> 00:14:13.779 unsettling. A 2024 Pew Research study analyzed 00:14:13.779 --> 00:14:17.519 millions of web pages. They found that 38 % of 00:14:17.519 --> 00:14:20.799 web pages that existed in 2013 were completely 00:14:20.799 --> 00:14:24.179 eradicated a decade later. And the acceleration 00:14:24.179 --> 00:14:27.240 of that decay is the truly alarming part. Because 00:14:27.240 --> 00:14:29.879 the same study found that pages created in 2021 00:14:29.879 --> 00:14:32.980 were going missing at a rate of roughly one in 00:14:32.980 --> 00:14:36.220 five within just two years. One in five? Yeah. 00:14:36.340 --> 00:14:40.279 We are losing 20 % of our immediate digital history 00:14:40.279 --> 00:14:43.340 almost as fast as we generate it. And this isn't 00:14:43.340 --> 00:14:45.779 just affecting obscure personal blogs from 2005 00:14:45.779 --> 00:14:49.740 or defunct local businesses. It is eroding the 00:14:49.740 --> 00:14:51.639 foundational pillars of our shared knowledge. 00:14:52.360 --> 00:14:55.299 Just look at Wikipedia. We treat Wikipedia as 00:14:55.299 --> 00:14:57.919 the modern, indestructible library of Alexandria. 00:14:58.279 --> 00:15:01.340 But Wikipedia is entirely built on citations. 00:15:01.519 -->

00:15:04.240 Without citations, it's just a collection of 00:15:04.240 --> 00:15:07.059 unsourced claims from anonymous users. And yet, 00:15:07.159 --> 00:15:10.620 54 % of Wikipedia pages contain at least one 00:15:10.620 --> 00:15:13.399 reference link to a webpage that no longer exists. 00:15:13.899 --> 00:15:16.700 And the epistemological crisis is even more severe 00:15:16.700 --> 00:15:19.820 in academia and medicine. A recent analysis demonstrated 00:15:19.820 --> 00:15:22.419 that the inaccessibility of web references in 00:15:22.419 --> 00:15:26.080 medical journals rises to over 41 % within five 00:15:26.080 --> 00:15:28.840 years of publication. That's terrifying. Think 00:15:28.840 --> 00:15:30.360 about the implications of that for a second. 00:15:30.500 --> 00:15:32.740 A peer -reviewed medical paper is published, 00:15:33.000 --> 00:15:35.720 making a vital claim based on external data sets 00:15:35.720 --> 00:15:38.669 or previous online research. Five years later, 00:15:38.809 --> 00:15:41.450 nearly half of the evidence supporting that paper 00:15:41.450 --> 00:15:44.169 cannot be verified by a new researcher because 00:15:44.169 --> 00:15:47.269 the links are simply dead. The foundational bedrock 00:15:47.269 --> 00:15:49.929 of scientific reproducibility is crumbling because 00:15:49.929 --> 00:15:53.009 it relies on temporary URLs. But wait, surely 00:15:53.009 --> 00:15:55.009 the Internet Archive and the Wayback Machine 00:15:55.009 --> 00:15:56.990 are solving this, right? That's their entire 00:15:56.990 --> 00:15:59.850 mandate. I mean, if I hit a dead link in an article, 00:16:00.009 --> 00:16:02.570 my first instinct is to immediately plug it into 00:16:02.570 --> 00:16:04.210 the Wayback Machine to find the cached version. 00:16:04.580 --> 00:16:06.820 The Internet Archive is an invaluable resource, 00:16:07.039 --> 00:16:10.419 obviously, but it is not a panacea. And it is 00:16:10.419 --> 00:16:12.519 heavily constrained by the administrative clock 00:16:12.519 --> 00:16:15.379 we talked about earlier. A comprehensive study 00:16:15.379 --> 00:16:19.379 analyzing 27 .3 million archived URLs within 00:16:19.379 --> 00:16:22.559 the Internet Archive found that only 35 .3 % 00:16:22.559 --> 00:16:27.279 were still accessible and alive by 2023. Really? 00:16:27.600 --> 00:16:30.799 Why is that number so low? If the Archive crawls 00:16:30.799 --> 00:16:32.840 a page and saves it on their servers, shouldn't 00:16:32.840 --> 00:16:35.639 it be permanent? It comes down to how the modern 00:16:35.639 --> 00:16:38.799 web is constructed. In the early 2000s, web pages 00:16:38.799 --> 00:16:42.820 were mostly static HTML text documents. A web 00:16:42.820 --> 00:16:45.360 crawler could easily ingest and save the entire 00:16:45.360 --> 00:16:49.340 page. Today, the web is heavily reliant on complex 00:16:49.340 --> 00:16:52.240 JavaScript frameworks, dynamic database calls, 00:16:52.440 --> 00:16:55.240 and highly personalized content delivered through 00:16:55.240 --> 00:16:59.000 APIs. A web crawler often cannot bypass a login 00:16:59.000 --> 00:17:01.950 wall. or it simply cannot execute the complex 00:17:01.950 --> 00:17:05.910 JavaScript required to render the text. Oh, so 00:17:05.910 --> 00:17:08.109 it just captures a blank loading screen, essentially. 00:17:08.450 --> 00:17:12.029 In many cases, yes. Furthermore, what we call 00:17:12.029 --> 00:17:15.849 deep links, URLs that point directly to a specific 00:17:15.849 --> 00:17:19.470 PDF, a high -resolution image, or a subdirectory 00:17:19.470 --> 00:17:22.730 dataset rather than a top -level homepage, have 00:17:22.730 --> 00:17:25.769 a terrifyingly short lifespan. The half -life 00:17:25.769 --> 00:17:30.099 of a deep link is just one year. One year. Only 00:17:30.099 --> 00:17:32.559 about 4 % of deep links survive beyond a decade. 00:17:33.000 --> 00:17:35.359 The archive cannot catch everything. And even 00:17:35.359 --> 00:17:38.039 when it does, it often only catches the visual 00:17:38.039 --> 00:17:40.259 facade of the page, not the deep data behind 00:17:40.259 --> 00:17:42.779 it. This paints a really grim picture of the 00:17:42.779 --> 00:17:45.720 public Internet. It is essentially an untended 00:17:45.720 --> 00:17:48.440 garden built on transient financial contracts. 00:17:48.859 --> 00:17:50.900 But I know what you, the listener, are thinking 00:17:50.900 --> 00:17:54.460 right now. You were thinking, OK, sure, the public 00:17:54.460 --> 00:17:57.279 web is rotting and Wikipedia links are breaking. 00:17:57.900 --> 00:18:02.089 But my personal data is different. I pay for 00:18:02.089 --> 00:18:05.430 a premium Google One subscription. I have a beefy 00:18:05.430 --> 00:18:07.269 two terabyte external hard drive sitting right 00:18:07.269 --> 00:18:09.910 next to my laptop. I use Apple's time machine. 00:18:10.289 --> 00:18:13.630 My home ecosystem is perfectly curated and safe. 00:18:13.829 --> 00:18:16.369 And that false sense of security is actually 00:18:16.369 --> 00:18:18.890 the most dangerous element of personal data management. 00:18:19.009 --> 00:18:21.630 To dismantle that illusion, we have to shift 00:18:21.630 --> 00:18:25.079 our temporal perspective entirely. We have to 00:18:25.079 --> 00:18:27.720 look at what data scientists call the 25 -year 00:18:27.720 --> 00:18:31.319 horizon. The 25 -year horizon. This is brilliant 00:18:31.319 --> 00:18:33.319 because it forces you out of the day -to -day 00:18:33.319 --> 00:18:36.619 mindset. 25 years is roughly one working lifetime. 00:18:37.019 --> 00:18:39.740 It's the span between the birth of a child and 00:18:39.740 --> 00:18:43.039 them graduating from college. So let's look back 00:18:43.039 --> 00:18:46.240 exactly 25 years from today, back to roughly 00:18:46.240 --> 00:18:49.309 2001. Think about the hardware and the storage 00:18:49.309 --> 00:18:52.500 mediums you were using in 2001. We were relying

00:18:52.500 --> 00:18:56.440 on Iomega zip disks. We were using mini DV tapes 00:18:56.440 --> 00:18:59.420 to record home videos on camcorders. We were 00:18:59.420 --> 00:19:02.259 carefully burning CDRs using massive desktop 00:19:02.259 --> 00:19:05.259 towers. The early digital cameras used compact 00:19:05.259 --> 00:19:08.220 flash cards that held like 16 megabytes of data. 00:19:08.420 --> 00:19:11.539 Right. Now ask yourself, how much of that 2001 00:19:11.539 --> 00:19:14.000 media can you seamlessly mount and read on the 00:19:14.000 --> 00:19:17.200 ultra -thin laptop you are using today? You likely 00:19:17.200 --> 00:19:19.740 do not have a SCSI port for the zip drive. You 00:19:19.740 --> 00:19:22.680 definitely do not have a FireWire 400 port to 00:19:22.680 --> 00:19:25.839 ingest the mini DV tape. Most modern laptops 00:19:25.839 --> 00:19:28.119 haven't had a built -in optical CD drive in over 00:19:28.119 --> 00:19:30.619 a decade. Yeah, I'd have no way to plug any of 00:19:30.619 --> 00:19:33.279 that in. Exactly. You might be able to recover 00:19:33.279 --> 00:19:35.299 some of that data by hunting down specialist 00:19:35.299 --> 00:19:38.640 legacy hardware on eBay, buying old cables, and 00:19:38.640 --> 00:19:40.579 running virtual machines with legacy operating 00:19:40.579 --> 00:19:43.839 systems. But for the average consumer, that data 00:19:43.839 --> 00:19:46.839 is functionally unreadable. One working lifetime 00:19:46.839 --> 00:19:49.440 completely obliterates consumer digital media. 00:19:49.599 --> 00:19:52.000 It is not a theoretical risk. We have already 00:19:52.000 --> 00:19:54.279 lived through the empirical proof of it. And 00:19:54.279 --> 00:19:56.579 the reason standard backup methods fail over 00:19:56.579 --> 00:19:59.680 this 25 -year timeline is due to a mathematical 00:19:59.680 --> 00:20:02.099 concept that completely shattered my confidence 00:20:02.099 --> 00:20:04.779 in my own setup when I read the source material. 00:20:05.039 --> 00:20:08.599 It is called the compounding arithmetic of failure. 00:20:09.519 --> 00:20:11.599 Let's break this down, starting with the cloud, 00:20:11.740 --> 00:20:14.740 because people just assume that Google or Amazon's 00:20:14.740 --> 00:20:17.480 massive multi -billion dollar data centers offer 00:20:17.480 --> 00:20:20.619 immunity to failure. The hardware in a Google 00:20:20.619 --> 00:20:23.380 data center is indeed highly redundant, but your 00:20:23.380 --> 00:20:25.299 access to it is subject to the administrative 00:20:25.299 --> 00:20:27.420 clock. Let's look at Google's standing policy. 00:20:27.599 --> 00:20:30.160 As of recent updates, a personal Google account 00:20:30.160 --> 00:20:33.119 that remains inactive for two years may be entirely 00:20:33.119 --> 00:20:36.990 deleted. Entirely? Yes. That includes everything 00:20:36.990 --> 00:20:39.730 stored in Gmail, Google Drive, and Google Photos. 00:20:39.769 --> 00:20:43.130 So if you pass away, or if you suffer a severe 00:20:43.130 --> 00:20:46.250 cognitive decline and forget your password, or 00:20:46.250 --> 00:20:48.910 you are simply offline for a protracted period 00:20:48.910 --> 00:20:52.869 like an illness, your absence triggers an automated 00:20:52.869 --> 00:20:55.329 corporate deletion policy. It's not a server 00:20:55.329 --> 00:20:57.690 crash. It's literally a script running on a schedule 00:20:57.690 --> 00:21:01.849 designed to free up server space. Exactly. It's 00:21:01.849 --> 00:21:04.299 just a cleanup routine. And even if you remain 00:21:04.299 --> 00:21:06.460 active, what happens when you want to migrate 00:21:06.460 --> 00:21:08.900 your data out of the cloud? Say the subscription 00:21:08.900 --> 00:21:11.779 price quadruples over the next decade. Cloud 00:21:11.779 --> 00:21:13.880 providers utilize what are called egress fees. 00:21:14.460 --> 00:21:17.180 They make it incredibly cheap, often completely 00:21:17.180 --> 00:21:19.660 free to upload your data. But when you want to 00:21:19.660 --> 00:21:22.440 download terabytes of your own files to move 00:21:22.440 --> 00:21:24.940 to a competing service, they charge you exorbitant 00:21:24.940 --> 00:21:27.640 bandwidth fees. So they trap you. They financially 00:21:27.640 --> 00:21:29.859 trap you inside their ecosystem at the exact 00:21:29.859 --> 00:21:32.700 moment that leaving becomes necessary. The cloud 00:21:32.700 --> 00:21:35.599 is a hotel. It is not a vault. Okay, so the cloud 00:21:35.599 --> 00:21:38.700 is vulnerable to administrative failure and financial 00:21:38.700 --> 00:21:42.279 capture. What about local hardware? I have an 00:21:42.279 --> 00:21:44.220 external hard drive sitting quietly in my desk 00:21:44.220 --> 00:21:46.819 drawer. It is protected from the elements. It's 00:21:46.819 --> 00:21:48.640 not being bumped around in a backpack on the 00:21:48.640 --> 00:21:51.299 subway. Surely a hard drive that is safely stored 00:21:51.299 --> 00:21:54.440 away is a permanent archive. You'd think so, 00:21:54.619 --> 00:21:56.740 but let's look at the failure rates of mechanical 00:21:56.740 --> 00:22:00.819 hard drives. Backblaze is a major cloud storage 00:22:00.819 --> 00:22:02.940 and backup provider, and they publish highly 00:22:02.940 --> 00:22:05.519 detailed reliability statistics on their massive 00:22:05.519 --> 00:22:08.460 fleet of hard drives. Their data shows that even 00:22:08.460 --> 00:22:11.000 enterprise -grade drives running continuously 00:22:11.000 --> 00:22:13.859 in climate -controlled, vibration -mitigated 00:22:13.859 --> 00:22:16.920 server racks fail at an annualized rate of around 00:22:16.920 --> 00:22:21.200 1 .36%. Which doesn't sound terrible for a server 00:22:21.200 --> 00:22:24.579 farm. No, but a hard drive sitting unpowered 00:22:24.579 --> 00:22:26.940 in your desk drawer is mechanically in a far 00:22:26.940 --> 00:22:30.119 worse position. This counterintuitive fact amazed

00:22:30.119 --> 00:22:33.339 me. You assume that turning a device off preserves 00:22:33.339 --> 00:22:35.859 its lifespan. How is an idle hard drive worse 00:22:35.859 --> 00:22:39.220 off than one spinning 24 -7? Because a hard drive 00:22:39.220 --> 00:22:42.500 is fundamentally mechanical. Inside that sealed 00:22:42.500 --> 00:22:45.119 casing, the platters spin on bearings lubricated 00:22:45.119 --> 00:22:48.319 by specialized fluids. When a drive sits unpowered 00:22:48.319 --> 00:22:50.900 for years, those fluid lubricants settle and 00:22:50.900 --> 00:22:54.259 degrade. The mechanical tolerances are so microscopic 00:22:54.259 --> 00:22:56.759 that when you finally plug that drive in after 00:22:56.759 --> 00:22:59.420 five or ten years of sitting idle, the spindle 00:22:59.420 --> 00:23:01.859 motor often lacks the torque to overcome the 00:23:01.859 --> 00:23:04.039 stiction, the static friction of the settled 00:23:04.039 --> 00:23:07.579 bearings. Oh, wow. So it just seizes up. The 00:23:07.579 --> 00:23:10.740 drive simply refuses to spin up. Or worse, the 00:23:10.740 --> 00:23:13.019 reed right heads stick to the platters and physically 00:23:13.019 --> 00:23:15.359 scratch the magnetic surface, destroying the 00:23:15.359 --> 00:23:17.710 data instantly. A hard drive is designed for 00:23:17.710 --> 00:23:20.470 constant operation. Three to five years is a 00:23:20.470 --> 00:23:23.750 responsible, reliable operational lifespan. Planning 00:23:23.750 --> 00:23:26.309 to use a hard drive as a 25 -year archival vessel 00:23:26.309 --> 00:23:29.509 is an engineering fallacy. Okay, but what about 00:23:29.509 --> 00:23:33.269 SSDs? Solid -state drives. They have completely 00:23:33.269 --> 00:23:35.450 taken over the market. They are small. They are 00:23:35.450 --> 00:23:38.430 incredibly fast. And crucially, they have zero 00:23:38.430 --> 00:23:40.750 moving parts. There are no bearings to seize 00:23:40.750 --> 00:23:44.450 up. I use external SSDs for everything now. Unpowered 00:23:44.450 --> 00:23:47.490 consumer SSDs are arguably even more precarious 00:23:47.490 --> 00:23:49.809 for long -term cold storage than mechanical drives. 00:23:50.009 --> 00:23:52.490 We have to understand how NAND flash memory, 00:23:52.730 --> 00:23:55.170 which is the core technology of an SSD, actually 00:23:55.170 --> 00:23:58.650 stores data. An SSD does not use magnetism. It 00:23:58.650 --> 00:24:01.049 stores data by trapping microscopic pools of 00:24:01.049 --> 00:24:03.349 electrons inside billions of microscopic cells, 00:24:03.529 --> 00:24:05.990 specifically within a component called a floating 00:24:05.990 --> 00:24:08.569 gate transistor. So it's essentially holding 00:24:08.569 --> 00:24:11.589 an electrical charge in a tiny microscopic cage. 00:24:11.809 --> 00:24:15.509 Correct. But those cages are not perfectly impermeable. 00:24:15.589 --> 00:24:18.670 Over time, due to the laws of physics and ambient 00:24:18.670 --> 00:24:21.690 thermal energy, those trapped electrons slowly 00:24:21.690 --> 00:24:23.829 leak out through the oxide insulation layer. 00:24:24.170 --> 00:24:27.049 If enough electrons leak from a cell, the controller 00:24:27.049 --> 00:24:29.309 can no longer determine if that cell represents 00:24:29.309 --> 00:24:33.500 a digital one or a zero. The data corrupts. When 00:24:33.500 --> 00:24:35.660 an SSD is plugged into a computer and powered 00:24:35.660 --> 00:24:38.539 on, the drive's controller constantly runs background 00:24:38.539 --> 00:24:41.160 algorithms to check cell voltage and rewrite 00:24:41.160 --> 00:24:44.140 data to refresh the charge. But if it's sitting 00:24:44.140 --> 00:24:46.700 in a drawer? If it is unpowered, that refresh 00:24:46.700 --> 00:24:49.779 cycle never happens. The official standards body 00:24:49.779 --> 00:24:52.640 for microelectronics, JEDEC, publishes client 00:24:52.640 --> 00:24:55.720 requirements for SSD retention. The standard 00:24:55.720 --> 00:24:58.839 guarantees a minimum of only one year of data 00:24:58.839 --> 00:25:01.460 retention for a consumer drive powered off. and 00:25:01.460 --> 00:25:03.420 stored at 30 degrees Celsius, which is about 00:25:03.420 --> 00:25:06.599 86 degrees Fahrenheit, essentially the temperature 00:25:06.599 --> 00:25:09.900 of a warm room or a closet in the summer. One 00:25:09.900 --> 00:25:15.420 single year. Wait, people are buying $300 SSDs, 00:25:15.440 --> 00:25:18.099 loading their entire family's video history onto 00:25:18.099 --> 00:25:20.799 them, tossing them into a fire safe in the garage, 00:25:20.920 --> 00:25:24.279 and assuming they are good for decades. It is 00:25:24.279 --> 00:25:26.900 a qualification floor, meaning the drive might 00:25:26.900 --> 00:25:29.680 last longer, perhaps. three to five years, depending 00:25:29.680 --> 00:25:32.099 on the exact NAND architecture and storage temperature. 00:25:32.619 --> 00:25:35.940 But the physics remain unchanged. Thermal energy 00:25:35.940 --> 00:25:39.519 guarantees electron leakage. An SSD is a brilliant 00:25:39.519 --> 00:25:42.400 high -speed working drive. It is a catastrophic 00:25:42.400 --> 00:25:46.539 long -term archival medium. So let's bring this 00:25:46.539 --> 00:25:48.480 back to the compounding arithmetic of failure. 00:25:49.140 --> 00:25:52.039 If the cloud, mechanical hard drives, and solid 00:25:52.039 --> 00:25:54.240 -state drives all carry these inherent annual 00:25:54.240 --> 00:25:56.799 risks, what does the math actually look like 00:25:56.799 --> 00:26:00.299 over a 25 -year horizon? The mathematics of probability 00:26:00.299 --> 00:26:03.440 compounding are just unforgiving. Let's assume 00:26:03.440 --> 00:26:05.599 you have a storage strategy. Maybe it's a cloud 00:26:05.599 --> 00:26:07.720 account or an external drive that faces just 00:26:07.720 --> 00:26:10.779 a 4 % chance of a fatal event in any given year. 00:26:11.000 --> 00:26:14.559 A 4 % risk

means there is a 96 % chance your 00:26:14.559 --> 00:26:17.339 data survives the year intact. That feels incredibly 00:26:17.339 --> 00:26:20.460 safe, right? Yeah, 96 % sounds great. But over 00:26:20.460 --> 00:26:24.480 25 years, you must multiply 0 .96 by itself 25 00:26:24.480 --> 00:26:27.819 times. When you do that, the chance of your archive 00:26:27.819 --> 00:26:30.700 surviving the full quarter century drops to approximately 00:26:30.700 --> 00:26:35.759 36%. A 4 % annual risk translates to nearly a 00:26:35.759 --> 00:26:38.339 two -thirds chance of total catastrophic loss 00:26:38.339 --> 00:26:41.559 over a working lifetime. And 4 % is an incredibly 00:26:41.559 --> 00:26:44.619 optimistic baseline. If we factor in typical 00:26:44.619 --> 00:26:47.900 household chaos, spilled coffee, a stolen laptop, 00:26:48.180 --> 00:26:51.119 an expired credit card, a forgotten cloud password, 00:26:51.359 --> 00:26:55.279 a 10 % annual risk is a much more realistic assessment. 00:26:56.170 --> 00:26:59.309 At a 10 % annual risk, the survival rate of your 00:26:59.309 --> 00:27:04.630 data over 25 years is just 7%. 7%. That means 00:27:04.630 --> 00:27:06.950 catastrophic failure isn't just a possibility. 00:27:06.990 --> 00:27:10.009 It is a statistical near certainty. You don't 00:27:10.009 --> 00:27:11.789 need a house fire to lose everything. You just 00:27:11.789 --> 00:27:14.950 need one bad year out of 25 to wipe out the other 00:27:14.950 --> 00:27:18.039 24. Now, I want to introduce a counter -argument 00:27:18.039 --> 00:27:20.200 here, because I know the tech enthusiasts listening 00:27:20.200 --> 00:27:23.059 are waiting for this. What about a NAS, a network 00:27:23.059 --> 00:27:25.859 -attached storage device? Many serious photographers 00:27:25.859 --> 00:27:28.519 and tech -savvy people have a multi -bay NAS 00:27:28.519 --> 00:27:30.960 sitting in their home network closet. They run 00:27:30.960 --> 00:27:33.759 RAID arrays, redundant array of independent disks, 00:27:33.980 --> 00:27:36.440 where the data is automatically striped and mirrored 00:27:36.440 --> 00:27:39.039 across multiple hard drives. If one drive physically 00:27:39.039 --> 00:27:41.000 breaks, the data is perfectly mirrored on the 00:27:41.000 --> 00:27:43.299 others, and you just slot in a replacement drive. 00:27:43.619 --> 00:27:46.180 Isn't that the ultimate foolproof safe? This 00:27:46.180 --> 00:27:48.240 is perhaps the most vital distinction in data 00:27:48.240 --> 00:27:51.500 management. A NAS running a RAID array provides 00:27:51.500 --> 00:27:55.319 availability, not archivability. Break down the 00:27:55.319 --> 00:27:57.759 mechanics of why that matters. RAID architecture 00:27:57.759 --> 00:28:02.099 is designed to solve one specific problem. Uninterrupted 00:28:02.099 --> 00:28:04.880 uptime in the event of a single mechanical component 00:28:04.880 --> 00:28:08.180 failure. If disk number two in a four -disk array 00:28:08.180 --> 00:28:10.859 suffers a read -write head crash, the RAID controller 00:28:10.859 --> 00:28:13.700 uses parity data or mirroring on the other disks 00:28:13.700 --> 00:28:16.099 to seamlessly keep your files accessible while 00:28:16.099 --> 00:28:18.740 you replace the broken drive. That is availability. 00:28:19.299 --> 00:28:22.480 However, RAID does absolutely nothing to protect 00:28:22.480 --> 00:28:24.880 you against systemic or environmental failures. 00:28:25.240 --> 00:28:27.720 Systemic failures like what? If your home network 00:28:27.720 --> 00:28:29.960 is breached and a ransomware payload executes, 00:28:29.980 --> 00:28:32.519 it will instantly encrypt the primary drive and 00:28:32.519 --> 00:28:35.319 immediately mirror that encryption across every 00:28:35.319 --> 00:28:38.440 redundant drive in the array. Your data is perfectly, 00:28:38.680 --> 00:28:41.960 redundantly destroyed. If a power surge circumvents 00:28:41.960 --> 00:28:44.119 your surge protector, it can fry the entire chassis 00:28:44.119 --> 00:28:46.839 and every drive inside it simultaneously. Or, 00:28:46.839 --> 00:28:49.579 as the scenario goes, if a pipe bursts in your 00:28:49.579 --> 00:28:52.200 ceiling while you're at work and floods the office, 00:28:52.240 --> 00:28:54.500 the NAS enclosure, the redundant drives inside 00:28:54.500 --> 00:28:56.980 it, and the router controlling it are all sitting 00:28:56.980 --> 00:29:00.420 in the exact same puddle of water. Precisely. 00:29:00.700 --> 00:29:03.779 A NAS is a phenomenal tool for a working professional 00:29:03.779 --> 00:29:06.579 who cannot afford an hour of downtime while editing 00:29:06.579 --> 00:29:10.400 a video project. But it is not an archive. An 00:29:10.400 --> 00:29:12.160 archive is a medium that survives completely 00:29:12.160 --> 00:29:14.700 independently of your current electrical, network, 00:29:14.839 --> 00:29:17.480 and hardware infrastructure. Okay, so if we summarize 00:29:17.480 --> 00:29:20.079 everything up to this point, the public web is 00:29:20.079 --> 00:29:22.940 a fragile facade, cloud services are hostile 00:29:22.940 --> 00:29:25.599 to long -term ownership, mechanical hard drives 00:29:25.599 --> 00:29:29.960 seize up, SSDs bleed electrons, and expensive 00:29:29.960 --> 00:29:32.660 NAS setups are just redundant vulnerability. 00:29:33.200 --> 00:29:36.119 It sounds like an utterly impossible, overwhelming 00:29:36.119 --> 00:29:40.230 crisis. I can imagine you, the listener, staring 00:29:40.230 --> 00:29:42.690 at your laptop right now, paralyzed by the sheer 00:29:42.690 --> 00:29:45.450 volume of data you think you need to save and 00:29:45.450 --> 00:29:47.789 the apparent lack of any viable medium to save 00:29:47.789 --> 00:29:50.789 it on. But this is the exact moment where this 00:29:50.789 --> 00:29:53.589 deep dive pivots from outlining the problem to 00:29:53.589 --> 00:29:55.970 delivering an incredibly liberating solution. 00:29:56.430 -->

00:30:00.029 Because the anxiety we feel is mostly based on 00:30:00.029 --> 00:30:02.809 an illusion. What if the amount of data that 00:30:02.809 --> 00:30:05.930 genuinely matters, the human record we discussed 00:30:05.930 --> 00:30:08.890 earlier, is exponentially smaller than we fear? 00:30:09.349 --> 00:30:12.150 This is the concept of the camera roll scale. 00:30:12.470 --> 00:30:15.589 The primary source of data anxiety is the illusion 00:30:15.589 --> 00:30:18.630 of massiveness. We look at our laptops and phones 00:30:18.630 --> 00:30:21.849 and see terabytes of consumed storage. We assume 00:30:21.849 --> 00:30:24.990 our personal legacy is petabytes of data. But 00:30:24.990 --> 00:30:27.230 when you analytically strip away the digital 00:30:27.230 --> 00:30:30.569 noise, the reality is astonishingly manageable. 00:30:31.029 --> 00:30:34.089 Let's define the noise. Your phone's storage 00:30:34.089 --> 00:30:37.549 is filled with cached application data. Massive 00:30:37.549 --> 00:30:40.410 operating system updates, 4K movies downloaded 00:30:40.410 --> 00:30:43.470 for a flight, gigabytes of podcasts you've already 00:30:43.470 --> 00:30:46.690 listened to, and thousands of blurry, rapid -fire 00:30:46.690 --> 00:30:49.829 duplicate photos. None of that is your legacy. 00:30:50.150 --> 00:30:53.789 Exactly. When you isolate the pure human memories, 00:30:53.849 --> 00:30:57.509 the curated photos, the specific videos of major 00:30:57.509 --> 00:31:00.349 life events, the scanned legal and historical 00:31:00.349 --> 00:31:04.609 documents, the scale shrinks dramatically. A 00:31:04.609 --> 00:31:07.109 comprehensive 2026 study of smartphone users 00:31:07.109 --> 00:31:09.930 analyzed the actual contents of median photo 00:31:09.930 --> 00:31:12.829 libraries. They found that the typical user has 00:31:12.829 --> 00:31:16.990 a library consisting of just 2 ,547 photos and 00:31:16.990 --> 00:31:20.849 127 videos. That number feels shockingly low, 00:31:20.950 --> 00:31:22.769 but it really highlights how much of our perceived 00:31:22.769 --> 00:31:26.349 data bloat is just software overhead. And there 00:31:26.349 --> 00:31:29.690 was another stat in that study from our sources 00:31:29.809 --> 00:31:32.250 that really proves the silent decay we talked 00:31:32.250 --> 00:31:36.859 about. Of the oldest photos sitting on a typical 00:31:36.859 --> 00:31:41.059 smartphone is only 2 .7 years. That is a staggering 00:31:41.059 --> 00:31:43.740 metric. It is. It proves that users are routinely, 00:31:43.940 --> 00:31:46.940 quietly losing their older photographic history. 00:31:47.400 --> 00:31:50.079 When they upgrade phones or when a cloud sync 00:31:50.079 --> 00:31:52.859 fails silently in the background, they lose the 00:31:52.859 --> 00:31:55.140 older files and simply adapt to the new baseline. 00:31:55.599 --> 00:31:57.640 They don't even realize the history has been 00:31:57.640 --> 00:32:00.059 truncated. But let's look at the gigabyte footprint 00:32:00.059 --> 00:32:02.900 of those 2 ,500 photos because this is where 00:32:02.900 --> 00:32:05.160 the anxiety truly dissolves. Let's do the exact 00:32:05.160 --> 00:32:08.559 math on the camera roll. How big is a memory? 00:32:08.740 --> 00:32:11.579 A modern smartphone camera, typically 12 to 48 00:32:11.579 --> 00:32:14.079 megapixels, uses highly efficient compression 00:32:14.079 --> 00:32:17.099 algorithms. Apple, for instance, uses the HEIC 00:32:17.099 --> 00:32:19.740 format, which is based on high -efficiency video 00:32:19.740 --> 00:32:22.720 coding. It utilizes complex spatial prediction 00:32:22.720 --> 00:32:25.019 to compress image data without losing visual 00:32:25.019 --> 00:32:29.099 fidelity. A standard 12 -megapixel HEIC photo 00:32:29.099 --> 00:32:31.700 consumes roughly 2 to 3 megabytes of storage 00:32:31.700 --> 00:32:34.839 space. If you shoot in older JPEG formats, it 00:32:34.839 --> 00:32:37.960 might be 4 to 6 megabytes. Now, let's introduce 00:32:37.960 --> 00:32:41.220 the baseline archival medium, a standard single 00:32:41.220 --> 00:32:44.380 -layer optical Blu -ray disc, which holds 25 00:32:44.380 --> 00:32:48.740 gigabytes of data. 25 ,000 megabytes. So if we 00:32:48.740 --> 00:32:51.490 do the division. One single 25 gigabyte disc 00:32:51.490 --> 00:32:56.049 can hold approximately 7 ,500 HEIC format photographs? 00:32:56.410 --> 00:32:59.529 Yes. A typical individual's entire smartphone 00:32:59.529 --> 00:33:01.769 camera roll, representing years, potentially 00:33:01.769 --> 00:33:05.230 a decade of their life, fits onto one single 00:33:05.230 --> 00:33:08.309 physical disc with gigabytes of room to spare. 00:33:08.529 --> 00:33:11.569 Even for an avid amateur photographer who curates 00:33:11.569 --> 00:33:15.569 a library of 15 ,000 vital photos, their entire 00:33:15.569 --> 00:33:19.609 legacy is safely stored on two thin discs. It 00:33:19.609 --> 00:33:22.890 is the digital equivalent of a shoebox. You do 00:33:22.890 --> 00:33:26.009 not need an enterprise server rack. A physical 00:33:26.009 --> 00:33:28.650 Blu -ray disc is a millimeter thick. You can 00:33:28.650 --> 00:33:30.569 hold your entire photographic history between 00:33:30.569 --> 00:33:33.799 your thumb and forefinger. Now, we do have to 00:33:33.799 --> 00:33:36.079 address the elephant in the room regarding storage 00:33:36.079 --> 00:33:39.700 space, which is video. Because modern phones 00:33:39.700 --> 00:33:42.319 default to shooting video in incredible resolutions. 00:33:42.920 --> 00:33:45.819 And video consumes storage at an exponentially 00:33:45.819 --> 00:33:48.809 faster rate than photography. Video is the hidden 00:33:48.809 --> 00:33:51.750 tax on storage, definitely. While videos might 00:33:51.750 --> 00:33:54.349 only represent 5 % of the files in your library, 00:33:54.630 --> 00:33:58.269 they will easily consume 40 to 50 % of your storage 00:33:58.269 --> 00:34:01.670 capacity.

Let's look at the bit rates. One minute 00:34:01.670 --> 00:34:04.569 of 4K resolution video, shot at a standard 60 00:34:04.569 --> 00:34:08.130 frames per second, requires roughly 400 megabytes 00:34:08.130 --> 00:34:11.050 of storage. So you're eating up nearly half a 00:34:11.050 --> 00:34:13.010 gigabyte every 60 seconds you leave the camera 00:34:13.010 --> 00:34:16.510 rolling. Correct. Extrapolating that... An hour 00:34:16.510 --> 00:34:19.309 of standard 4K home video will effectively fill 00:34:19.309 --> 00:34:23.590 one 25 -gigabyte disk. However, even when factoring 00:34:23.590 --> 00:34:26.570 in heavy video usage, the scale remains remarkably 00:34:26.570 --> 00:34:29.969 finite. If we analyze a family of four, all taking 00:34:29.969 --> 00:34:32.269 photos and recording major milestones over an 00:34:32.269 --> 00:34:35.929 entire 25 -year generational span, the mathematics 00:34:35.929 --> 00:34:39.130 show that a stack of just 20 disks is sufficient 00:34:39.130 --> 00:34:41.869 to archive the entire family's visual legacy. 00:34:42.269 --> 00:34:45.530 20 disks. That is a stack roughly an inch high. 00:34:45.880 --> 00:34:48.679 sitting on a bookshelf. That is the true scale 00:34:48.679 --> 00:34:51.400 of your digital life. The risk isn't that you 00:34:51.400 --> 00:34:54.039 lack the capacity or the wealth to build an archive. 00:34:54.260 --> 00:34:57.800 The risk is simply procrastination. It is failing 00:34:57.800 --> 00:34:59.900 to spend the afternoon organizing those files 00:34:59.900 --> 00:35:02.300 and committing them to the shelf before the cloud 00:35:02.300 --> 00:35:04.860 provider changes their terms or the hard drive 00:35:04.860 --> 00:35:07.719 seizes up. But this naturally leads to the most 00:35:07.719 --> 00:35:10.360 critical technical question of the entire deep 00:35:10.360 --> 00:35:13.420 dive. If you're nodding along, realizing you 00:35:13.420 --> 00:35:15.940 only need to burn 20 discs to save your family's 00:35:15.940 --> 00:35:18.760 history, you are also likely remembering the 00:35:18.760 --> 00:35:21.280 early 2000s. You're remembering buying spindles 00:35:21.280 --> 00:35:23.420 of cheap CD -Rs from an office supply store, 00:35:23.719 --> 00:35:26.179 burning a mix CD for a road trip, and finding 00:35:26.179 --> 00:35:28.280 that it skipped, failed, and became completely 00:35:28.280 --> 00:35:30.980 unreadable six months later. Why should anyone 00:35:30.980 --> 00:35:33.500 trust their family's legacy to a plastic disc? 00:35:33.960 --> 00:35:36.340 What makes modern archival discs any different 00:35:36.340 --> 00:35:38.619 from the junk we used to burn? To understand 00:35:38.619 --> 00:35:41.440 the solution, we have to deeply examine the chemistry 00:35:41.440 --> 00:35:44.380 of permanence. We have to dissect why those old 00:35:44.380 --> 00:35:48.079 CD -Rs and DVD -Rs failed so miserably. A standard 00:35:48.079 --> 00:35:50.920 writable optical disc consists of a polycarbonate 00:35:50.920 --> 00:35:53.920 plastic substrate, a recording layer, a reflective 00:35:53.920 --> 00:35:56.519 metallic layer, and a protective lacquer coating. 00:35:56.880 --> 00:36:00.659 The fatal flaw in consumer CD -Rs was the composition 00:36:00.659 --> 00:36:03.460 of the recording layer. They relied on organic 00:36:03.460 --> 00:36:07.429 dyes. typically cyanine, thalassianine, or azo 00:36:07.429 --> 00:36:10.269 dyes. When you say organic dye, you essentially 00:36:10.269 --> 00:36:13.809 mean complex chemical paints? Exactly. The burning 00:36:13.809 --> 00:36:16.690 process for a standard CDR involved the drive's 00:36:16.690 --> 00:36:19.469 laser firing into that organic dye layer, rapidly 00:36:19.469 --> 00:36:21.989 heating it, and causing a chemical reaction that 00:36:21.989 --> 00:36:24.750 permanently darkened microscopic spots. These 00:36:24.750 --> 00:36:27.570 dark spots and the unaltered clear spots represented 00:36:27.570 --> 00:36:30.110 the digital ones and zeros, the pits and lands, 00:36:30.389 --> 00:36:33.150 that a reading laser would later interpret. Right. 00:36:33.380 --> 00:36:35.739 But because the dye was organic, it was fundamentally 00:36:35.739 --> 00:36:38.719 unstable. The molecular bonds within the dye 00:36:38.719 --> 00:36:41.099 were highly susceptible to environmental degradation. 00:36:42.000 --> 00:36:43.800 Ultraviolet light from the sun would literally 00:36:43.800 --> 00:36:45.679 break the double bonds in the dye molecules, 00:36:46.019 --> 00:36:48.460 causing the darkened spots to fade until the 00:36:48.460 --> 00:36:50.539 laser could no longer distinguish a 1 from a 00:36:50.539 --> 00:36:53.849 0. High humidity would cause the layers to delaminate. 00:36:54.349 --> 00:36:56.730 Furthermore, if the laser in the disk drive was 00:36:56.730 --> 00:36:58.909 slightly weak, it wouldn't heat the dye sufficiently, 00:36:59.190 --> 00:37:01.809 creating a shallow burn that degraded even faster. 00:37:02.650 --> 00:37:04.989 Spindles of those early 2000s disks that appear 00:37:04.989 --> 00:37:07.610 perfectly pristine to the naked eye today will 00:37:07.610 --> 00:37:10.210 almost universally return massive read errors 00:37:10.210 --> 00:37:12.409 on their inner tracks because the chemical dye 00:37:12.409 --> 00:37:15.610 has simply aged out of existence. So organic 00:37:15.610 --> 00:37:18.789 chemistry was the vulnerability. Enter the technological 00:37:18.789 --> 00:37:23.110 hero of this deep dive, the M disk. What exactly 00:37:23.110 --> 00:37:25.050 is an M disk and how does it solve the chemistry 00:37:25.050 --> 00:37:28.289 problem? MDISC, which stands for Millennial Disk, 00:37:28.510 --> 00:37:31.289 was a proprietary technology born out of extensive 00:37:31.289 --> 00:37:33.869 materials science research at Brigham Young University 00:37:33.869 --> 00:37:37.469 and commercialized around 2009. The revolutionary 00:37:37.469 --> 00:37:39.809 leap of the

MDISC was the complete elimination 00:37:39.809 --> 00:37:43.050 of the unstable organic dye layer. Instead, the 00:37:43.050 --> 00:37:45.469 MDISC utilizes a recording layer composed of 00:37:45.469 --> 00:37:48.809 an inorganic, glassy carbon material. Glassy 00:37:48.809 --> 00:37:51.949 carbon. So instead of a chemical paint, it is 00:37:51.949 --> 00:37:54.050 essentially a micro -thin layer of synthetic 00:37:54.050 --> 00:37:57.869 rock. Functionally, yes. It is an inorganic compound 00:37:57.869 --> 00:38:00.750 that is highly inert to oxidation, immune to 00:38:00.750 --> 00:38:03.670 ultraviolet degradation, and possesses an incredibly 00:38:03.670 --> 00:38:06.210 high melting point. When an M -disc is placed 00:38:06.210 --> 00:38:08.329 in a drive to be written, the recording laser 00:38:08.329 --> 00:38:10.949 has to fire with significantly higher power than 00:38:10.949 --> 00:38:13.309 it would for a die disc. It doesn't just induce 00:38:13.309 --> 00:38:15.769 a chemical color change. The laser physically 00:38:15.769 --> 00:38:18.869 melts localized pits into that hard, rock -like 00:38:18.869 --> 00:38:21.909 carbon layer. The data is written via a permanent 00:38:21.909 --> 00:38:24.449 physical phase change in an inorganic material. 00:38:25.010 --> 00:38:27.130 That is fascinating. Yeah. You're essentially 00:38:27.130 --> 00:38:30.090 engraving data into stone at a microscopic level. 00:38:30.349 --> 00:38:33.489 And this isn't just theoretical marketing. There 00:38:33.489 --> 00:38:36.130 is a legendary independent test detailed in the 00:38:36.130 --> 00:38:38.309 source material that conclusively proves just 00:38:38.309 --> 00:38:40.809 how resilient this inorganic layer is. Let's 00:38:40.809 --> 00:38:43.210 talk about the China Lake Test, because the parameters 00:38:43.210 --> 00:38:45.429 of this experiment sound like a military torture 00:38:45.429 --> 00:38:47.889 chamber for electronics. The China Lake Test 00:38:47.889 --> 00:38:50.170 is the foundational proof of concept for the 00:38:50.170 --> 00:38:53.079 MDISC. The United States Naval Air Warfare Center 00:38:53.079 --> 00:38:55.400 Weapons Division, located at China Lake, California, 00:38:55.619 --> 00:38:58.159 routinely conducts extreme environmental testing 00:38:58.159 --> 00:39:00.940 for military hardware. They decided to evaluate 00:39:00.940 --> 00:39:04.440 the archival integrity of the early M -Disc DVDs 00:39:04.440 --> 00:39:07.019 against the best, highest quality standard organic 00:39:07.019 --> 00:39:10.300 die discs on the market using premium brands 00:39:10.300 --> 00:39:12.760 like Verbatim, Mitsubishi and Delcon devices. 00:39:13.139 --> 00:39:16.389 OK, so top tier consumer stuff. Right. They placed 00:39:16.389 --> 00:39:18.590 all the disks into environmental testing chambers 00:39:18.590 --> 00:39:21.750 designed to simulate severe accelerated aging. 00:39:21.969 --> 00:39:24.570 The disks were subjected to grueling temperature 00:39:24.570 --> 00:39:28.090 cycles reaching 85 degrees Celsius, 185 degrees 00:39:28.090 --> 00:39:31.389 Fahrenheit, combined with 85 % relative humidity, 00:39:31.650 --> 00:39:34.389 while simultaneously being bombarded with full 00:39:34.389 --> 00:39:36.829 -spectrum light arrays designed to mimic intense 00:39:36.829 --> 00:39:39.389 direct solar radiation. They basically threw 00:39:39.389 --> 00:39:42.690 absolute hell at these disks to see which one 00:39:42.690 --> 00:39:45.829 would break first. The results were stark and 00:39:45.829 --> 00:39:49.050 definitive. Every single standard organic dye 00:39:49.050 --> 00:39:52.409 disk suffered catastrophic data loss. The environmental 00:39:52.409 --> 00:39:54.969 stress caused the chemical dyes to degrade and 00:39:54.969 --> 00:39:57.750 the layers to physically delaminate. The M disks, 00:39:57.869 --> 00:40:00.409 however, survived the entire testing protocol 00:40:00.409 --> 00:40:03.469 without any measurable data degradation. The 00:40:03.469 --> 00:40:05.469 Navy's report concluded that the M disk was the 00:40:05.469 --> 00:40:07.710 only format capable of surviving the rigorous 00:40:07.710 --> 00:40:10.670 environmental conditions. That test established 00:40:10.670 --> 00:40:12.989 the MDISC as the gold standard for institutional 00:40:12.989 --> 00:40:16.250 and personal archiving. OK, the chemistry is 00:40:16.250 --> 00:40:20.510 brilliant and the military test is highly convincing. 00:40:20.710 --> 00:40:23.630 But I am going to push back here because I'm 00:40:23.630 --> 00:40:25.510 looking at the corporate history in our source 00:40:25.510 --> 00:40:29.260 notes. It clearly states that Millenniata, the 00:40:29.260 --> 00:40:31.260 company that originally invented and patented 00:40:31.260 --> 00:40:34.119 the MDISC technology, went bankrupt and dissolved 00:40:34.119 --> 00:40:38.079 in December 2016. Okay, how can we sit here and 00:40:38.079 --> 00:40:40.280 confidently advise the listener to entrust their 00:40:40.280 --> 00:40:43.619 irreplaceable family legacy to a format created 00:40:43.619 --> 00:40:46.769 by a defunct company? Doesn't a corporate bankruptcy 00:40:46.769 --> 00:40:49.449 trigger the exact administrative clock warning 00:40:49.449 --> 00:40:51.369 we spent the first 20 minutes of this deep dive 00:40:51.369 --> 00:40:55.409 criticizing? It is a vital question, and it is 00:40:55.409 --> 00:40:57.389 a nuance that trips up many people looking into 00:40:57.389 --> 00:41:00.110 archiving. But the dissolution of Millennata 00:41:00.110 --> 00:41:03.170 actually represents a massive, necessary victory 00:41:03.170 --> 00:41:06.170 for the MDISC format. It demonstrates what archivists 00:41:06.170 --> 00:41:08.949 consider the correct order of operations for 00:41:08.949 --> 00:41:11.530 a sustainable medium. How does the creator going 00:41:11.530 --> 00:41:14.070 bankrupt represent a victory for the product? 00:41:14.389 -->

00:41:17.409 You have to separate the corporate entity from 00:41:17.409 --> 00:41:20.670 the open technological standard. Millenniatas 00:41:20.670 --> 00:41:22.590 struggled financially not because the M -Disk 00:41:22.590 --> 00:41:25.030 technology was flawed, but because the broader 00:41:25.030 --> 00:41:27.389 consumer hardware market experienced a massive 00:41:27.389 --> 00:41:30.710 shift. Around 2015, manufacturers like Apple 00:41:30.710 --> 00:41:33.150 and Dell completely stopped including built -in 00:41:33.150 --> 00:41:35.829 optical drives in their laptops in favor of making 00:41:35.829 --> 00:41:38.630 devices thinner and relying on the cloud. The 00:41:38.630 --> 00:41:41.429 overall volume of optical disks sold plummeted. 00:41:41.489 --> 00:41:43.730 The startup couldn't survive the hardware transition. 00:41:44.250 --> 00:41:46.989 Oh, that makes sense. The market changed. However, 00:41:47.170 --> 00:41:49.730 the medium itself, the M -Disc standard, was 00:41:49.730 --> 00:41:52.210 so robust that it survived the death of its creator. 00:41:52.469 --> 00:41:54.670 Before millennia unfolded, they successfully 00:41:54.670 --> 00:41:57.530 licensed the manufacturing technology to massive, 00:41:57.650 --> 00:42:00.429 diversified global conglomerates, most notably 00:42:00.429 --> 00:42:02.969 Verbatim, which operates under the umbrella of 00:42:02.969 --> 00:42:05.989 the Mitsubishi Chemical Group. Mitsubishi has 00:42:05.989 --> 00:42:07.949 the deep pockets and manufacturing infrastructure 00:42:07.949 --> 00:42:10.650 to keep producing the discs indefinitely, regardless 00:42:10.650 --> 00:42:13.590 of the fate of the original Utah startup. I see. 00:42:13.900 --> 00:42:16.920 The intellectual property outlived the startup, 00:42:17.119 --> 00:42:20.119 and manufacturing passed to a global titan. But 00:42:20.119 --> 00:42:22.800 what about the hardware to read it? If the company 00:42:22.800 --> 00:42:25.440 is dead, how do we know the software or the drives 00:42:25.440 --> 00:42:28.320 will even exist in 20 years? This is the quiet, 00:42:28.420 --> 00:42:30.420 ultimate triumph of the M -Disk Blu -ray standard. 00:42:31.179 --> 00:42:34.150 Absolute read compatibility. To read a modern 00:42:34.150 --> 00:42:36.230 M -Disc Blu -ray, you do not need a proprietary 00:42:36.230 --> 00:42:39.150 specialized M -Disc reader. You do not need to 00:42:39.150 --> 00:42:41.849 download legacy driver software from a defunct 00:42:41.849 --> 00:42:45.250 2016 website. You do not need a cloud API key, 00:42:45.389 --> 00:42:48.070 and you are not beholden to any corporate terms 00:42:48.070 --> 00:42:51.030 of service. An M -Disc Blu -ray is designed to 00:42:51.030 --> 00:42:53.389 meet the exact optical specifications of the 00:42:53.389 --> 00:42:55.690 standard Blu -ray format. It mounts seamlessly 00:42:55.690 --> 00:42:58.989 in any cheap mass market $30 external Blu -ray 00:42:58.989 --> 00:43:01.469 drive you can buy off the shelf today using the 00:43:01.469 --> 00:43:04.510 standard 405 nanometer blue laser. It mounts 00:43:04.510 --> 00:43:06.909 natively in Windows, Mac OS, and Linux without 00:43:06.909 --> 00:43:09.539 requiring third -party software. That is the 00:43:09.539 --> 00:43:12.280 ultimate relief. We avoid the 1970s tape deck 00:43:12.280 --> 00:43:15.269 problem entirely. We have a universal... open 00:43:15.269 --> 00:43:17.949 standard. If I pull an M disk off a dusty shelf 00:43:17.949 --> 00:43:20.670 in the year 2045, I can simply plug whatever 00:43:20.670 --> 00:43:23.150 generic optical drive exists at that time into 00:43:23.150 --> 00:43:25.650 a computer, and the standard file system will 00:43:25.650 --> 00:43:28.030 mount the data instantly. The data is completely 00:43:28.030 --> 00:43:31.690 sovereign. So we have established the perfect 00:43:31.690 --> 00:43:35.150 inorganic disk. The chemistry is sound, the capacity 00:43:35.150 --> 00:43:37.510 handles our camera rolls, and the standard is 00:43:37.510 --> 00:43:40.230 immune to corporate death. But building a true 00:43:40.230 --> 00:43:42.909 archive is not just about logging onto Amazon 00:43:42.909 --> 00:43:45.909 and buying a spindle of blank disks. It is about 00:43:45.909 --> 00:43:49.409 the execution. The physical act of archiving 00:43:49.409 --> 00:43:52.849 requires a specific protocol. Let's get incredibly 00:43:52.849 --> 00:43:55.630 practical. How do you actually build this archive 00:43:55.630 --> 00:43:58.389 this weekend? What is the architect's practice? 00:43:58.769 --> 00:44:01.809 The practice of archiving requires a disciplined 00:44:01.809 --> 00:44:04.989 sequence. It is an intentional, deliberate process 00:44:04.989 --> 00:44:07.670 that is slightly dull, which is exactly why it 00:44:07.670 --> 00:44:10.329 is effective. The methodology breaks down into 00:44:10.329 --> 00:44:14.210 four essential steps. Freeze, hash, burn, and 00:44:14.210 --> 00:44:17.289 verify. Okay, walk us through them. First, you 00:44:17.289 --> 00:44:19.889 must freeze the folder. You gather the specific 00:44:19.889 --> 00:44:23.429 photographs, the finalized tax documents, the 00:44:23.429 --> 00:44:26.349 exported video files you intend to archive, and 00:44:26.349 --> 00:44:29.110 you place them into a single, dedicated directory. 00:44:29.449 --> 00:44:32.829 And then crucially, you stop modifying them. 00:44:32.929 --> 00:44:35.510 You do not open them to make a quick crop. You 00:44:35.510 --> 00:44:38.909 do not rename them. the data state must be completely 00:44:38.909 --> 00:44:41.409 frozen. Because if you change a file after the 00:44:41.409 --> 00:44:44.010 next step, the entire verification process breaks. 00:44:44.230 --> 00:44:48.309 So what is the next step? Step two is creating 00:44:48.309 --> 00:44:52.349 a manifest of hashes. A digital hash is a fundamental 00:44:52.349 --> 00:44:55.750 concept in cryptography and data integrity. Using

00:44:55.750 --> 00:44:59.110 a standard algorithm like SHA -256, you use a 00:44:59.110 --> 00:45:02.449 simple software utility to scan every file in 00:45:02.449 --> 00:45:06.320 your frozen folder. The algorithm processes the 00:45:06.320 --> 00:45:09.079 raw binary data of the file and outputs a unique 00:45:09.079 --> 00:45:11.219 fixed -length string of characters. This is the 00:45:11.219 --> 00:45:14.420 file's mathematical fingerprint. And the architecture 00:45:14.420 --> 00:45:16.559 of a hash is incredibly sensitive, right? Like, 00:45:16.619 --> 00:45:19.380 if I take a high -resolution photograph and change 00:45:19.380 --> 00:45:23.579 exactly one single pixel from dark blue to slightly 00:45:23.579 --> 00:45:26.579 darker blue, the resulting hash string will be 00:45:26.579 --> 00:45:29.619 completely, radically different from the original 00:45:29.619 --> 00:45:32.909 hash. That is called the avalanche effect. Even 00:45:32.909 --> 00:45:35.409 a single flipped bit entirely alters the hash. 00:45:35.570 --> 00:45:37.949 By generating a text file containing the hashes 00:45:37.949 --> 00:45:40.469 of every photo you are about to burn, you create 00:45:40.469 --> 00:45:43.409 an infallible ledger of the data's exact state 00:45:43.409 --> 00:45:46.710 at the moment of archiving. Brilliant. Step three 00:45:46.710 --> 00:45:49.590 is the burn itself. You load your blank M disk 00:45:49.590 --> 00:45:52.369 and initiate the burn software. The critical 00:45:52.369 --> 00:45:55.449 rule here is to prioritize accuracy over speed. 00:45:56.139 --> 00:45:59.119 Modern optical drives boast incredibly high maximum 00:45:59.119 --> 00:46:02.820 burn speeds, 16x or 24x, which are essentially 00:46:02.820 --> 00:46:06.280 party tricks. Riding to that glassy carbon layer 00:46:06.280 --> 00:46:10.139 requires sustained, deep laser power. If your 00:46:10.139 --> 00:46:12.519 software offers the option, you manually restrict 00:46:12.519 --> 00:46:14.679 the burn speed to match the baseline rating of 00:46:14.679 --> 00:46:18.599 the disk, usually 4x or 6x. A slow, steady burn 00:46:18.599 --> 00:46:21.599 using constant linear velocity ensures the pits 00:46:21.599 --> 00:46:24.880 are melted deeply and cleanly. And then comes 00:46:24.880 --> 00:46:27.260 step four, which is arguably the most important 00:46:27.260 --> 00:46:30.179 rule of this entire deep dive. Verification. 00:46:30.920 --> 00:46:33.619 Let me bring up an analogy. Going through the 00:46:33.619 --> 00:46:35.900 trouble of buying an M -desk, burning your files 00:46:35.900 --> 00:46:37.900 to it, and immediately tossing it into a desk 00:46:37.900 --> 00:46:40.440 drawer without verifying the integrity of the 00:46:40.440 --> 00:46:43.400 burn is exactly like packing a parachute with 00:46:43.400 --> 00:46:45.800 a blindfold on, shoving it into a closet, and 00:46:45.800 --> 00:46:47.780 just confidently assuming it will successfully 00:46:47.780 --> 00:46:49.960 deploy when you jump out of an airplane ten years 00:46:49.960 --> 00:46:53.400 later. You have absolutely no idea if the burn 00:46:53.400 --> 00:46:56.800 process actually worked until you test it. The 00:46:56.800 --> 00:46:59.940 parachute analogy is perfect. A silent error 00:46:59.940 --> 00:47:01.679 could have occurred during the write process, 00:47:01.980 --> 00:47:04.619 a speck of dust, a micro fluctuation in laser 00:47:04.619 --> 00:47:08.440 power, a buffer underrun. To verify, you simply 00:47:08.440 --> 00:47:11.019 instruct your software to read the freshly burned 00:47:11.019 --> 00:47:15.340 physical disk and recalculate the SHA -256 hashes 00:47:15.340 --> 00:47:18.119 of the files directly from the optical media. 00:47:18.610 --> 00:47:21.110 The software then compares those new hashes against 00:47:21.110 --> 00:47:23.389 the original manifest you created in step two. 00:47:23.610 --> 00:47:27.010 If every single hash matches perfectly, you haven't 00:47:27.010 --> 00:47:29.989 just copied data. You have mathematically proven, 00:47:30.170 --> 00:47:33.829 down to the exact binary digit, that your archive 00:47:33.829 --> 00:47:37.090 is a perfect clone of your original files. If 00:47:37.090 --> 00:47:39.050 the hashes don't match, you throw the disk in 00:47:39.050 --> 00:47:41.510 the trash and try again. Blank disks are cheap. 00:47:42.010 --> 00:47:45.309 Corrupted memories are forever. Now, to ensure 00:47:45.309 --> 00:47:47.510 that the burn process goes perfectly on the first 00:47:47.510 --> 00:47:49.889 try, We need to talk about the physical hardware 00:47:49.889 --> 00:47:52.820 doing the burning. Because the source material 00:47:52.820 --> 00:47:55.159 provides very specific drive recommendations 00:47:55.159 --> 00:47:58.059 to avoid a mechanical issue known as starving 00:47:58.059 --> 00:48:01.349 the laser. What does it mean to starve a laser 00:48:01.349 --> 00:48:03.829 during a burn? This comes back to the physical 00:48:03.829 --> 00:48:07.400 demands of the M -Disc. Melting pits into inorganic 00:48:07.400 --> 00:48:10.219 glassy carbon requires significantly more thermal 00:48:10.219 --> 00:48:13.519 energy than tinting an organic dye. The laser 00:48:13.519 --> 00:48:15.860 diode in the drive must maintain a very high, 00:48:15.980 --> 00:48:18.139 entirely uninterrupted power draw throughout 00:48:18.139 --> 00:48:20.780 the entire burn process. This is particularly 00:48:20.780 --> 00:48:23.440 crucial if you are writing to high -capacity 00:48:23.440 --> 00:48:27.099 BDXL disks. A standard Blu -ray holds 25 gigabytes, 00:48:27.340 --> 00:48:30.820 but a triple -layer BDXL disk holds 100 gigabytes. 00:48:31.239 --> 00:48:34.199 Burning 100 gigabytes at a slow, reliable speed 00:48:34.199 --> 00:48:37.079 can take over an hour of continuous high intensity 00:48:37.079 --> 00:48:39.619 laser firing. And this is where the power source 00:48:39.619 --> 00:48:42.559 becomes the bottleneck. Exactly. Many

modern 00:48:42.559 --> 00:48:44.760 external optical drives are bus powered, meaning 00:48:44.760 --> 00:48:47.280 they draw their electrical current entirely through 00:48:47.280 --> 00:48:50.360 the USB cable connected to your laptop. A standard 00:48:50.360 --> 00:48:53.659 USB port has strict power delivery limits. If 00:48:53.659 --> 00:48:56.420 you are halfway through a 100 gigabyte burn and 00:48:56.420 --> 00:48:58.699 your laptop screen decides to go to sleep or 00:48:58.699 --> 00:49:01.000 the operating system temporarily diverts power 00:49:01.000 --> 00:49:03.579 on the USB bus to prioritize another component, 00:49:04.289 --> 00:49:06.329 The voltage supplied to the optical drive dips 00:49:06.329 --> 00:49:08.949 for a fraction of a second. The laser starves. 00:49:08.949 --> 00:49:11.849 The thermal energy drops. The pit isn't melted 00:49:11.849 --> 00:49:15.389 deeply enough. The burn silently fails, and you 00:49:15.389 --> 00:49:19.829 have just ruined a $30 blank BDXL disk. So how 00:49:19.829 --> 00:49:22.429 do we mitigate that risk? What specific hardware 00:49:22.429 --> 00:49:24.550 should the listener purchase to build their architecture? 00:49:24.980 --> 00:49:26.880 The recommendations are split into two tiers 00:49:26.880 --> 00:49:29.360 based on your capacity needs. The entry -level 00:49:29.360 --> 00:49:31.260 recommendation is for users who are primarily 00:49:31.260 --> 00:49:33.480 archiving documents and a moderate amount of 00:49:33.480 --> 00:49:37.159 photos onto standard 25GB M .Discs. For this, 00:49:37.320 --> 00:49:40.159 the Buffalo 6X portable Blu -ray drive is highly 00:49:40.159 --> 00:49:42.820 reliable. It explicitly states firmware support 00:49:42.820 --> 00:49:45.460 for the M .Disc standard. However, because it 00:49:45.460 --> 00:49:47.559 is a bus -powered drive, you must follow strict 00:49:47.559 --> 00:49:50.280 operational hygiene. You must plug the drive 00:49:50.280 --> 00:49:52.900 directly into a primary USB port on the computer 00:49:52.900 --> 00:49:56.420 chassis, never into an unpowered USB hub, a monitor 00:49:56.420 --> 00:49:59.239 pass -through, or a cheap dongle. And crucially, 00:49:59.340 --> 00:50:01.380 you must configure your operating system settings 00:50:01.380 --> 00:50:03.559 to prevent the computer from going to sleep or 00:50:03.559 --> 00:50:05.420 spinning down the hard drives while the burn 00:50:05.420 --> 00:50:08.119 is active. You essentially have to babysit the 00:50:08.119 --> 00:50:10.340 laptop to ensure it keeps feeding power to the 00:50:10.340 --> 00:50:13.789 USB port. But what about the Pro tier? For the 00:50:13.789 --> 00:50:16.570 person shooting 4K video, who needs to utilize 00:50:16.570 --> 00:50:19.949 the massive 100 gigabyte triple layer M disks? 00:50:20.190 --> 00:50:23.349 For massive hour -long burns, you want to eliminate 00:50:23.349 --> 00:50:26.409 the USB power variable entirely. The top line 00:50:26.409 --> 00:50:29.070 recommendation is a desktop class drive, specifically 00:50:29.070 --> 00:50:33.889 the Asus BW16D1X -U. The model number is obtuse, 00:50:33.909 --> 00:50:36.440 but the engineering is what matters. The Asus 00:50:36.440 --> 00:50:39.000 drive does not rely on your laptop's USB port 00:50:39.000 --> 00:50:41.480 for power. It features its own dedicated power 00:50:41.480 --> 00:50:43.880 brick that plugs directly into an AC wall outlet, 00:50:44.159 --> 00:50:47.320 pulling a highly stable 12 volts at 3 amps. This 00:50:47.320 --> 00:50:49.380 means the spindle motor turning the heavy 100 00:50:49.380 --> 00:50:52.500 gigabyte disk and the 405 nanometer laser melting 00:50:52.500 --> 00:50:55.539 the carbon layer have access to massive uninterrupted 00:50:55.539 --> 00:50:57.940 current directly from the wall. The laser never 00:50:57.940 --> 00:51:00.320 begs the laptop for power. It delivers incredibly 00:51:00.320 --> 00:51:04.099 stable, deep burns. So, we have the correct high 00:51:04.099 --> 00:51:06.940 -power Asus drive. We've executed our slow burn 00:51:06.940 --> 00:51:10.980 and we verified our hashes. The data is mathematically 00:51:10.980 --> 00:51:13.679 perfect and permanently etched into synthetic 00:51:13.679 --> 00:51:18.019 rock. Now, what are the physical storage rules? 00:51:18.320 --> 00:51:20.800 Because the physical treatment of the media dictates 00:51:20.800 --> 00:51:24.340 its longevity. I remember back in the early 2000s, 00:51:24.360 --> 00:51:26.800 people would buy those sticky printable paper 00:51:26.800 --> 00:51:29.219 labels and stick them onto the top of their CDRs 00:51:29.219 --> 00:51:32.239 to make them look professional. Is that acceptable 00:51:32.239 --> 00:51:35.260 for an archive? Under no circumstances should 00:51:35.260 --> 00:51:38.840 you ever apply an adhesive paper label to an 00:51:38.840 --> 00:51:41.519 archival optical disc. At the high rotational 00:51:41.519 --> 00:51:44.300 speeds required to read a Blu -ray disc, a paper 00:51:44.300 --> 00:51:46.460 label that is even a fraction of a millimeter 00:51:46.460 --> 00:51:48.980 off -center will introduce a severe physical 00:51:48.980 --> 00:51:51.559 imbalance, causing the drive to vibrate violently, 00:51:51.820 --> 00:51:54.699 which can induce read errors or physically shatter 00:51:54.699 --> 00:51:58.119 the disc inside the drive. Furthermore, the chemical 00:51:58.119 --> 00:52:00.800 adhesives used on the labels can eventually off 00:52:00.800 --> 00:52:02.960 -gas and degrade the protective lacquer layer 00:52:02.960 --> 00:52:05.940 on the top of the disc. Write on the inner plastic 00:52:05.940 --> 00:52:08.579 hub with a specialized soft -tip marker if you 00:52:08.579 --> 00:52:11.579 must, but ideally, keep the disc face pristine. 00:52:12.039 --> 00:52:15.000 And how should they be housed? Store the burned 00:52:15.000 --> 00:52:17.820 M discs in standard, rigid plastic jewel cases. 00:52:18.139 --> 00:52:21.119 Never

use those cheap, thin paper sleeves or 00:52:21.119 --> 00:52:23.960 flexible plastic binders. Every time you slide 00:52:23.960 --> 00:52:26.340 a disc in and out of a paper sleeve, microscopic 00:52:26.340 --> 00:52:28.960 dust particles act as an abrasive, eventually 00:52:28.960 --> 00:52:32.000 scratching the polycarbonate data surface. Store 00:52:32.000 --> 00:52:34.239 the jewel cases upright, exactly like books on 00:52:34.239 --> 00:52:37.139 a library shelf. Do not stack them flat in massive 00:52:37.139 --> 00:52:39.179 towers as the weight can cause the bottom discs 00:52:39.179 --> 00:52:42.840 to warp over decades. Keep them in a cool, dark, 00:52:42.880 --> 00:52:45.679 and dry environment. An interior closet in a 00:52:45.679 --> 00:52:48.510 climate -controlled living space is ideal. Do 00:52:48.510 --> 00:52:50.730 not store them in an uninsulated attic where 00:52:50.730 --> 00:52:53.130 wild temperature swings will physically expand 00:52:53.130 --> 00:52:55.730 and contract the polycarbonate layers, inducing 00:52:55.730 --> 00:52:58.610 stress fractures. And certainly do not store 00:52:58.610 --> 00:53:00.329 them in a basement where a flooded water heater 00:53:00.329 --> 00:53:02.789 could submerge them. And the labeling on the 00:53:02.789 --> 00:53:06.250 case is vital. As the old archivist saying goes, 00:53:06.409 --> 00:53:09.170 a perfectly preserved disk that nobody can identify 00:53:09.170 --> 00:53:12.769 in the year 2045 is only slightly more useful 00:53:12.769 --> 00:53:15.699 than a disk nobody can read. Print out a paper 00:53:15.699 --> 00:53:18.119 insert for the jewel case, detailing exactly 00:53:18.119 --> 00:53:20.460 what is on the disk, the date it was burned, 00:53:20.599 --> 00:53:23.199 and what specific hashing algorithm you used 00:53:23.199 --> 00:53:26.099 to verify it. Which brings us to the ultimate 00:53:26.099 --> 00:53:29.320 architectural rule of thumb for this entire practice. 00:53:29.559 --> 00:53:32.039 The rule that guarantees survival against physical 00:53:32.039 --> 00:53:35.380 reality. Right. It is a variation of the classic 00:53:35.380 --> 00:53:38.780 3 -2 -1 backup strategy, adapted for physical 00:53:38.780 --> 00:53:43.280 media. The rule is this. One single disk is merely 00:53:43.280 --> 00:53:47.059 a hope. Two identically burned and verified disks 00:53:47.059 --> 00:53:49.460 stored in two different rooms of your house is 00:53:49.460 --> 00:53:52.820 a reliable method. Three disks with the third 00:53:52.820 --> 00:53:56.619 stored entirely off -site, perhaps in a bank 00:53:56.619 --> 00:53:59.340 safety deposit box or simply on a shelf at a 00:53:59.340 --> 00:54:01.599 trusted friend or family member's house in a 00:54:01.599 --> 00:54:04.260 different city, is the standard you use for the 00:54:04.260 --> 00:54:07.539 human records you can absolutely never afford 00:54:07.539 --> 00:54:10.539 to lose. A localized fire or flood can destroy 00:54:10.539 --> 00:54:14.119 two disks in one house. It is... statistically 00:54:14.119 --> 00:54:17.199 impossible for two separate natural disasters 00:54:17.199 --> 00:54:20.619 to simultaneously destroy the primary home and 00:54:20.619 --> 00:54:23.039 the off -site location hundreds of miles away. 00:54:23.360 --> 00:54:26.460 We have covered immense ground today. We have 00:54:26.460 --> 00:54:28.920 examined the silent, relentless threat of the 00:54:28.920 --> 00:54:31.679 administrative clock and the physical decay of 00:54:31.679 --> 00:54:34.630 magnetic media. We have shattered the illusion 00:54:34.630 --> 00:54:37.610 of data massiveness, reducing decades of human 00:54:37.610 --> 00:54:40.030 memory down to the scale of a single physical 00:54:40.030 --> 00:54:44.000 shoebox. We have explored the glassy carbon chemistry 00:54:44.000 --> 00:54:46.559 of the M disk that solves the degradation problem. 00:54:47.059 --> 00:54:50.300 And we have laid out the precise hardware, the 00:54:50.300 --> 00:54:52.679 cryptographic hashing, and the physical practice 00:54:52.679 --> 00:54:55.929 required to execute this successfully. Let's 00:54:55.929 --> 00:54:58.090 bring this all home and summarize the core practical 00:54:58.090 --> 00:55:01.510 value for you, the listener. Against a decade 00:55:01.510 --> 00:55:03.909 of paying monthly cloud rent to a tech conglomerate, 00:55:04.219 --> 00:55:07.039 Against the constant low -level anxiety of getting 00:55:07.039 --> 00:55:09.400 locked out of an automated account or having 00:55:09.400 --> 00:55:12.659 your data held hostage by egress fees? A stack 00:55:12.659 --> 00:55:15.539 of verified, verbatim MDISCs and a dedicated 00:55:15.539 --> 00:55:18.480 ASUS optical drive represents a financial rounding 00:55:18.480 --> 00:55:20.699 error. We are talking about an investment of 00:55:20.699 --> 00:55:24.360 less than $150. But what that small investment 00:55:24.360 --> 00:55:27.880 buys you is functionally priceless. It grants 00:55:27.880 --> 00:55:31.079 you true, API -free, terms -of -service -free, 00:55:31.139 --> 00:55:34.019 absolute custody of your life's irreplaceable 00:55:34.019 --> 00:55:37.139 memories. No tech billionaire can unilaterally 00:55:37.139 --> 00:55:39.719 change the terms of a physical M disk sitting 00:55:39.719 --> 00:55:42.539 quietly on your bookshelf. No server migration 00:55:42.539 --> 00:55:46.420 can erase it. It is entirely sovereign. It is 00:55:46.420 --> 00:55:48.739 the purest form of digital sovereignty available 00:55:48.739 --> 00:55:52.260 to a consumer today. But as we conclude this 00:55:52.260 --> 00:55:54.840 analysis, I want to leave everyone with a broader, 00:55:54.980 --> 00:55:58.420 deeply philosophical thought to mull over. It 00:55:58.420 --> 00:56:00.260 builds on everything we've discussed today regarding 00:56:00.260 --> 00:56:02.469 the fragility of the web. the great divergence, 00:56:02.730 --> 00:56:06.489 and the illusion of permanence.

Historians and 00:56:06.489 --> 00:56:08.550 data archivists recognize that we are currently 00:56:08.550 --> 00:56:11.909 living through a profound paradox that is increasingly 00:56:11.909 --> 00:56:15.070 being referred to as the digital dark age. A 00:56:15.070 --> 00:56:18.389 dark age? How is that possible when we just established 00:56:18.389 --> 00:56:22.010 that human civilization is producing 600 exabytes 00:56:22.010 --> 00:56:25.070 of high -fidelity data every single day? We are 00:56:25.070 --> 00:56:28.329 drowning in information. We are drowning in information, 00:56:28.570 --> 00:56:31.650 but we are starving for permanence. We produce 00:56:31.650 --> 00:56:35.670 exponentially more raw data daily than any previous 00:56:35.670 --> 00:56:38.369 civilization in human history. Yet precisely 00:56:38.369 --> 00:56:41.030 because of the ephemeral nature of magnetic charges 00:56:41.030 --> 00:56:44.510 on SSDs, the seizing fluid dynamic bearings of 00:56:44.510 --> 00:56:47.289 hard drives, and the incredibly fragile rental 00:56:47.289 --> 00:56:49.829 agreements of the cloud, we actually run the 00:56:49.829 --> 00:56:52.489 very real risk of leaving behind fewer permanent 00:56:52.489 --> 00:56:55.309 readable records than the ancient Sumerians did. 00:56:55.530 --> 00:56:59.460 That is a staggering. realization. The Sumerians 00:56:59.460 --> 00:57:02.420 inscribed cuneiform onto clay tablets. Whether 00:57:02.420 --> 00:57:04.440 they intentionally baked those tablets in kilns 00:57:04.440 --> 00:57:06.780 or whether the tablets were accidentally fired 00:57:06.780 --> 00:57:09.079 when their cities were burned by invaders, that 00:57:09.079 --> 00:57:11.619 inorganic clay survived in the earth for 5 ,000 00:57:11.619 --> 00:57:14.699 years. We can read their grain receipts and their 00:57:14.699 --> 00:57:18.179 poetry today. Exactly. A fired clay tablet is 00:57:18.179 --> 00:57:21.280 essentially a primitive macroscopic version of 00:57:21.280 --> 00:57:23.699 the glassy carbon layer of an M -disc. It is 00:57:23.699 --> 00:57:26.320 a physical phase change in an inorganic medium. 00:57:26.880 --> 00:57:29.300 So the provocative question we must ask ourselves 00:57:29.300 --> 00:57:32.579 is this. If a future digital archaeologist, or 00:57:32.579 --> 00:57:35.159 on a much more personal and realistic timeline, 00:57:35.400 --> 00:57:37.639 simply your own great -grandchildren 50 years 00:57:37.639 --> 00:57:40.000 from now, decides to dig through the remnants 00:57:40.000 --> 00:57:42.360 of our current era to understand who you were, 00:57:42.579 --> 00:57:45.320 what exactly will they find? Will they find your 00:57:45.320 --> 00:57:47.780 carefully curated, mathematically verified M 00:57:47.780 --> 00:57:50.340 -discs, resting safely in a labeled jewel case 00:57:50.340 --> 00:57:52.320 on a bookshelf, ready to mount in a standard 00:57:52.320 --> 00:57:55.289 drive? Or will they simply uncover the rusted, 00:57:55.409 --> 00:57:58.070 completely unreadable platters of an old mechanical 00:57:58.070 --> 00:58:00.309 hard drive sitting at the bottom of a flooded 00:58:00.309 --> 00:58:03.449 desk drawer, alongside a dead web link to a cloud 00:58:03.449 --> 00:58:05.409 account that a corporation automatically deleted 00:58:05.409 --> 00:58:08.510 decades ago? It is completely up to you to leave 00:58:08.510 --> 00:58:11.329 a deliberate fossil record. You do not have to 00:58:11.329 --> 00:58:13.610 save the noise. You don't need to archive the 00:58:13.610 --> 00:58:15.750 cached application data or the downloaded movies. 00:58:16.269 --> 00:58:18.809 But the memories, the photographs, the written 00:58:18.809 --> 00:58:21.610 documents, the audio recordings that prove you 00:58:21.610 --> 00:58:24.159 were here. and that you lived a beautiful, complex 00:58:24.159 --> 00:58:26.940 life. Do not leave them sitting on death row 00:58:26.940 --> 00:58:29.519 in a corporate server farm. Take the afternoon. 00:58:30.000 --> 00:58:33.099 Freeze the folder. Generate the hashes. Burn 00:58:33.099 --> 00:58:36.760 the inorganic copy. Verify the math. Put it on 00:58:36.760 --> 00:58:39.860 a physical shelf. The cloud can comfortably hold 00:58:39.860 --> 00:58:41.980 your working set while you need immediate access 00:58:41.980 --> 00:58:44.820 to it on your phone, but the shelf holds the 00:58:44.820 --> 00:58:47.239 incontrovertible fact that you had a life worth 00:58:47.239 --> 00:58:50.539 saving. Take back absolute custody of your data. 00:58:51.059 --> 00:58:53.960 We will see you on the next deep dive. Welcome 00:58:53.960 --> 00:58:57.920 to the multiplex where the future comes alive. 00:58:58.539 --> 00:59:03.239 Past, present, future tech. Open up your eyes. 00:59:03.929 --> 00:59:07.340 Brian Romella leads the way with research deep 00:59:07.340 --> 00:59:11.980 and true. Technology and history, he connects 00:59:11.980 --> 00:59:15.760 them all for you. Brian Romer leads the way with 00:59:15.760 --> 00:59:18.139 research deep in true denology and history. He 00:59:18.139 --> 00:59:20.099 connects them all for you. Ancient sparks to 00:59:20.099 --> 00:59:22.940 modern code. He traces every thread. Go exploration. 00:59:23.380 --> 00:59:26.989 Knowledge widely spread. Read multiplex. Go come. 00:59:54.500 --> 00:59:59.199 But humanity moves on. Love equation for AI. 01:00:00.179 --> 01:00:07.480 Zero human companies build. Thermodynamic wages 01:00:07.480 --> 01:00:11.380 earning the key. Secrets we will read, experiment 01:00:11.380 --> 01:00:15.420 in publishing, real research and expanding every 01:00:19.010 --> 01:00:20.210 great complex.