A 2004 iPod, read to the metal Ghosts in the Free Space

Abstract

A working device is not a snapshot. It is a stratified site, and most of its history is written in the layers nobody meant to keep.

The object was an Apple iPod, fourth generation — the grayscale click-wheel model, order number M9282, built in the forty-second week of 2004. It was plugged into a modern Windows PC to be looked at before a planned factory restore. It mounted instantly as drive E:, a 18.6 GB FAT32 volume labelled DAN'S IPOD, about a third full. No drivers, no iTunes, no ceremony. That easy mount is the first fact of the case: a Windows-formatted iPod is not a sealed appliance, it is a filesystem, and a filesystem can be excavated.

What follows is a field report with two subjects running in parallel. The surface subject is the device: what it held, what it had held, and what that says about a person between 2005 and 2010. The deeper subject is the investigator — an AI agent given the device, a set of tools, and latitude to decide what to do. Where the machine was read, decoded, or guessed, the text says so. Every substantive claim below carries a label.

01

Teaching a parser to read 2004

Before trusting a single statistic, prove the ruler.

The device announces itself in a plain-text file, iPod_Control/Device/SysInfo. Recovered It gives the board name iPod Q21, family 0x4 (fourth generation), firmware 3.1.1 — the last software this grayscale line ever received — a US region code, and a serial number, printed here as 4U442······ with its unit-unique tail masked. That serial is worth a pause, because the first attempt to read it was wrong.

The pre-2010 Apple serial encodes a production week in characters four and five. Read quickly, they looked like 24 — week 24, mid-June 2004. Decoded But the digits are 42, not 24: week 42, mid-October 2004. The transposed reading was not just sloppy, it was impossible — a mid-June build would predate the model's own July 19 launch. The internal contradiction is what flagged the error. It is the first small lesson of the investigation: a date that can't be true is more useful than one that merely looks plausible.

The real prize is iPod_Control/iTunes/iTunesDB, a 2.2 MB binary catalogue of every track. Its format is a nested tree of four-character chunks — mhbd for the database, mhit per track, mhod for strings in UTF-16 — documented decades ago by the iPodLinux project. Writing a parser for it is not hard. Writing one you can trust is the whole game, because a single wrong byte offset silently corrupts every number built on top of it.

So the parser was calibrated before it was believed. It dumped the raw header bytes of three known tracks and checked decoded fields against values that could be verified by ear and eye:

# mhit header, track 1 — calibrating field offsets
0x28 length_ms  = 0x00042005 = 270341 ms  → 4:30  ok
0x34 year       = 0x000007d5 = 2005       → ok
0x38 bitrate    = 0x000000a0 = 160 kbps   → ok
0x3c samplerate = 0xac440000 = 44100 Hz   → ok
0x1f rating byte → {0: 1415, 100: 6}    → stars x20, clean
0x20 rating byte → noise, all values   → rejected

The rating field is a good example of why calibration matters. Two candidate offsets both looked like plausible homes for a star rating. One produced a clean distribution — 1,415 songs unrated, six rated, nothing in between; the other produced uniform noise. Decoded Only after that check were the aggregates computed: Recovered 1,421 tracks, 6.13 GB, 94.2 hours of music, 2,765 lifetime plays, and a listening history dense enough to have a personality.

And it did. The library is a near-perfect core sample of mid-2000s American emo and pop-punk. One artist — Say Anything — accounts for 86 tracks and 520 plays, roughly a fifth of everything ever played on the device. Brand New, Taking Back Sunday, Minus the Bear, American Football, Cartel, Northstar; a reggae seam of Bob Marley and Sublime; a few Lewis Black comedy albums ripped as hour-long single tracks. At this point the working title in the notes was time capsule: a library frozen at its last sync in December 2010 and untouched for fifteen years. That title was about to fall apart.

02

A second library in the free space

The 12 gigabytes that looked empty were the most informative part of the disk.

An intact database is a tidy story, and tidy stories should be distrusted. The obvious unexamined territory was the 12.4 GB of free space. On a FAT32 volume, “free” does not mean “blank” — it means the clusters are unclaimed, and clusters that were written and later released still hold their old contents until something overwrites them. The question was whether any of that space had ever been used.

Reading the File Allocation Table answered it. Recovered Of the free clusters, 541,702 — about 2.07 GB — sit below the highest allocated cluster, in 155 discrete runs, some over 200 MB long. That is the signature of deletion: space that was occupied, then freed, now stranded beneath the live data. The other 10.3 GB is a contiguous tail above the high-water mark, almost certainly untouched since the disk was formatted. So the plan changed. Rather than image the whole volume — twenty-two minutes of continuous load on a twenty-one-year-old drive — the carve targeted only the 2.07 GB of holes.

# FAT allocation map — read-only, physical volume
allocated clusters : 1,614,585   6.159 GB  live library
free below H2O     :   541,702   2.066 GB  recycled — 155 runs
free above H2O     : 2,705,914  10.322 GB  virgin tail
highest allocated  : cluster 2,156,288

The holes were full of music. A signature scan found deleted ID3 headers, MPEG frames, and — the real find — 21 deleted mhbd markers. There were older copies of the database itself in the free space. Recovered Because iTunes rewrites the catalogue as one contiguous blob, each deleted generation could be read back from its own header's declared length and re-parsed with the same calibrated offsets.

Two of those generations predate everything in the live library. The largest clean one is a snapshot from October 2005: Decoded 970 tracks, 3,763 plays, with add-dates running April to October 2005. The device had an entire earlier life — and it was a different person's taste in the same body. Fall Out Boy leads it with 365 plays; then Dashboard Confessional, The Academy Is…, Spitalfield, Anberlin. The Beatles, The Doors, and the Eagles are present in 2005 and completely gone by the second life. Only 219 of the 968 first-life songs — 22% — survive into the final library. The 2006 restore did not update this iPod. It erased it.

This is the moment the investigation stopped being an inventory and became archaeology. The “time capsule” was real, but it was the second settlement on the site. And there were more layers between: Decoded a ladder of intermediate database generations shows the second library rebuilding — 557 tracks in August 2006, 718 by September, 827 by October, 1,019 by January 2007, 1,421 by 2008. The play counters reset with the restore, too: 3,763 plays in the 2005 database, then 712 in the first 2006 one. The device's true lifetime listening is well over six thousand plays, not the 2,765 the surviving catalogue reports. A single snapshot had been quietly lying about the total by more than half.

03

Every file is a receipt

The database records what iTunes believed. The files remember where they came from.

A catalogue entry says “artist, title, album.” The audio file underneath it carries something the catalogue cannot: the fingerprint of the tool that made it. Sweeping all 1,421 files — full ID3 parsing on the MP3s, atom-tree walks on the AAC files — turned the library into a provenance map.

The headline is an absence. Recovered No file in the library carries a purchase marker — no FairPlay DRM, no iTunes Store account atoms — anywhere in the 295 AAC files, the format any Store download of the era would have used. Of those AAC files, 278 carry the Gracenote CD-lookup tag iTunes writes when it imports a disc, which points to a CD-ripping workflow rather than a download. The MP3s are harder to place: Inferred 723 of 1,126 are bare constant-bitrate files with no encoder tag at all, 467 of them at exactly 128 kbps — a profile consistent with mid-2000s peer-to-peer files, though bitrate alone cannot prove where a file came from.

Under the hood the files are a museum of a decade of ripping software. Recovered Encoder credits span SoundJam MP — the pre-iTunes Mac player Apple bought in 2000 — through Audiograbber with a LAME plug-in, Exact Audio Copy in secure mode, RealJukebox, FreeRIP, mp3.com, and an iTunes version ladder from v2.0 to v7.3. Dozens of MP3s carry scene-release tags in their comment frames; fourteen are marked Release type: Advance — pre-retail leaks — and their rip dates run from February 2005, well before the earliest add-date in the library, which means they were made by someone else and passed along. Two files credit an IRC channel by name. A quarter of the MP3s had also been touched by Windows Media Player, which left its own metadata behind: two music managers, two ecosystems, one messy source PC.

The mix shifts over time, and the shift is measurable. Reconstructed Joining encoder type to add-date, the share of each half-year's new music that shows CD-rip evidence climbs from about 26% in the first half of 2006 to 54% in the second half of 2007. Over eighteen months the balance visibly tips from downloading toward ripping — what changed in the owner's habits is theirs to say, but the ratio in the bytes is not ambiguous. And carried silently through all of it: Recovered 68 files hold 2.68 MB of embedded cover art on a device with a grayscale screen that could never display a single pixel of it — dead weight synced faithfully for years because nobody told iTunes to stop.

04

Three clocks, one silence

Every track carries three timestamps that disagree, and the disagreement is the record.

Each song has a filesystem modification time, a database “date added,” and a last-played time. Naively they should roughly agree. They don't, and an early assumption about why was wrong. Recovered For 536 of the 1,421 tracks — 38% — the file's modification time is earlier than the date it was supposedly added to the library. That is impossible if the modification time were the sync time. It isn't: iTunes preserved the source file's own timestamp when it copied it across. The modification times date the music on the owner's PC; the FAT creation times date when it landed on the iPod. Two clocks, two different events, and separating them is what made the timeline legible.

Once separated, the sync history sharpens to the minute, cross-checked three ways: Reconstructed the August 2006 restore appears identically in FAT creation times, in a system file's modification time, and in the database's own internal playlist timestamps — all landing at 2006-08-07 00:57. Hidden events surface that the database alone conceals: a burst of 125 catalogue entries created in eleven minutes on November 14, 2006, for music that had physically been on the device since June — a library re-import, not new music. The famous “big month” of November 2006 is mostly a re-cataloguing artifact.

And then the silence. Reconstructed The last playback this iPod recorded was logged on 2010-01-17 at 12:13. The database was last written eleven months later, on 2010-12-17 at 13:31 — the catalogue and both preference files stamped in the same second, no music added, nothing changed. The device's temporary “Play Counts” scratch file, which iTunes deletes at every sync and playback recreates, is absent. Inferred So the story of the ending is legible: the iPod sat unplayed for most of a year, was connected one last time in December 2010, handed its host an eleven-month-old listening record, and was not played again — not until this investigation stirred it back to life sixteen years later. Its last act before going dark was to file its own obituary.

The last thing this device recorded itself hearing was a song about waiting: “Hey There Delilah.” Then it went quiet — for sixteen years.

05

What the owner chose

A track list is what someone owned. A playlist is what they decided.

The database holds seventeen playlists, and one of them is different from all the others in kind. Decoded On-The-Go 1 could only have been built on the device itself, thumbed out on the click wheel with no keyboard in sight. It contains exactly three songs — the owner's entire Angels & Airwaves holdings — and the order is not the album order. The hit single is first. Two of the three songs were played exactly once in their lives, both on the same day in March 2007, which is almost certainly the afternoon the playlist was made and played. It is the single most direct trace of a hand on the device.

The hand-named playlists are a portrait of an obsession managing itself. Recovered sa is 57 tracks, 100% Say Anything. saaa is that band's album In Defense of the Genre, tracks 1–14 in order, added one day after the album's release. zmixxx, despite the name, is not a mix at all — it is Brand New's Your Favorite Weapon reproduced complete, in album order. And songs turned out to be a smart playlist with its rules quietly disabled, an accidental duplicate of another list. The ratings explain themselves in the same breath: Decoded the owner rated exactly six songs in the device's whole life, every one of them five stars. Rating, for this person, was not a scale. It was a shrine.

The most forensically satisfying playlist is the dullest-looking one. Top 25 Most Played is an automatic list, and its membership is exactly correct — the true top 25 by play count. But its order is stale. Reconstructed Exactly three songs are ranked below where their play counts say they belong, and those three are the only tracks in the list played after mid-2009. iTunes kept merging their play counts at later syncs but never re-sorted the sequence. The frozen ordering pins the last real curation event to a library migration on 2009-07-03 — a timestamp shared by nine playlist records at once. The list is a photograph of the owner's taste taken in July 2009 and never retaken.

06

The investigator in the loop

The device is the narrative. The way it was investigated is the case study.

It would be easy to present the preceding sections as a clean march from question to answer. It wasn't, and pretending otherwise would waste the more interesting half of the story. First, the whole haul in one place — every layer of the site, what it gave up, and how much to trust it:

Swipe to view the full table →

And here is the candid ledger of how the investigator behaved while producing that inventory.

A human forensics expert would have noticed some of this sooner. The FAT32 creation-versus-modification distinction is a first-day fact in disk forensics; the AI rediscovered it empirically after tripping on it. A seasoned examiner would also have reached for free-space carving as a reflex on any “too clean” device, rather than arriving there after the database looked suspiciously complete.

But the failure mode worth naming is the opposite one. A rigid recovery utility — the kind of tool that scans a disk and emits a list of files — would have done the file-carving faster and cleaner than any of this. It would also have missed the entire story. It would have reported 970 orphaned MP3s as generic recovered files, never recognizing them as a coherent earlier library. It would not have parsed a deleted database to reconstruct a play-count history. It would not have noticed that a playlist's ordering was stale while its membership was current. The value here was not in reading bytes off a platter. It was in knowing which absences were load-bearing.

The honest summary: the AI was persistent, appropriately cautious with the hardware, genuinely creative in choosing the free-space route — and repeatedly sloppy in exactly the places where a fast model moves quickly, especially text encoding and over-eager pattern matching. It was neither the hero nor the gimmick. It was a capable junior investigator who needed its own contradictions to keep it honest, and mostly got them.

07

A field kit for old hardware

None of this is generic advice. Each rule is something this device taught by punishing its absence.

1. Preserve before you manipulate. The backup came first, and every risky read after it ran on the copy. A restore was one click away from erasing all of this permanently.
2. Prove the ruler before you measure. Two plausible rating offsets, one real. Calibration against known values is the difference between data and confident noise.
3. Treat free space as a primary source. The most important discovery — an entire earlier library — existed only in clusters the filesystem called empty.
4. Read metadata as evidence, not decoration. Encoder tags and CD-lookup markers reconstructed an acquisition history the catalogue could not express.
5. Correlate weak signals across formats. Three disagreeing clocks, cross-checked, dated a restore to the second and exposed hidden re-imports.
6. Record the negative findings. “No purchase markers detected,” “no Play Counts file,” “no timestamps after the last sync” each carried as much meaning as anything recovered.
7. Keep recovery and reconstruction in separate columns. A recovered byte and an inferred story are different kinds of thing; the labels in this essay exist so a reader can tell which is which.
8. Verify the assembled narrative, not just the parts. Two “database generations” were real chunks assembled into a false whole. Individual artifacts can be sound while the story built from them is wrong.

08

What we still don't know

Preserving uncertainty is part of the record. Several questions are genuinely open. Speculative The purpose of the final December 2010 connection is undecidable from the evidence — a deliberate sync, or simply a charge that iTunes turned into a sync on its own. The device's own real-time clock was never set, so on-device settings carry only a 1999–2000 epoch date; when the owner last changed a setting is unknowable. The 10.3 GB virgin tail was deliberately not carved, on the judgment that its information value did not justify the mechanical risk to the drive — a route left open on purpose, not closed. And the deeper generations recovered from free space were parsed for counts and titles but not exhaustively reassembled; a more complete diff of the 2005 library against the 2006 rebuild would sharpen the picture of exactly what the restore destroyed.

The device still works. Its drive read 6.156 GB without a single error. But it is a mechanical disk from 2004, and the responsible conclusion is the unglamorous one: the artifact is now safer as a verified copy than as a spinning platter, and the next person to plug it in should back it up before they do anything else — especially the restore that started this whole inquiry, which would have overwritten every ghost in this report.