Hubbry Logo
CD-TextCD-TextMain
Open search
CD-Text
Community hub
CD-Text
logo
8 pages, 0 posts
0 subscribers
Be the first to start a discussion here.
Be the first to start a discussion here.
CD-Text
CD-Text
CD-Text
View on Wikipedia
from Wikipedia
CD-Text
Media typeOptical disc
Encoding2 channels of LPCM audio, plus ITTS data
Read mechanism780 nm laser diode
StandardRed Book
Developed byPhilips & Sony
UsageAudio storage
Extended fromCD-DA

CD-Text is an extension of the Red Book Compact Disc specifications standard for audio CDs. It allows storage of additional information (e.g. album name, song name, and artist name) on a standards-compliant audio CD.

The specification for CD-Text was included in the Multi-Media Commands Set 3 R01 (MMC-3) standard, released in September 1996 and backed by Sony.[1] It was also added to new revisions of the Red Book.[2] The actual text is stored in a format compatible with Interactive Text Transmission System (ITTS), defined in the IEC 61866 standard.[3] The ITTS standard is also applied in the MiniDisc format, as well as in Digital Audio Broadcasting technology and Digital Compact Cassette.

Storage

[edit]
Optical discs
General
Optical media types
Standards
See also

The CD-Text information is stored in the subchannels R to W on the disc. This information is usually stored in the subchannels in the lead-in area of the disc, where there is roughly 5 kilobytes of space available. It can also be stored on the main program area of the disc (where the audio tracks are), which can store about 31 megabytes.[1] Since the R to W channels are not used in the Red Book specification of audio CDs, they are not read by all CD players, which prevents some devices from reading CD-Text information.[1]

Format

[edit]

CD-text data is defined in a scattered manner between MMC-3 and Sony documentation. The information below uses GNU libcdio's description.[4]

On the lowest level, CD-text is stored in 18-byte "pack" units; this part is defined in MMC-3 Annex J. Each pack consists of 4 bytes of header—type indicator, track number reference, sequential counter, block number and character position indicator (BNCPI); 12 bytes of payload; and 2 bytes of CRC. The type indicator ranges from 0x80 to 0x8F, the 13 defined values being:[5]

CD-Text keywords
Type Keyword Description Section Format
0x84 ARRANGER Name(s) of the arranger(s) Any Character
0x83 COMPOSER Name(s) of the composer(s) Any Character
0x86 DISK_ID Disc Identification information Disc Binary
0x87 GENRE Genre Identification and Genre information Disc Binary
0x8e ISRC International Standard Recording Code of each track Track Character
0x85 MESSAGE Message from the content provider and/or artist Any Character
0x81 PERFORMER Name(s) of the performer(s) Any Character
0x82 SONGWRITER Name(s) of the songwriter(s) Any Character
0x80 TITLE Title of album name or track titles Any Character
0x88 TOC_INFO Table-of-content information Disc Binary
0x89 TOC_INFO2 Second table-of-content information Disc Binary
0x8e UPC_EAN UPC/EAN code of the album Disc Character
0x8f SIZE_INFO Size information of the block Any Binary

The BNPCI is used to define information that does not fit in one pack. This can be text or binary data. The BNCPI also indicates whether the text is single-byte or double-byte data in the top bit. This determines how null-terminated strings are defined – one or two bytes of 0x00.[4] The DBCS mode is rarely, if ever, used. Its special null handling is not necessary for computer DBCS code pages, as they are "hybrid" with ASCII and compatible in the NUL behavior. UTF-16 could be the intended use.

For block types listed above as "character" (per MMC-3), the payload is a simple null-terminated string. (MMC-3 is written confusingly here – it describes the encoding as "ASCII" in the pack type table despite mentioning the BNCPI flag modifying its behavior later.) The descriptions of the binary fields are vague, but the developers of GNU libcdio has either matched them to sections of MMC-3 or written new descriptions based on Sony's sample.[4]

Another layer of encoding specification is found at this payload level, in the SIZE_INFO block. Here the first byte may be used to indicate the encoding, ASCII, Latin-1, or "MS-JIS". This is supported by the original Sony authoring tools.[4]

See also

[edit]

References

[edit]
[edit]
Revisions and contributorsEdit on WikipediaRead on Wikipedia

CD-Text

View on Grokipedia
from Grokipedia
CD-Text is an extension to the Red Book standard for (CD-DA), enabling the embedding of textual metadata—such as album titles, artist names, track titles, songwriter credits, genre, and disc-related information—directly onto audio CDs for display on compatible players. This feature enhances user experience by providing on-disc information without relying on external databases, while maintaining full with standard CD players that ignore the additional data. Developed jointly by Philips and Sony, CD-Text was announced in June 1996 as a means to add informational capabilities to the existing CD format. The specification was formalized in the Multi-Media Commands Set 3 (MMC-3) standard released in September 1996, building on the original Red Book standard from 1980 (later published as IEC 60908). It leverages unused subcode channels (R through W) in the CD's lead-in area (up to 5 KB of data) and program area (potentially up to 31 MB across the disc), ensuring no impact on audio quality or capacity. The text data follows the Interactive Text Transmission System (ITTS) format defined in IEC 61866, organizing information into language-specific blocks with 13 pack types (e.g., for titles, performers, or messages) per block, each including a header, payload, and cyclic redundancy check (CRC) for error detection. Support for CD-Text reading and writing is available in various software tools like Nero and ImgBurn, though adoption varies: many modern CD players and car stereos display it, but not all devices or operating systems (e.g., early versions of iTunes) natively handle it during playback or ripping. Despite its utility, CD-Text's prevalence declined with the rise of digital streaming, yet it remains a notable evolution in optical media metadata standards.

History and Development

Origins

CD-Text originated in the mid-1990s as a collaborative effort between and to extend the capabilities of the (CD-DA) format defined in the Red Book standard. The two companies, which had previously co-developed the core CD technology in the early 1980s, aimed to incorporate textual metadata—such as track titles, artist names, and album details—directly onto audio CDs without disrupting the established audio encoding or playback mechanisms. This development built on their experience with earlier CD extensions like CD-Graphics (CD-G), adapting concepts for text storage to create a more integrated audio experience. The primary motivation for CD-Text was to embed essential disc information on the medium itself, minimizing reliance on supplementary materials like printed inserts or emerging external databases for metadata retrieval. By doing so, and sought to enhance user convenience and compatibility with evolving playback devices, allowing displays of text during audio reproduction on compatible players. CD-Text was announced by and in June 1996. Development progressed through internal collaboration, culminating in the formal specification's inclusion in the Multi-Media Commands Set 3 Revision 01 (MMC-3 R01) standard, released by in September 1996. This timeline reflected and 's ongoing commitment to iterative improvements in optical media, ensuring with existing CD infrastructure while introducing new data-handling features.

Standardization

CD-Text was formally specified in the Multi-Media Commands Set 3 (MMC-3) standard, released in September 1996 and developed through collaboration between Sony Corporation and Philips Electronics. This inclusion defined the commands and sub-channel mechanisms for accessing CD-Text data on audio CDs, enabling devices to read embedded metadata such as track titles and artist information. Subsequent integration occurred in the revised Red Book specifications under IEC 60908, with the second edition published in February 1999 incorporating as an official extension to the system. This update aligned with the Interactive Text Transmission System (ITTS) outlined in IEC 61866:1997, ensuring compatibility in text packet formatting and transmission protocols across audiovisual systems. The (IEC) approved these enhancements, leading to widespread adoption in CD production guidelines by 1997, as evidenced by the release of over 100 CD-Text-enabled titles from major labels that year. Minor updates in the MMC-4 standard and subsequent revisions further improved compatibility by refining read commands and error handling for CD-Text data on evolving optical drives.

Technical Specifications

Storage Mechanism

CD-Text data is physically stored in the subchannels through within the lead-in area of the , utilizing space that was previously unused in the standard CD format and providing a capacity of up to approximately 5 KB. This placement allows for the inclusion of essential metadata, such as basic disc and track , without altering the audio content. The lead-in area, which precedes the program area containing the audio tracks, serves as the primary location for this to ensure quick accessibility during disc initialization. For discs requiring more extensive text, CD-Text can extend into the program area using the R-W subchannels, enabling a total storage capacity of up to 31 MB across the entire disc. In this configuration, the data is distributed via subcodes embedded uniformly throughout the audio tracks, but it remains optional and does not overwrite or interfere with the main audio data, preserving the integrity of the stereo audio signal. This approach leverages the inherent structure of CD subcodes, originally defined in the Red Book standard for , to add textual enhancements seamlessly. The reading process for CD-Text mirrors that of standard audio playback, employing the same 780 nm infrared to scan the disc's pits and lands, followed by specialized subchannel decoding to extract and interpret the embedded . This decoding occurs in parallel with audio extraction and introduces no additional overhead beyond the predefined subcode allocation, thereby avoiding any degradation in audio quality or playback performance.

Data Format

CD-Text data is structured into fixed-length 18-byte packs, which form the fundamental units for storing textual and binary metadata on the disc. Each pack comprises a 4-byte header, a 12-byte section for the actual , and a 2-byte (CRC) field for error detection. The CRC is computed using the X16+X12+X5+1X^{16} + X^{12} + X^5 + 1, with the result inverted and stored in big-endian format. These packs are primarily located in the R-W subchannels of the CD's lead-in area. The header provides essential metadata for interpreting the pack:
  • Byte 0: Pack type identifier (8 bits, e.g., 0x80 for track title).
  • Byte 1 specifies the track number (0 for disc-level , 1–99 for individual tracks).
  • Byte 2 holds the sequence number (ranging from 00h to FFh), which orders packs within a text block.
  • Byte 3 indicates the character position or block number, with its most significant bit (bit 7) flagging double-byte mode (1 for double-byte characters, 0 for single-byte).
Pack types are categorized into text packs (e.g., identifiers starting with 80h–85h or 8Eh for textual content) and binary packs (e.g., 86h–89h, 8Dh, or 8Fh for non-textual such as images or codes), though binary packs see limited practical use. Text packs support sequential numbering to chain multiple units for strings exceeding the 12-byte limit, allowing up to 255 packs per block within a text group. For extended character support, the format includes double-byte mode, where each character occupies two bytes in the payload, terminated by a two-byte null sequence; this enables handling of character sets like those for Japanese, offering a form of Unicode-like extensibility. However, the MMC-3 specification provides somewhat vague details on the precise mechanics of this mode, leaving room for implementation variations. Text strings in the payload are null-terminated (one byte for single-byte mode, two for double-byte), with unused bytes zero-padded.
Byte PositionFieldDescription
0Pack Type8 bits: pack type identifier.
1Track Number8 bits: 0 (disc) or 1–99 (track).
2Sequence Number8 bits: 00h–FFh, for ordering multi-pack text.
3Char. Pos./Block Num.Bits 0–3: position (0–15); bits 4–6: block (0–7); bit 7: double-byte flag.
4–1512 bytes: text (null-terminated) or binary data.
16–17CRC16-bit error check, inverted polynomial result.

Content and Encoding

Text Fields

CD-Text enables the storage of various metadata fields containing textual information about the disc and its tracks, enhancing by providing details such as titles and credits directly from the medium. These fields are organized into categories identified by unique pack type codes ranging from 0x80 to 0x8F, allowing up to 16 distinct field types in total. The core text fields include the title field (0x80), which stores the name for the entire disc or the individual track title; the performers field (0x81), listing the primary or artists associated with the album or track; the songwriters field (0x82), crediting those who wrote the or music for the album or track; the composers field (0x83), identifying the musical composers; and the field (0x87), categorizing the content using predefined codes for musical styles. These fields prioritize essential identification and attribution, forming the foundation of CD-Text metadata commonly displayed on compatible players. Additional fields expand on credits and identification, such as the arrangers field (0x84) for those who arranged ; the field (0x85) for optional notes or dedications per disc or track; the disc identification field (0x86), often containing the media catalog number (MCN) in ASCII format; and the ISRC field (0x8E), holding 12-character Recording Codes for individual tracks or the 13-character UPC/EAN for the disc. These supplementary elements support industry-standard tracking and provide deeper contextual information without overwhelming the primary audio content. Text fields are specified either at the disc level (applicable to the entire , using track number 0) or at the track level (specific to individual ), allowing flexible metadata application across up to 99 tracks. For instance, an album artist might be noted disc-wide in the performers field, while track-specific songwriters could vary per song. This structure is encoded via text packs in the CD's subchannels, with each field potentially spanning multiple packs to accommodate longer entries. Due to the limited space in subchannels, text in each field is constrained to approximately 100-200 characters, varying by whether it is stored in the lead-in area or program area and the number of packs allocated. This capacity ensures concise yet informative entries, such as an album title like "The Dark Side of the Moon" or a track title "Time," while preventing excessive data overhead on the audio sectors.

Character Encoding

CD-Text primarily employs 7-bit for basic English text, which supports the standard Latin alphabet, numerals, and common punctuation marks. This encoding is specified for 0x09 in the pack header, allowing straightforward representation of simple alphanumeric content across various text fields. For broader Western European language support, the format extends to ISO-8859-1 (Latin-1), an 8-bit single-byte encoding that includes accented characters and additional symbols such as , , and . This is the default for most non-Japanese implementations, enabling compatibility with languages like French, German, and Spanish while maintaining with ASCII subsets. The ISO-8859-1 set is implicitly aligned with the single-byte mode, where bit 7 (DBCC) of the Block Number and Character Position Indicator remains unset. Japanese text is accommodated through MS-JIS (Shift-JIS), a variable-width encoding that uses single-byte characters for ASCII compatibility and double-byte sequences for , hiragana, and . This is indicated by 0x69 in the pack header, with double-byte mode activated by setting the DBCC bit to 1; strings in this mode are terminated by two consecutive null bytes rather than one. However, double-byte support is optional and rarely implemented in practice due to ambiguities in the MMC-3 specification, such as inconsistent handling of pack types and device variations that may misinterpret or reject extended characters. The language code in each CD-Text pack's header explicitly determines the active encoding, ensuring that decoders can switch between single-byte (ASCII/ISO-8859-1) and double-byte (Shift-JIS) modes as needed for internationalization. This applies to fields such as track titles (TITL), where the chosen encoding dictates how the 12-byte text payload is interpreted. The encoding mode is further indicated by the DBCC bit. Significant limitations persist in CD-Text encoding, including the absence of full Unicode support, which restricts representation to the aforementioned sets and excludes scripts like Cyrillic, Arabic, or complex East Asian ideographs beyond Japanese. Text exceeding pack limits—typically 12 bytes per pack, with a recommended total under 160 bytes per string—is simply truncated, with no provision for fallback mechanisms or error indication for unsupported characters. These constraints, combined with implementation ambiguities in MMC-3 Annex J, often result in garbled or incomplete display on non-compliant devices.

Compatibility and Usage

Device Support

CD-Text functionality requires devices capable of reading the subchannel Q data encoded on audio CDs, a feature incorporated into many hardware players following its 1996 standardization. Numerous CD players released after 1997 support CD-Text display, enabling users to view metadata such as album titles, artist names, and track titles on integrated displays. For instance, Sony's players, including models like the CDP-CE500 and CDP-C325, retrieve and show this information during playback. Aftermarket car stereos also commonly provide CD-Text compatibility, often displaying text on their interfaces for enhanced while driving. Similarly, certain DVD players maintain for audio CDs and can render CD-Text; Sony's DVP-NS900V series, for example, partially supports this feature when handling CD audio. In software, CD-Text extraction and display rely on /ATAPI interfaces to issue Multi-Media Commands (MMC) for data retrieval, primarily through the READ TOC/PMA/ATIP command with a format specifier for CD-Text pack locations, followed by targeted subchannel reads. tools like Exact Audio Copy (EAC) fully support this process, allowing users to extract CD-Text metadata during secure audio and incorporate it into output files or cue sheets for burning. Media players such as enable reading and displaying CD-Text from inserted discs, integrating it into track information views without additional plugins in recent versions.

Adoption and Limitations

CD-Text saw limited adoption following its introduction in 1996 as an optional extension to the Red Book audio CD standard, primarily driven by , which incorporated it into select commercial releases during the late . Usage peaked around the year 2000 amid the height of physical CD sales, but remained confined to a minority of productions. Key limitations stem from its non-mandatory status in the Red Book specification, allowing manufacturers to omit support without violating core compatibility requirements. Many CD players and drives ignore the Q-subchannel and other subchannels used for CD-Text to reduce production costs and complexity, resulting in inconsistent playback across devices. Additionally, CD-Text data stored in the disc's lead-in area can be vulnerable to physical damage or manufacturing errors, which may render the metadata unreadable while leaving audio intact. Criticisms of CD-Text portray it as a failed attempt at embedded metadata, introduced too late for widespread hardware support and overshadowed by databases like , which identify tracks via timing fingerprints rather than on-disc text. By 2025, its use in new CD productions has become exceedingly rare, supplanted by streaming services that rely on centralized, dynamic metadata ecosystems. As of November 2025, support persists in software like Exact Audio Copy and , and some modern car audio systems, but native integration in mobile OS remains limited.
Add your contribution
Related Hubs
User Avatar
No comments yet.