Subchannel Viewer Example

subchannel_1.gif (10806 bytes)

This screen shot of the Subchannel viewer shows a number of interesting things occurring on this disc.

First, note the columns across the top:

  • Trk = Track Number, 0 to 99
  • Idx = Index Number, 0 to 99
  • CA = 8 bits, Control in left nibble, Address in right
    • Where Control = 4RCE
      • 4: 0 = 2 channel, 1 = 4 channel audio
      • R: 0 = audio, 1 = ROM
      • C: 1 = copyrighted
      • E: 1 = emphasis used in audio recording
    • And Address:
      • 1: ATIME encoded frame
      • 2: frame contains a UPC
      • 3: frame contains an ISRC
      • 5: used only on multisession in Leadin & Leadout areas
  • ATIME = Absolute Time within a disc, 00:00:00 through 99:59:74
  • RTIME = Relative Time within a track
  • CRC = indicates Subchannel CRC error has occurred
  • CU = indicates CU errors in the accompanying mainchannel data (similar to E32's)
  • Additional = shows UPC and ISRC data

The highlighted blue line shows the first subchannel frame of track 8, the line just above it is last frame of track 7. Note that track 8 does not have a pause, i.e. index 0 point. It begins with index 1. Also, we can tell that both tracks are audio from the CA field showing 01 (as opposed to 41 for ROM).

There are two subchannel frames with CRC's, at ATIME 33:34:72 and 33:34:73. Note that when frames have CRC errors, the data being displayed will probably have incorrect digits in it somewhere. When you see the CRC errors, you should look at the good frames before and after the bad frame to determine what the expected data should be.

The subchannel frame at 33:34:73 also has a CU error in the accompanying mainchannel data. This means the C1 and C2 error correction failed to correct the data. This is typically evidence of a media problem, and you'd likely expect to see CRC errors in the neighboring subchannel frames.

We can see the ISRC number for track 8 is USSM19604428. Each subchannel frame can hold either an ATIME, ISRC, or UPC record. So you'll notice at the line where you'd have expected to see ATIME 33:35:08, there is no ATIME information, but instead this subchannel frame was utilized for an ISRC entry. Incidentally, if an ISRC or a UPC exists on a disc, they are required to repeat at least every 100 subchannel frames. Also, ATIME entries must occur at least every 9 out of 10 subchannel frames.

Subchannel Viewer Example 2:

subchannel_2.gif (10748 bytes)

The highlighted blue line indicates where track 1 index 0 becomes track 1 index 1. Notice that the RTIME prior to this point counts down towards 00:00:00, and begins counting back up starting at index 1. Another thing worth noticing is that the RTIME 00:00:00 occurs twice, once at the end of index 0 and again at the start of index 1. This disc follows the Sony RTIME convention. The Philips method would have the last RTIME of index 0 being 00:00:01, and therefore not have the duplicate RTIME 00:00:00.

This disc also has a UPC. As you scrolled through this disc, you'd expect to see the UPC repeat at least every 100 frames.

Subchannel Viewer Example 3:

subchannel_3.gif (14013 bytes)

In version 1.20 the subchannel viewer was enhanced to also display the RW and Pflag information. While all discs are supposed to use the PFlag, RW is only used in CD+G, CD+Midi, and CD-Text discs.

The presence of RW data is evident in this display. In the upper display window, the RW column shows that there is RW data beginning at ATIME 00:02:20. The lower display window (titled "RSTUVW") shows the four packets of RW data for the ATIME highlighted by the blue line in the upper display window. You can see that packets 1 and 2 are all zero - which means they don't contain any RW data, but packets 3 and 4 do show actual RW data. If the ECC bytes for each packet are displayed in the "Parity Q" and "Parity P" columns. If an uncorrectable packet exists, it would be indicated with a "(bad)" immediately after the packet number, and the upper display would have "RWERR" in the RW column.

Also, version 1.20 added a field to display the Pflag. This flag pulses high at track changes. In the above example, since there is no track change, there is also no PFlag activity. The Red Book spec states that the Pflag should go high prior to index 1 of each track, for two seconds or the length of the index 0 region, whichever is longer.