[Feature Request] Sidecar Meta File Support for Full CD Subchannel/CUE Replication (Multi-index, CATALOG, ISRC)

[crashGG]

Currently, the CHD (V5) format suffers from architectural limitations that prevent it from storing critical CD metadata, specifically:Multi-index Tracks: The format drops secondary index markers (Index 00, Index 02+, etc.), which causes accurate sub-track split points and audio pre-gaps to be permanently lost (Ref: mamedev/mame#10308).Disc-level Meta Tags: Header-level tags inside .cue files—such as CATALOG (UPC/EAN barcodes) and ISRC codes—are stripped entirely during conversion (Ref: mamedev/mame#15529, #15214).While the upstream MAME team focuses primarily on arcade preservation (where these Redump-style subchannel specifics are rarely utilized), libchdr is the de facto standard for console emulators (e.g., RetroArch cores, DuckStation, Flycast, and standalone Saturn/Sega CD emulators). For home console emulation, the absence of this data directly causes breaking gameplay and audio bugs.Since modifying the core CHD format requires a V6 specification—which has been stalled in MAME's roadmap for years—I propose a pragmatic, decentralized solution implemented directly within libchdr: Sidecar Metadata File Support.

Proposed Solution:
Sidecar Metadata File (.chd.meta)Instead of altering the compressed .chd binary file, libchdr can look for an optional companion text-based sidecar file sharing the same base filename (e.g., Game.chd paired with Game.chd.meta).When libchdr initializes a CHD image, it will check for this sidecar file. If present, it will dynamically inject the missing indices, catalog codes, and track metadata back into the virtual layout structure delivered to the core emulator.

Why This is Necessary & Key Benefits

1. Perfect Console Emulation CompatibilityCertain platforms—most notably the Sega Saturn and Sega CD—rely strictly on precise multi-index track timing or sub-code data to bypass copy protection, trigger CD audio tracks, or sync in-game events. This enhancement allows libchdr to parse these games flawlessly without forcing users to revert to bulky, uncompressed .bin/.cue rips.
2. 100% Backward Compatibility with Existing ArchivesUsers will not need to re-compress their massive, terabyte-scale collections of existing CHD V5 files. They only need to generate a tiny sidecar file (a few hundred bytes) exclusively for the specific games that require it.
3. Bypassing MAME's Stalled V6 RoadmapThe upstream MAME team has shown long-term hesitation regarding the CHD V6 development path, leaving these format bugs in limbo. Furthermore, upstream MAME naturally deprioritizes non-arcade console edge cases. Implementing this feature directly inside libchdr empowers the console emulation scene to resolve these long-standing issues independently.

[rtissera]

One of the whole points about CHD format is single file per disc.
I am not against the idea of implementing vendor (libchdr) specific extensions of CHDv5 to overcome those limits (yes, there are PITA, mostly on Saturn, PS1, Dreamcast (MIL-CD) rips.
I am not aware of any Sega CD specific issue.
Also you message looks like a bit LLMed.

[crashGG]

Man, hold up, you laughin' at LLMs? You don't know the struggle out here on GitHub when English ain't your first language, homie. Them old school translators are goofy as hell, big trippin' on basic technical words, just frontin' like they useful.

[rtissera]

@crashGG no I have nothing against LLMs and use Claude on daily basis, was just curious about the AI tone of your message. And English is not my first language, neither fyi.
This point has been discussed various times over years, if MAME does not implement V6, then maybe it's about time to design either :

• some kind of extended feature set. Easy to wire in reader, but biggest problem is : this will need some custom chdman tool.
• external enhancement file like you suggested, but the struggle is I am afraid of stacking "hacks" (CHD + META + SBI for PSX for instance).

[crashGG]

Based on practical emulation needs and maintainability, here is the refined counter-proposal:
Refined Proposal:
Direct Sidecar Implementation
Scope Reduction & Practical Impact
PSX: standard .sbi files already handle LibCrypt protection for PAL titles. No metadata overlapping is required.
Sega CD: missing CATALOG numbers do not affect emulator execution or game logic.
The Actual Bottleneck: the critical regressions are strictly isolated to Sega Saturn (multi-index tracking) and Dreamcast (MIL-CD layout structure).
Zero Tooling Overhead (No chdman Fork)Requiring a custom chdman build to re-pack terabytes of user archives creates massive adoption friction. The goal is zero re-compression.Human-Readable & Drop-In CompatibilityUsers should be able to fix missing subchannel data using basic text editors or by leveraging existing assets.
We can achieve this via two potential implementations for the .chd.meta file:
Option 1: Direct .cue Passthrough (Simplest)libchdr looks for Game.chd.cue (or other extensions) alongside Game.chd. If present, it overrides the internal CHD track layout with the plain-text .cue data. Users just rename their original CUE sheet.
Option 2: Minimalist Meta SyntaxA lightweight text format explicitly detailing only the missing indices and descriptors:
TRACK 02 AUDIO
INDEX 00 01:23:45
INDEX 02 01:25:00

[johnsanc314]

Instead of a sidecar file, why not just create a standard for this meta info and write directly to the CHD? The CHD format already supports freeform meta data with chdman's addmeta command.

[rtissera]

That is indeed a proper way to do it I think

[rtissera]

Maybe even embedding the original cuesheet as meta since CHD already provides LBA<->hunk logic

[rtissera]

Subcode are available in CloneCD images as .sub format to my best knowledge

[Sanaki]

It is indeed possible to produce a chd with intact libcrypt-passing subchannels by generating it from a toc format disc image. I have instructions for doing so in the recently resolved libretro/beetle-psx-libretro#811 if that's of interest. Otherwise I agree, the metadata should be part of the file. Fair warning though, last I recall the metadata modification commands only functioned on uncompressed chds, requiring that you handle generation of the chd in multiple stages (compression as a secondary stage). Why? I have no idea, someone broke it over a decade ago and no one fixed it.