# PFES-ENG-022 — Media Representation

**Status:** Active  
**Knowledge Cycle Stages:** Represent, Preserve

## Purpose

Represent optical media in forms suitable for engineering while preserving information beyond ordinary ISO use.

## Engineering Problem

No single format captures all sectors, descriptors, authentication resources, geometry, provenance, and behavior.

## Historical Engineering Evolution

Project work moved from ISO-only outputs toward raw images plus structured sidecars and external resources such as AD, PFI, DMI, and validation metadata.

## Engineering Discoveries

- Multiple complementary representations are often better than one overloaded format.
- Media representations are engineering artifacts.

## Architectural Decisions

- Keep the original acquisition authoritative.
- Use sidecars for structured metadata.
- Trace every representation to source acquisition.

## Knowledge Produced

- Raw images
- ISO views
- Sidecars
- Descriptor files
- Emulator inputs

## Knowledge Consumed

- Acquired media
- Identity
- Validation

## Current Engineering State

Current Xbox workflows use full raw images with `.xdvd.json` and related metadata. Emulator sessions consume both firmware and valid media representations.

## Engineering Lessons

- The extra files are not auxiliary; they carry engineering evidence.

## Negative Knowledge

Project Frankenstein no longer assumes:

- ISO alone completely describes optical media.
- Metadata can always be regenerated.

## Current Implementations

- `.xdvd.json` / `.media.json` sidecars
- External AD/PFI/DMI resources

## Future Implementations

- Engineering media package specification
- Automatic package validation

## Open Questions

To be expanded during engineering review.

## Why This Chapter Exists

Representations make media usable for engineering without pretending one file contains everything.

## Original Xbox Engineering Media Package

The mature Option 1 workflow produces a multi-file engineering media package:

```text
<title>[media].iso
<title>[media].media.json
<title>[media].xdvd.json
<title>[media].ad_c0.bin
<title>[media].pfi.bin
<title>[media].dmi.bin
```

The `.iso` contains 2048-byte logical sector data. Firmware-facing authentication, physical-format, and manufacturing information that cannot be represented honestly as ordinary READ(10) sectors remains external.

Responsibilities are separated:

- `.iso`: host READ(10) sector data;
- `.media.json`: media identity, reconstructed image geometry, observed media state, write-media state, reconstruction policy, and validation;
- `.xdvd.json`: legacy command-replay and detailed SCSI-response compatibility data;
- `.ad_c0.bin`: vendor/authentication response payload;
- `.pfi.bin`: Physical Format Information;
- `.dmi.bin`: Disc Manufacturing Information and media identity material.

Media profiles remain separate from firmware/device profiles. The session layer binds the selected device profile, media profile, firmware image, and runtime configuration.

## Coordinate Systems Must Remain Explicit

Original Xbox workflows use several different LBA coordinate systems:

- reconstructed image LBA;
- locked/video host LBA;
- unlocked GDR-8050L host LBA;
- XISO/game-region-relative LBA;
- XDFS-relative LBA.

These values must never be silently interchanged. Sidecars must name the coordinate system of every offset and count.

## Planned CCI Image Support

Project Frankenstein intends to support CCI images as a future media representation.

The current historical reverse-engineering note proposes that Repackinator CCI creation consists of two conceptually separate transformations:

1. scrub an Xbox image by replacing selected unused or nonessential sector data;
2. compress the scrubbed result into a CCI container using LZ4-related compression.

This is useful as a working hypothesis, but it is not yet a validated format specification.

CCI output support must therefore begin with format validation rather than direct implementation. The dumper should preserve the distinction between:

- the archival or Redump-reference image;
- the scrubbed logical image;
- the compressed CCI container.

A CCI file must never be treated as a bit-identical substitute for the unscreened archival source unless independent evidence proves identity.

