CD tracks that have pre-gap audio

, , , ,
1

Continuing the discussion from Releases with multiple DiscIDs:

The only time you should have to manually scan backwards from 0:00 to play pre-gap audio is when the audio is placed in the pre-gap of track 1. Any audio placed in the pre-gap of track n+1 should play after track n has finished. This presumes that you are playing the CD in sequential order (track n then track n+1 then track n+2, etc.), if you are using a randomize/shuffle mode then the pre-gap audio will probably not be played (behaviour might differ depending on the model of CD player).

3 Likes
2

What you say contradicts the mentioned Wikipedia article. But anyway, there has to be a gap in the TOC too. Or is it added to the preceding track n?

3

IIRC, the TOC only contains the start point of each track, not the end point (where the “start” means the position of index 01). So the length of track n in the TOC will extend to the start of track n+1 (index 01), and therefore include the length of the track n+1 pre-gap (index 00).

3 Likes
4

That Wikipedia says:

After track 3, 7 and 9 there is a short jam (lasting between 0:35 and 1:30; altogether 3:39) which can be accessed directly by rewinding from tracks 4, 8, and 10 respectively.

But it can also be accessed, not directly, by just letting your CD play tracks from track 3, without using the next track button nor the digit (jump to track) buttons of your CD player.

It’s the index 00 of track 4 that is played between tracks 3 and 4 with a countdown display. *
It will only play if you let the transition between 3 and 4 play continuously. Any skip I described above (digits, previous, next) will jump to index 01 of tracks.

As @Kid_Devine said.

* You should be able to see that with almost any of your CD, many CD have a 2 second silence between each index 00 and 01 of many tracks. So you should see a countdown of -01:59 to 00:00 before the song starts.

2 Likes
5

As the owner of this CD, bought in 1996, does anyone know how I can setup EAC to get it to rip that pre-gap audio track before Track 1?

When I ripped the CD a few years ago I forgot about these extras. The TOC in the EAC log looks like this:

 Track |   Start  |  Length  | Start sector | End sector 
---------------------------------------------------------
    1  |  2:40.07 |  3:51.50 |     12007    |    29381   
    2  |  6:31.57 |  3:51.48 |     29382    |    46754   
    3  | 10:23.30 |  5:04.12 |     46755    |    69566   
    4  | 15:27.42 |  5:59.60 |     69567    |    96551   
    5  | 21:27.27 |  3:27.28 |     96552    |   112104   
    6  | 24:54.55 |  4:13.32 |    112105    |   131111   
    7  | 29:08.12 |  5:11.13 |    131112    |   154449   
    8  | 34:19.25 |  4:31.62 |    154450    |   174836   
    9  | 38:51.12 |  3:14.50 |    174837    |   189436   
   10  | 42:05.62 |  3:50.28 |    189437    |   206714   
   11  | 45:56.15 |  4:18.00 |    206715    |   226064

There is that 2:40 track clearly shown in the TOC, but EAC ignored it. All the other hidden audio bits were ripped and added to the end of the previous tracks.

The quoted length of tracks 3, 7 and 9 in the above TOC are the combined length of the actual track plus the jam. This matches the track list for this MBID as shown with the track name / [unknown] (This matches the Wikipedia quote of “which can be accessed directly by rewinding from tracks 4, 8, and 10 respectively”)

6

I overlooked the word directly. It’s not like the pregap of track 1 which can only be accessed by rewinding from index 1. And it will be part of the preceding track when ripped by standard software. So you would not know about from reading the TOC. You actually have to listen to it.
I think I’ve understood now. There’s no use of looking for gaps between tracks.

1 Like
7

It’s been a few years since I used EAC, but I recall that there was just a configuration option, a check-box on some menu, you could set. There’s also settings for where to put the pre-gaps. The default is to attach them to the end of the “Previous” track. I think, since there’s no “Track 0” to append the Track 1 pre-gap to, you just need to extract all the pre-gaps as their own WAV files, rather than just appending them to the track before or after.

I don’t remember if EAC has a DAO ripping mode, but if so, the hidden pre-gap audio will be the very first thing in the data file. (If you’re using “cdrdao” on Linux or something it’ll do this too.)

CDs are kinda non-deterministic… It’s difficult to predict how two different players will interpret the media…

So… brief summary of “Red Book Compact Disc Digital Audio”… The CD format was designed in the 1970s before the widespread availability of cheep microprocessors. So you don’t need a computer of any kind of play a CD. So, audio CDs are structured like a simplex radio broadcast… or like a tape. There’s no concept of any organizational structure, like sectors, or an absolute position. There’s a lead-in and lead-out area (two seconds of alternating bits), at the beginning an end of the disk, so the player knows about where to start, stop, and when it has seeked out too far. And everything in between is just a bunch of ones and zeros you pump into your DAC. (With a bit of 14-bit to 8-bit and Reed-Solomon decoding, same as they were already using for satellite broadcasts in the 1970s).

Early CD players were not really designed to do random seeking when the user presses a button… According to the Red Book spec, the player only need to seek to about 2 seconds within wherever it is actually trying to seek to. That’s why a Red Book compliant CD must have 2 seconds of “pre gap” between each track. Early players would commonly ‘miss’ when you tell them to reposition their laser. The pre-gap has an extremely obvious bit pattern in the P subcode, which is how the player knows that it’s in the pre-gap, and not in the regular audio portion. The player mutes its audio while trying to locate the next track, skipping ahead a bunch, and the then checking if it’s in a pre-gap or not…

Because the CD player, has no brains, and is just looking around for various sync marks to know where it is. Like a vinyl record, if you drop the laser on a random spot of the disk, it’ll read until it successfully decodes a frame without error, and then spews it out of a digital audio converter. This is also why CDs can ‘skip’, and the audio drops out for a fraction of a second, and then the player is suddenly somewhere else. (The physical “groove” of lands and pits the laser is reading has a slight wobble to help the player with tracking, which is another elaborately engineered thing you don’t need to use a computer for.)

Some players (like my first CD player) had a mode where they would automatically pause between tracks too. They look for the pre-gap to know when to do this. They don’t need to memorize a TOC or anything. All of what they need to know is encoded right there were they are currently reading from. Computer memory is expensive.

For convenience, Red Book CDs also have a “Table of Contents”, which most players read and use these days… (But it’s not actually “necessary” you can build a player that just works like an analog record player, or tape player, which starts at the beginning, and plays to the end, and you can fast forward.) It’s an array of up to 99 tracks and 99 index marks. (Index marks are what everybody was going to use to skip around within a track, because players were too dumb to make seek arbiltrarilly.)

You can point the track offsets at any arbitrary location, even off the end of the disc, but most players are smart enough to stop at the lead-out. The actual audio program only really has three pieces of information in it:

  1. Is this frame part of a pre-gap, or not part of a pre-gap?
  2. The timestamp to display to the user. (Early CD players didn’t even have their own clock.)
  3. A fraction of a second of PCM encoded audio.

And that’s it. The whole 2352 byte sector thing is a kludge added with the “Yellow Book” data “CD-ROM” stuff. Those sectors don’t really align with any absolute position of anything on a Red Book CD.
Every player gets to arbiltrarilly decide for itself where sector 0 will be. Most of the time it’s within a few hundred samples past the end of the lead-in, depending on whatever amount of time it takes for the player to think about things as the disc keep spinning. (Actually, I’m not sure about this part exactly, it might also just be that the player shifts the “sector” boundaries around depending to line up with the beginning of the tick of a frame in the Q-subcode, or the end… or somewhere in the middle.) (CD-ROMs have explicitly defined sectors, CDDA doesn’t.)

Index 0, is the mandatory two second long pre-gap, and index 1 is the beginning of the audio program, Indexes 2-99 can be set anywhere within the auditory part of the track. In practice, these were rarely ever used.

Every track has a pre-gap… even track 1… anyway, you know this part.

Most players will just start playing at the good part, track 1 index 1

Anyway, so don’t think of a CD as being like a hard disk, think of a CD as being like a broadcast television signal, with the video made up of a bunch of black and white dots… Because that is actually in fact exactly what it is. All of the CDs in the 1970s and 1980s were recorded onto video tape, because nobody had 800MB hard drives until the mid 90’s.

If you lived near Boston in the 1980s, WGBX would sometimes broadcast classical music, with the video being a bunch of randomly blinking black and white squares. At the time, I didn’t really know what this was, but it turns out that Sony used to sell a TV set top box to consumers, that would decode a television signal like this and spit out “CD Quality” audio for your hi-fi sound system… or whatever. Anyway, record studios and CD pressing plants used the same thing for mastering CDs.

For being a “digital” format, it almost isn’t…

Remember video LaserDiscs? Those are literally just an analog, pulse width modulated, 6MHz FM, composite NTSC television signal. You don’t need a computer to read them either. Compact Disc Audio was an upgrade of this that skipped the whole FM encoding step in the middle, and using PCM rather than PWM.

I got distracted and I forgot the point I was going to make… Basically, if CDs seems weird and don’t make any sense, this is why.

5 Likes
8

Oh yeah, the current track number, current index number, current absolute time from the “beginning” of the audio program, and relative time from the start (index 1) of the current track; are all encoded in the Q-subcode. Everything the player knows is right there in front of it, there’s no other state to keep track of…

So, you can play some hilarious tricks on various CD players/CD-ROM drives. A bunch of them were used for copy protection rather than for artistic purposes.

Ugh, I remembered why I brought this up, and now I’ve forgotten it again. (I should probably just get some sleep.)

I was planning on building a something like a KryoFlux, but for optical media, someday… If you were wondering… After ripping thousands of CDs, with a bunch of different drives, and a bunch of different software, I’ve discovered that there is no single combination of parts that will rip CDs “perfectly”. (Most of them get things about 99.9% right, so if you use multiple programs with multiple drives, you can combine the results and get 100%. I have an unfinished program I wrote to do some of this, but my life got busy and complicated, so I haven’t worked on it for years.

2 Likes
9

Here’s one method for ripping pre-gap audio from track 1 (aka HTOA) using EAC:

  1. Deselect all the tracks except track 1
  2. Go to Action > Copy Selected Tracks Index-Based
  3. Select either Uncompressed or Compressed depending on your preference
  4. After it’s done ripping you should have two files named something like:
    a) 01.00 Track01.wav (This is the HTOA)
    b) 01.01 Track01.wav (This is the track 1 audio)
3 Likes
10

Also, to save time, if you still have all of the logs from when you previously ripped all the CDs, you can find just the few CDs to re-rip by searching the logs for any Track 1’s which begin at a sector higher than 150.

( 150 ÷ 75 frames/second = 2 seconds of pre-gap )

1 Like
11

I remembered the point I was going to make, tying back into the original thread this one forked off of…

Why are so many CDs of the the exact same release, slightly different? How can there be so many DiscIDs?

Back in the days before you could easily upload 750MB of data to a CD manufacturing plant, or mail them DDP files on a DVD-R or DLT tape… even back before DAT tapes had been invented. Sony and Philips required that all CD manufacturing plants (there were only really three on Earth at the time…) accept digital audio on 3/4-inch U-Matic video tapes, which were a black and white (luma only) PAL or NTSC video signal. (Technically not NTSC because I think NTSC is only color, but it’s NTSC without the color burst, so it’s exactly 60fps, not 59.94fps.)

I believe that a SMPTE timecode was also a requirement on the U-Matic tapes, but I’m not sure if that timecode is the exact same one used when the CD is encoded. I had a look through ECMA-130 (which is the CD-ROM spec, not CDDA), and it seems that the timecode in the Q-subchannel is added around when the PCM samples are run through the CIRC encoder.

Anyway, so I haven’t actually done the research on this part, but I don’t think the TOC information was on the U-Matic tape. DDP wasn’t created until 1988… So, I think the TOC information was just written on a piece of paper, and someone at the CD manufacturing plant types it into the computer running the laser engraving machine.

In the early days of CDs, people thought of them as more like small vinyl records, rather than as “data”. And so everything about their initial design and manufacture is based in this context.

(Vinyl records were already being mastered from PCM audio stored on 2-inch Quadruplex videotape in the early 1970’s.)

Anyway, so I don’t have very many duplicate CDs in my collection, but I’ve compared a few pairs of releases which are digitally different (but auditorily identical), and mostly what I found was that the PCM audio data had just moved to a different byte offset between the two releases… So, one release will have an extra 73 samples of silence (1176 null bytes) at the beginning of Track 1 (index 1)

And you may ask, why does the second pressing of the CD now have an extra 10 to 30 milliseconds of silence at the beginning?

I can only speculate…

Maybe rather than master the second release from the U-Matic tape again, they just used the first released CD as the master? Maybe they used a different engraving machine that’s just 15ms slower at processing stuff, or maybe it has a programming error? Maybe a decimal point got rounded off somewhere. Maybe something trims or adds silence to the ends?

There is no explicit “start” signal, or addresses… It’s just a continuous stream of PCM audio and an SMPTE timecode, with a maximum temporal resolution of 0.013 second.

So, I looked up ECMA-130 to refresh my memory… I forgot that due the the amount of error correction that CDs use, they tolerate a ridiculous amount of manufacturing defects… (And yet, I still have some unplayable CDs with bubbles in the aluminum layer, but anyway…) (Gotta keep manufacturing costs down below US$0.01 per disc!)

In the 1980’s CDs were also still really expensive to make, and the record companies had no idea if anyone would buy them, so they were probably only doing short manufacturing runs so they wouldn’t be stuck with a bunch of unsellable CDs in a warehouse somewhere. So, for popular stuff, I speculate they were probably manufacturing a new batch when the previous one sold out, and this happened a lot for very popular CDs. Also there’s usually dozens of record licensing, distribution, and production companies, and it’s conceivable that several companies would, independently of each other, be manufacturing the “same” CDs for sale.

Anyway, technical stuff… The Table Of Contents (TOC) is stored in Q-Subcode of the Lead-In Area, which is explicitly encoded as actual “Track 0”. It’s a list, structured very similarly to the timecode info stored literally everywhere else all over the entire CD, except it’s not info about the present frame at all, but a track number, an absolute timestamp of where Index 1 of that that begins. (It points to the end of the pre-gap.) up to 98 more track numbers, just like this… the total number of tracks on the CD… both a beginning and ending track number? (This must be some XA Mode 2 thing?) and the start of the Lead-Out at the end of the audio program… in MM:SS:fff format.

Index marks are not stored in the TOC. You really do need to extract the Q-subcode from every frame on the entire CD to find them.

And the TOC only points to Index 1 of each track.

And the spec explicitly says this really only has about ±1 second of accuracy of positioning. Hence why pre-gaps are 2 seconds wide.

Fun reading:

https://www.ecma-international.org/publications/files/ECMA-ST/Ecma-130.pdf

These three fields are part of the q-channel (see 22.3.3.5) of a Section (see clause 18) that comes out of the 8-to-14 encoder at the moment at which the Sync of the Sector enters the scrambler. The time in the Header shall be given with an accuracy of ± 1 s (see clause 21). This tolerance takes care of the delay caused by the CIRC (see annex C) and possibly other storage registers. The length of these delays is of the order of 30 ms, i.e. the recording length of one Sector on the disk.

And then later on…

21 Addressing system in the Information Area

The address of a Section of an Information Track on the disk is given as the elapsed time from the start of the User Data Area to that Section. This time is recorded in the Control bytes of each Section, and is called absolute time. It is given with a resolution of 1/75 of a second. The time is given for a data rate from the disk of 4,321 8 x 106 Channel bits per second. This amounts to exactly 75 Sections per second.

The address of a Sector is recorded in the Sector Header, also as an absolute time. It has no prescribed relation to the addresses of the Sections, because the mapping of a Sector on the Sections during recording is implementation dependent due to the freedom left in clause 16. Therefore, the address of a Sector is filled in just before the Sector enters the CIRC encoder.

The nominal value of the absolute time in the Header of a Sector shall be equal to the absolute time recorded in the Control bytes of that Section which is being processed by the 8-to-14 encoder at the instant that the Sync of the Sector enters the CIRC encoder. This prescription assumes that the CIRC encoder is the only delaying element in the recording electronics.

The tolerance on the nominal time in the address of the Header of a Sector shall be ± 1 s. This tolerance is large compared with the recording time of a Section (1/75 s) and of a Sector, in order to accommodate the freedom this ECMA Standard leaves for the implementation.

Each Sector has a unique address. The address of the first Sector with User Data of an Information Track is written in the table of contents of the disk (see 22.3.4). Thus, the table of contents points to the start of an Information Track on the disk in terms of the absolute time in the Control bytes with an accuracy of ± 1 s.

6 Likes
12

On Linux you should use cdparanoia! Without option it extracts the whole CD content into one file, with the -B option, it puts each track in a separate file, starting with “track0”, if there is a pregap track. Default format is wav.

… and thanks for this whole lesson!

1 Like
13

Oh yeah, I used to use cdparanoia all the time… but I don’t trust it anymore. I found an interesting bug/design flaw with it. If your CD has a long, identically repeating bit pattern… like a lot of electronic music does… cdparanoia attempts to overlap multiple “sector” reads, on the assumption that the CDROM drive is returning CDDA data starting from somewhat random offsets, as many older CDROM drives do. (Seriously)

So… if the music on your CD has some very “long” repetitive sounds, cdparanoia will attempt to reassemble them into a shorter repetitive sound, because it thinks the drive returned a following sector from an earlier physical offset.

i.e. Your music gets a few milliseconds shorter, but it is completely inaudible to the human ear.

Yeah, I make MD5 hashes of everything all the time. I’ve found several silently data corrupting hardware bugs this way…

Oh, and let me tell you about the weird CRCs that EAC uses for verification. The algorithm used misses (does not detect) about 3% of all errors. This is a different 3% of the data from the C2 error correction on the CD itself, which, also, misses about 3% of errors. So, I guess when used in combination, they’ll only miss 0.09% of all errors… 99.91% accuracy! (That’s equivalent to about 5 seconds out of every hour.) For comparison, the popular CRC32 algorithm that everyone uses will miss an error about 0.00152587% of the time. (99.99847413% accuracy).

CDs aren’t really “digital”; They are small scratch-proof vinyl records, with about 1.5MHz of analog bandwidth.

6 Likes
14

Wow, that feature sounds wonderful!
Just use the --keep-boring-filler-loops option or rip real music! :stuck_out_tongue_winking_eye:
(sorry, I couldn’t resist)

2 Likes
15

I think this is the “Julie Roberts” bug?

If so, this should have been fixed in libcdio-paranoia as of Incorrect track bug smallest absolute value match by rocky · Pull Request #10 · rocky/libcdio-paranoia · GitHub

2 Likes
16

That bug is complete mistery.
It just says I will edit this post soon to explain what I mean. I think this is critical.

It apparently is about ripping a Julie Roberts track 5 badly.
But how badly?
I could not find a description of the issue nor of the fix. :thinking:
Too much hidden inside circumvoluted English sentences.

2 Likes
17

The description of the issue:

The fix is not actually in whipper, since it’s an upstream issue that whipper can’t really handle. There are links in the comments to both discussion of the issue itself as well as potential fixes and final fix with upstream (in this case, libcdio-paranoia). I also linked the PR with the fix in my last message.

18

Yes I understood foxgrrl issue, it is very well explained.
But the Julie Something issue, really, is completely cryptic.
I was wondering how you could see a link with our issue, here. :wink:
I didn’t find an issue description over there at github.

19

It’s the same thing. What @foxgrrl described is literally what the Julie Roberts issue is: short segments of repeated audio. Hence why I’m seeing the link.

2 Likes
20

It has an edit pointing to a ticket on savannah that explains in detail.

1 Like