[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

[Libcdio-devel] proposed documentation for pregap interface

From: Robert William Fuller
Subject: [Libcdio-devel] proposed documentation for pregap interface
Date: Wed, 12 Mar 2008 01:03:22 -0400
User-agent: Thunderbird (X11/20071013)

Let me know what you think. I haven't put it in texi, yet, but here is the text:

6.3 CD-DA discs and gaps

Gaps are possibly one of the least understood topics in audio discs. In the case of CD-DA discs, standards only require a silent 2 second gap before the first audio track and after the last audio track. These are respectively referred to as lead-in and lead-out gaps. Many CD's, especially live CD's, lack silent gaps between the audio tracks, instead playing music continuously. Although these discs lack silent gaps, they may have gaps containing audio, or lack gaps altogether. Nonetheless, they conform to the CD-DA standards.

In order to understand gaps between audio tracks, it is necessary to understand how CD players display the track and time. Embedded in each block of audio data is non-audio information known as the Q sub-channel. The Q sub-channel tells the CD player what track number and time it should display while it is playing the containing block of audio data. Near the end of some tracks, the Q sub-channel may instruct the CD player to update the track number to the next track, and display a count down to the next track, often starting at -2 seconds and proceeding to zero. This is known as an audio track pre-gap. It may either contain silence, or sometimes in the case of live CD's, it may contain audio. Almost as often as not, there is no pre-gap whatsoever. Regardless, an audio track pre-gap is purely determined by the contents of the Q sub-channel, which is embedded in each audio sector.

When the track forward button is pressed on a CD player, the CD player advances to the next track, skipping that track's pre-gap. This is because the CD player uses the starting address of the track from the disc's table of contents (TOC) to determine where to start playing a track when either the track forward or track backward buttons are pressed. So to hear a pre-gap for track 4, the user must either listen to track 3 first, or use the track forward or reverse buttons to go to track 4, then use the seek backward button to back up into track 4's pre-gap, which is really part of track 3, at least according to the TOC. Track 1 pre-gaps are especially interesting because some commercial discs have audio hidden before the beginning of the first track! The only way to hear this hidden audio with a standard player is to use the seek backward button as soon as track 1 begins playing!

Audio track pre-gaps may be specified in a couple of different ways in the popular cue file format. The first way of specifying a pre-gap is to use the "PREGAP" command. This will place a pre-gap containing silence before a track. The second way of specifying a pre-gap is to give a track an "INDEX 00" as well as the more normal "INDEX 01". "INDEX 01" will be used to specify the start of the track in the disc's TOC, while "INDEX 00" will be used to specify the start of the track's pre-gap as recorded in the Q sub-channel. "INDEX 00" is ordinarily used for specifying track pre-gaps that contain audio rather than silence. Thus, the cue file format may be used to specify track pre-gaps with silence or audio, depending on whether the "PREGAP" or "INDEX 00" commands are specified. If neither type of pre-gap is specified for a track, no pre-gap is created for that track, which merely means the absence of pre-gap information in the Q sub-channel.

Various CD-DA ripping programs take various approaches to track pre-gaps. Some ripping programs ignore track pre-gaps altogether, relying solely on the disc's TOC to determine where tracks begin and end. If a disc is ripped with such a program, then re-burned later, the resulting disc will lack the odd playback behavior of sometimes counting down to the next track. Other ripping programs detect track pre-gaps and record them in the popular cue file format among others. Such ripping programs sometimes allow the user to determine whether track pre-gaps will be appended to the prior track or pre-pended to the track to which they "belong". Note that if a ripping program is ignorant of track pre-gaps, the track pre-gaps will be appended to the prior track, because that is where the disc's TOC puts them. Consequently, libcdio does not dictate the policy a ripping program should use in dealing with track pre-gaps. Hence, libcdio provides the cdio_get_track_pregap_[lba|lsn] interfaces to allow the application to deal with track pre-gaps as it sees fit.

Note that the cdio_get_track_pregap_[lba|lsn] interfaces currently only provide information for bin/cue and NRG images. (CDRDAO support will be added either when needed by the author or requested by someone offering the author a free beer.) Getting the track pre-gaps from a CD drive is a more complicated problem because not all CD drives support reading the Q sub-channel DIRECTLY at HIGH speed, and there is no interface to determine whether or not a drive supports this optional feature, aside from trying to read the Q sub-channel, and possibly incurring IO errors. However, all drives DO support reading the Q sub-channel INDIRECTLY while playing an audio disc by asking the drive for the current position. Unfortunately, this occurs at normal playback speed, and requires a certain settling time after the disc starts playing. Thus, using this SLOW interface requires a more sophisticated algorithm, such as binary search or some heuristic, like backing up progressively from the end of the prior track to look for the next track's pre-gap. Note that CD drives seek slowly, so it is better to simply use a drive that can read the Q sub-channel directly at HIGH speed, and avoid complicated software solutions. (Not to mention that if the user has an older system with an analog audio cable hooked up between their soundboard and their drive, and a ripping program uses the SLOW interface, the user will hear bits of the audio on the disc!) Consequently, because there is no good universal solution to the problem of reading the Q sub-channel from a drive, libcdio currently leaves this problem up to the application, a problem which is readily approachable through either libcdio's MMC interface or libcdio's cdda interface. For an example of one such application, see

reply via email to

[Prev in Thread] Current Thread [Next in Thread]