You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Since CHD is a format for preservation, I would expect that all properties of CDs should be supported. Unfortunately, CD_TEXT data is not among it, getting completely lost in the creation of a CHD. Roundtripping from a CD image to CHD and back to CD will not produce an identical CD as what was input.
Expected behaviour
That CD-TEXT data gets preserved in CHDs.
Steps to reproduce
I'll provide an example CD file here (one second long, single track, with basic CD-TEXT info):
chdman createcd -i silent.toc -o silent.chd
chdman extractcd -i silent.chd -o silent2.toc
After this step, you can examine that the silent2.toc file does not posses the CD-TEXT information found in the input file.
CD-TEXT is a bit of a rare extension to the audio CD format. Out of hundreds of CDs I own, maybe only a dozen of them have CD-TEXT data. There was always a chicken-and-egg problem with adoptions ("players don't support it so I won't include it" and "CDs don't have it, my player doesn't need to have it"), but it does exist in some commercial releases.
Given it is a standard of the CD Audio format (works on mixed-mode CDs too!), I believe it makes sense for CHD to preserve the data and allow it to round-trip.
I'll give warning that my little demo file is far from an exhaustive example, but the cdrdao man page describes all the options available. :-)
The text was updated successfully, but these errors were encountered:
There are two parts to CD TEXT – lead-in area info (MODE=4), and program area info (MODE=2). The CD TEXT data is stored in subcodes U to W (6 bits), organsied as packs of 24×6 bits and blocks of 8 packs (96×6 bits total). So technically, yes, it’s a case of not retaining subchannel information.
However, CHDs always contain a cooked table of contents rather than the raw lead-in content that the CD-ROM drive parses to obtain it. So to store the MODE=4 CD TEXT data, we’d need to either come up with a cooked CD TEXT format or come up with a way to allow raw lead-in data to be included.
The MODE=4 data in the lead-in area is what people usually mean when they talk about CD TEXT. This is where album and track information, copy protection status, “second TOC” information, etc. is stored.
The MODE=2 CD TEXT data consists of interactive text transmission system (ITTS, IEC61866) packets. It isn’t used as frequently or supported by as many players.
MAME version
0.269
System information
n/a
INI configuration details
Emulated system/software
n/a
Incorrect behaviour
Since CHD is a format for preservation, I would expect that all properties of CDs should be supported. Unfortunately, CD_TEXT data is not among it, getting completely lost in the creation of a CHD. Roundtripping from a CD image to CHD and back to CD will not produce an identical CD as what was input.
Expected behaviour
That CD-TEXT data gets preserved in CHDs.
Steps to reproduce
I'll provide an example CD file here (one second long, single track, with basic CD-TEXT info):
chdman createcd -i silent.toc -o silent.chd
chdman extractcd -i silent.chd -o silent2.toc
After this step, you can examine that the silent2.toc file does not posses the CD-TEXT information found in the input file.
silent.zip
Additional details
CD-TEXT is a bit of a rare extension to the audio CD format. Out of hundreds of CDs I own, maybe only a dozen of them have CD-TEXT data. There was always a chicken-and-egg problem with adoptions ("players don't support it so I won't include it" and "CDs don't have it, my player doesn't need to have it"), but it does exist in some commercial releases.
Given it is a standard of the CD Audio format (works on mixed-mode CDs too!), I believe it makes sense for CHD to preserve the data and allow it to round-trip.
I'll give warning that my little demo file is far from an exhaustive example, but the cdrdao man page describes all the options available. :-)
The text was updated successfully, but these errors were encountered: