القائمة
Knowledge on how audio CD rips are stored, identified, and verified
التثبيت باستخدام Codex أو Claude انسخ هذا Prompt والصقه في Codex أو Claude أو مساعد آخر ليراجع صفحة Skill ويثبّتها لك.
استنادا إلى تصنيف 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.