Menu
Knowledge on how audio CD rips are stored, identified, and verified
Installer avec Codex ou Claude Copiez ce prompt, collez-le dans Codex, Claude ou un autre assistant, puis laissez-le vérifier la page du skill et l'installer pour vous.
Basé sur la classification professionnelle SOC
| name | phono-archive |
| description | Knowledge on how audio CD rips are stored, identified, and verified |
Audio CDs are backed up from physical media into container formats shared with game preservation (CUE/BIN, CHD), but they follow an entirely different identification and verification model than ROMs.
IMPORTANT: When you learn something about an audio-disc format, algorithm, or data source, add it to a named file in formats/ and link to it from any database or provider doc that uses it. Always include the upstream sources where the knowledge came from — same rule as the sibling retro-archive skill.
Unlike retro-game ROMs (identified by file-hash matching against DAT databases), audio CDs are identified by their Table of Contents (TOC) — the per-track sector offsets and lead-out position burned into every CD. The TOC is stable across rips; two bit-identical rips of the same physical disc will always produce the same DiscID, even if their BIN files differ due to drive-offset differences.
This separation is a feature, not a bug:
A single disc has multiple canonical IDs because different databases derive different values from the same TOC:
| ID Kind | Used By | Where It Lives |
|---|---|---|
| MusicBrainz DiscID | MusicBrainz | formats/DiscID.md |
| FreeDB / CDDB ID | Historical FreeDB, many legacy rippers, some Japanese DBs | formats/DiscID.md |
| AccurateRip id1, id2 | AccurateRip, CUETools DB | formats/DiscID.md |
| Barcode / Catalog Number | Discogs, Amazon, Tower Records, etc. | printed on packaging — not derived from TOC |
All TOC-derived IDs are computed from the same four inputs: first track number, last track number, lead-out sector offset, and per-track sector offsets. Compute them once in phono-junk-toc; every provider consumes them.
Verification databases store community-submitted per-track checksums keyed by disc IDs. A positive match from multiple independent submitters is strong evidence that your rip is bit-perfect.
| Database | Checksum Algorithm | Where It Lives |
|---|---|---|
| AccurateRip | v1, v2 (offset-compensated weighted sum) | formats/AccurateRip.md |
| CUETools Database (CTDB) | Custom CRC | (not yet documented) |
Audio CDs use the same containers as retro disc games:
.cue + .bin — most common. The CUE sheet carries the TOC..chd — MAME's compressed format. The TOC is in the CHD metadata..wav / .flac per track — common after conversion, but DiscID-lossy if the TOC isn't preserved.Container parsing lives in the shared junk-libs-disc crate (copied from retro-junk-disc). See that crate's README and the retro-junk formats/CUE.md skill for details — the parser is identical. Audio CDs use TRACK <n> AUDIO entries rather than MODE1/2048 or MODE2/2352.
phono-junk is designed around pluggable providers (trait-based, see phono-junk-identify). Day-1 identification providers are MusicBrainz and Discogs; additional sources (VGMdb, Tower Records, Gracenote, CDJapan) land as additional trait impls.
Provider-specific endpoints, auth, rate-limit policy, and scraping selectors live in the sibling music-scraping/ skill.