CDGFix.gif


The CDG graphics format

If you are using CDGFix 3 Super for CDG ripping, file format conversion, maintaining SuperCDG and other tasks not involving manipulating the graphics of your tracks you do not need to worry about the contents of this topic. On the other hand if you are going to fix graphics errors, change colors, replace pictures, and do other graphics manipulation, then an understanding of the CDG instruction format is of great help. Below you will find essential information to help you understand the instruction set and why the graphics of a given track appear the way it does.

 

Overview

The CDG canvas

Timing

Colortable

Channels

The CDG instruction set

Invalid instruction packets

Possibly lost instruction packets

Color cycling

Limitations in the CDGFix 3 Super implementation of the CDG instruction set

Variations on the CDG storage format

 

Overview

The CDG instruction stream is stored on a CDG disc in areas known as subcode channels R-W. On a normal audio CD these channels are not used. The CD format defined by the "Red Book" defines different ways of utilizing this empty space, one of which is the CDG format.

Each CDG instruction is stored in a packet of 24 bytes. Some of these bytes define the instruction and parameters, while other bytes are used for error detection and correction. Each packet has a header consisting of a command byte and an instruction byte. The command byte signals the type of packet, for example a CDG instruction packet. In case of a CDG instruction packet the instruction byte defines the actual CDG instruction. The content and meaning of the remaining bytes depend on the specific CDG instruction contained by the packet.

Empty packets, i.e. packets without a CDG instruction, are known as timing packets and are used to make the graphics play in sync with the music.

 

The CDG canvas

The CDG canvas (the graphics area displayed on the screen) consists of a grid made up of 18 rows by 50 columns. Each cell in this grid contains a pixel map of 12 rows by 6 columns, making the canvas being 192 pixels high and 288 pixels wide. The Tile Block Normal and Tile Block XOR instructions can fill a single cell, hence a minimum of 900 instructions (or 3 seconds) are required to paint the entire canvas.

The outer most cells in the canvas grid (i.e. rows 0 and 17, and columns 0 and 49 - also known as the border) are normally not visible during playback. These cells are used to create graphics that can be scrolled into view by the Scroll Preset and Scroll Copy instructions. CDGFix 3 Super can however display the border cells as well for editing purposes (refer to the Border command on the View menu).

 

Timing

The timing of the CDG instructions are essential to make the graphics - i.e. lyrics and sweep - appear in sync with the music. The CDG storage format and packet size dictates that the CDG stream should play at a rate of 300 packets per second. In other words a single CDG packet occupies 1/300th of a second on the time line. As an example, if the lyrics has to wait for 4 seconds before continuing to stay in sync with the music, the CDG stream will contain 1200 timing packets.

If a track has out-of-sync graphics and music this can be corrected by inserting or removing timing packets from the CDG stream. If the graphics starts to early timing packets can be inserted at the beginning of the track, while graphics that starts to late can be adjusted by removing a number of timing packets at the beginning of the track. Likewise out-of-sync problems that occur later in the song can be fixed by removing or inserting timing packets at the correct locations.

As a tool to assist in synchronizing the graphics and the music the Timeline dialog can be used. This dialog is invoked by the Timeline command on the Tools menu.

 

Colortable

The CDG format colortable has 16 entries, each defining a color using RGB values of four bits each. Each colortable entry can thus select from a palette with a total of 4095 different colors. The 16 available colors are addressed by the CDG instructions by an index in the range 0 to 15. The colortable itself is built by the CDG instructions Load Color Table Low and Load Color Table High.

 

Channels

Some of the CDG instructions (specifically the Tile Block XOR and Tile Block Normal instructions) belongs to a given channel. The CDG format supports a total of 16 channels, numbered from 0 to 15. Most available tracks play on channels 0 and/or 4.

By utilizing the channel concept it is possible to create tracks that can display different lyrics depending on the channels selected for playback. CDGFix support channel selection through the Channels menu. This menu allows for switching individual channels on and off, as well as turning all on or all off.

A male/female duet may be created with the male lyrics on channel 1 and the female lyrics on channel 2. By default CDGFix has all channels on and will hence display both lyrics. However, turning off channel 1 results in only the female lyrics being displayed, while turning off channel 2 will display the male lyrics only. Some tracks may also contain different translations of the lyrics on separate channels, giving the singer the choice of singing in English or French, for example.

 

The CDG instruction set

The CDG instruction set consists of nine instructions. The following displays each instruction with parameters.

Memory Preset

Instruction arguments:

Color

- Color index to clear canvas (0..15)

Repeat

- Repeat count (0..15)

 

This instruction clears the CDG canvas by setting all pixels of each cell (including the canvas border cells) to the color specified by the Color argument. Normally the Memory Preset occurs in sequences of sixteen consecutive packets with a repeat count from 0 to 15. This is to make sure the instruction is recognized and executed even when reading from a media with a higher fault tolerance.

Border Preset

Instruction arguments:

Color

- Color index to clear the canvas border (0..15)

 

This instruction clears the CDG canvas' border cells by setting all pixels of the border cells to the color specified by the Color argument. By first issuing a Memory Preset instruction followed by a Border Preset instruction, the border and the rest of the canvas can be initialized to different colors.

Load Color Table Low

Instruction arguments:

Colors 0..7

- RGB values for the low order eight colors of the colortable.

 

The Load Color Table Low instruction loads new color RGB values into the colortable's eight low order indexes. The RGB values for color indexes are packed as a sequential stream of 96 bits, 12 bits for each color. When the colortable has been updated with the new RGB values each pixel in the CDG canvas are refreshed according to it's color index.

Load Color Table High

Instruction arguments:

Colors 8..15

- RGB values for the high order eight colors of the colortable.

 

The Load Color Table High instruction loads new color RGB values into the colortable's eight high order indexes. The RGB values for color indexes are packed as a sequential stream of 96 bits, 12 bits for each color. When the colortable has been updated with the new RGB values each pixel in the CDG canvas are refreshed according to it's color index.

Tile Block Normal

Instruction arguments:

Channel

- Channel number (0..15)

BColor

- Background color index (0..15)

FColor

- Foreground color index (0..15)

Row

- CDG canvas row index (0..17)

Column

- CDG canvas column index (0..49)

Pixels

- 6 by 12 pixels matrix to fill the selected cell, one bit for each pixel

 

This instruction fills teh CDG canvas cell identified by the Row and Column arguments with the 6 by 12 pixel graphics. Each pixel that has the corresponding bit cleared (0) in the Pixels argument are assigned the color identified by the BColor argument, while each pixel that is set (1) is assigned the color FColor.

The Channel argument dictates whether the Tile Block instruction is executed or not. If the identified channel is active (controlled by the Channels menu) the instruction is executed, otherwise not. An explanation of the channels concept are found at Channels.

Tile Block XOR

Instruction arguments:

Channel

- Channel number (0..15)

BColor

- Background color index (0..15)

FColor

- Foreground color index (0..15)

Row

- CDG canvas row index (0..17)

Column

- CDG canvas column index (0..49)

Pixels

- 6 by 12 pixels matrix to fill the selected cell, one bit for each pixel

 

The Tile Block XOR instruction executes in exactly the same way as the Tile Block Normal instruction, except for how colors are applied to the cell pixels. While the Tile Block Normal instruction writes the new color indexes directly into the cell pixels, the Tile Block XOR instruction result in the existing color index for each cell pixel being xor'ed with the new color index. The resulting color index from the xor operation is then written back into the cell pixels.

Scroll Preset

Instruction arguments:

Color

- Color index to preset border (0..15)

HShift

- Horizontal shift (0 = no horizontal shift, 1 = shift all columns right, 2 = shift all columns left)

XOffset

- Horizontal pixel offset (0..5)

VShift

- Vertical shift (0 = no vertical shift, 1 = shift all rows down, 2 = shift all rows up)

VOffset

- Vertical pixel offset (0..11)

 

This instruction shifts the CDG canvas left/right and/or up/down, making the graphics appear as moving across the screen. Cells that are shifted out of the CDG canvas at the edges (as defined by the HShift and VShift arguments) are lost, and cells that are shifted in from the opposite edges are filled with the color specified by the Color argument. In addition to shifting cells sideways and up/down, the XOffset and YOffset arguments can be used to offset the display of the CDG canvas by the specified number of pixels to the left and up, respectively.

For example, to scroll the graphics smoothly upwards (like the end titles of a movie), you would use 12 consecutive scroll instructions for each row (remember that each row is 12 pixels high). The 11 first scroll instructions will have VShift=0 and VOffset running from 1 to 11, making the CDG canvas move upwards one pixel for each scroll instruction. The final scroll instruction will have VShift=2 and VOffset=0, resulting in all rows be shifted one position upwards while resetting the CDG canvas display to offset 0 (the default). Then the same sequence is repeated for each new row you want to scroll up.

Given the data rate of the CDG stream one cycle of 12 scroll instructions will execute in 12/300th of a second, so you may want to use a number of timing packets between each scroll instruction to slow down the scrolling to the required speed. The packets between the scroll instructions are more typically used to paint new graphics in the border area. Since the border (by default) is invisible during playback it will appear as new graphics are scrolled into view from one edge while scrolled out of view at the opposite edge.

Scroll Copy

Instruction arguments:

HShift

- Horizontal shift (0 = no horizontal shift, 1 = shift all columns right, 2 = shift all columns left)

XOffset

- Horizontal pixel offset (0..5)

VShift

- Vertical shift (0 = no vertical shift, 1 = shift all rows down, 2 = shift all rows up)

VOffset

- Vertical pixel offset (0..11)

 

The Scroll Copy instruction operates in exactly the same way as the Scroll Preset instruction, with one exception; the cells that are shifted out of view at one edge are not lost, but instead shifted back into view from the opposite edge. Hence there are no Color argument since no cells have to be initialized to a fixed color.

Define Color Transparency

Instruction arguments:

Transp(0..15)

- Transparency factor for each of the 16 colors (0..63)

 

Transparency is defined by a value ranging from 0 to 63, 0 being completely opaque and 63 being completely transparent. This instruction defines an individual transparency level for each of the 16 color indexes. When a given color index has a transparency level higher than 0, all pixels with that color index in the CDG canvas be more or less "see-trough" depending on the transparency level. As pixels become more transparent the background image becomes more visible through these pixels (please refer to the Background page of the Settings dialog for details on defining background images).

CDGFix 3 Super has a simplified transparency implementation due to limitations in the graphics engine. Refer to Limitations in the CDGFix 3 Super implementation of the CDG instruction set for details.

 

Invalid instruction packets

When a packet that has a command byte signalling that the packet is a CDG instruction packet, but the instruction byte is not a known CDG instruction code, the packet is said to be a Invalid instruction packet. Such a packet can for obvious reasons not be executed, but it still shows up in the Instructions window by default. The latter can be changed using the Filter Packets submenu of the View main menu.

The reason for these kind of packets to show in the Instructions window is that they may be vital for the CDG file in question, but a bad ripping or data transfer has corrupted the CDG instruction code. By examining the packet arguments using the HEX Editor it may be possible to determine whether the packet is an instruction packet and if so, which CDG instruction code it actually should have. To assign the packet any given CDG instruction code use the Change Instruction command on the Tools menu, while using the Remove Instruction command on the same menu to flag the packet as a non-CDG instruction packet.

 

Possibly lost instruction packets

A Possibly lost instruction packet is the opposite of an Invalid instruction packet in that this type of packet has a valid CDG instruction code, but the command code does not flag the packet as a CDG instruction packet. These kind of packets are by default not displayed in the Instruction window, but can be revealed by using the same Filter Packets commands as mentioned above. If the graphics seem to be "missing" pixels or otherwise are corrupt it may be a good idea to turn on display of these packets to see whether there are some in the area where the graphics are incorrect. When a Possibly lost instruction packet is identified as actually being a valid CDG instruction packet it can be flagged as such by using the Recover Instruction command on the Tools menu.

 

Color cycling

Some brands of CDG tracks use Color cycling to create visual effects, for example in the title screen of the track. This is achieved by first creating the graphics as usual with the Tile Block Normal and Tile Block XOR instructions. Then a sequence of consecutive Load Color Table Low and Load Color Table High instructions is initiated. As each Load Color Table instruction defines new RGB values for the colortable the pixels in the CDG canvas are repainted accordingly, creating a visual effect. Depending on how the RGB values are changed the visual effect appears smooth or dramatic.

Using the same technique it is possible to create a fade in effect. Initially set all colortable entries to black and then create the graphics. Then start applying Load Color Table instructions that gradually move the RGB values in the direction of the final picture colors. A fade out effect is achieved in the same way by starting with full RGB values and gradually changing them towards black.

Like the Scroll Preset and Scroll Copy instructions the Load Color Table instructions each execute in 1/300th of a second. Color cycling at this speed would only be annoying, hence the insertion of an appropriate number of timing packets between each Load Color Table Low/High instruction pair is applied to achieve the desired speed.

 

Limitations in the CDGFix 3 Super implementation of the CDG instruction set

While the Define Color Transparency instruction dictates that each of the 16 colortable entries can have it's own transparency level ranging from 0 to 63 (full opacity and full transparency, respectively), CDGFix 3 Super is limited to defining only a single colortable index as transparent. In addition the CDGFix 3 Super graphics engine only allows a color to be completely opaque or completely transparent, no gradients in between. This is due to the fact that the CDGFix 3 Super graphics engine is based on Microsoft Windows functionality only, independent of other software like DirectX or the like.

CDGFix 3 Super handles the Define Color Transparency instruction by first scanning the 16 transparency levels to find the color index with the highest level. If two or more color indexes have the same transparency value the lowest color index is chosen. Then, if the transparency level for the selected color index is equal to or higher  than 32 that color index is defined as fully transparent. Otherwise all color indexes are reset to completely opaque.

While this at first glance might seem like a big limitation it is actually not. While most CDG brands does not use transparency at all, the ones that do normally does it very simple. A single color index is defined as completely transparent to allow a background picture or video to be visible through selected parts of the graphics, hence matching the CDGFix 3 Super implementation exactly.

 

Variations on the CDG storage format

Extended CD Graphics

The "Red Book" defines an extended version of the more common CDG format, known as Extended CD Graphics. In short this format supports the use of a 8-bit colortable where each color can be chosen from a palette with a total of 262144 colors. This in contrast to the 4-bit colortable with a palette of 4096 colors for the standard CDG format.

The 8-bit colortable of the extended format can either be used for a single picture memory, resulting in graphics with 256 available colors. Alternatively the picture memory can be divided in two, resulting in two separate pictures each with a 4-bit (16 colors) colortable. The latter usage supports graphics effects such as cut and dissolve between the two pictures.

The organization of the extended CD graphics data stream is backwards compatible, meaning that decoders that know the extended format will display the enhanced graphics with the effects used. However, when played on a player that only supports the standard CD graphics implementation, the graphics will gracefully degrade to a 4-bit colortable with a palette of 4096 colors.

CDGFix 3 Super only supports the standard CD graphics format.

 

CAVS CDG

Normally CDG data is stored in files with the extension CDG. However, CAVS has it's own file format with the same filename extension. These two formats are not compatible with each other and requires different readers and writers. While the standard CDG file format uses a record length of 24 bytes that fit the CDG packet layout on a CDG disc, the CAVS version of the format has a record length of 16 bytes. The CAVS CDG file format also uses other CDG instruction code values than the standard format, and has a different instruction argument values layout.

CDGFix 3 Super handles both the CDG file formats, and is able to recognize which format a given CDG file holds.

 

CAVS MCG

The CAVS MCG format is a variation on the CAVS CDG format. Again the CDG instruction code values have been changed, and the instruction argument values layout has been changed.

Another feature of the CAVS CDG and MCG formats is that they don't store timing packets, making the files considerably smaller than their standard CDG format counterparts. The timing is instead achieved by using two bytes of each record to indicate at which point in time the instruction should play.

A limitation of same two formats is that they don't support the Define Color Transparency instruction, making the CAVS formats unsuitable for CDG tracks that use color transparency to view a background picture or video while playing.

 

CAVS NCG

A third CAVS variation is the NCG format. This format is an encrypted version of either a CAVS CDG or MCG file. The NCG format is used on the CAVS JB-199 players. When registering CAVS CDG and/or MCG files to play on a JB-199 they are encrypted with a keyset unique to the JB-199 in use, effectively making the tracks unusable on other hardware and software players (both from CAVS and other manufacturers).

CDGFix 3 Super, however, are capable of decrypting NCG files and restoring the original CAVS CDG or MCG file, as well as converting directly to another supported format, such as standard CDG, ZIP, BIN or SuperCDG. The decryption of NCG files requires that the keyset used for encryption is detected first, a process that is supported directly by CDGFix 3 Super. Read more here: Convert encrypted NCG files