Does anyone include the pre-gap when ripping a CD to separate files? It's usually silence of course, but I've read about hidden songs in the pre-gap and live albums which have audio in the pre-gap between the tracks.

I just rip seperate files with EAC default setting. This includes audio info in pregap to previous track. I'm quite confident with that.

As for hidden pregap track 01, I rip this with "rip selection", generates a cuesheet, edit it, cut's out the pregap track using foobar2000 and label it as track 00.

Somehow I would have liked to keep the original CD cuesheet for all my albums, but I find the single-track organisation easier to manage and has better compatibility with anything.

I consider the (length of the) silence to be an integral part of the album.

Fandango, do you add it to the front of the track?

Do you find any benefit from extraordinary silence at the beginning of a track? Usually (at least on older material) the silence often is 2 sec.

I haven't heard of any "hidden" songs except for in two places:

1. After some amount of silence at the "end" of the last track, another track is appeneded. Technically, that's two songs with a bit of silence in between inside a single track (the last track).

2. In an "extended gap" (aka "Index 00") before Track 01 starts (normally this is at Track 01 Index 01, where most CD players start playing music). This is known in these parts as "Hidden Track One Audio" or HTOA.

---

Pretty much all rippers automatically handle ripping the audio from item #1 above, you just end up with a very long final track.

For item #2, the situation is more complicated. Some rippers can manually extract that audio (EAC with some custom fiddling for each CD you encounter with this kind of extra song). Some rippers automatically handle ripping it (Riptastic! and newer versions of dbpoweramp can extract it). However, many optical drives cannot read this part of the CD due to firmware limitations (sometimes they give errors, other times they just give data that is equivalent to silence).

-brendan

I rip with EAC in its default mode, which appends the pregap to the end of the previous track, and I manually rip the pre-track-1-gap if it is longer than would normally be expected.
I do that by ripping the entire disc as a single WAV file, then splitting it based on the extracted cuesheet.

I also always keep cuesheets and log files.

I'm also riping the INDEX 0 from TRACK 1 with EAC's "Copy Selected Tracks Index-Based" (Alt+X) or (Alt+Shift+X).

1. Select all and "Copy Selected Tracks"
2. Select Track 1 "Copy Selected Tracks Index-Based"
3. Keep Track 1 Index 0 eg. "01.00 Title.wav" and delete the "01.01 Title.wav"

Has anyone heard of audio data in the pregap that isn't a hidden song but is transitional audio between tracks, such as a live performance?

You bet!

I've never found one with it but I have made one myself.

How about a long silent pre-gap, something over 2 seconds? Ever run into that on an original disc?

Yeah, Abbey Road, 14 seconds before the final song IIRC.

That's the kind of thing that makes me not want to append pregaps. As long as you listen to the whole CD it makes sense, but otherwise it's not good. AR requires appended pregaps and a pregap may contain audio, but on the other hand you've got issues like this.

Appending gaps (as opposed to prepending gaps or leaving them out) most closely mimics the behavior of a standard CD player.

Unless you're shuffling.

How often do you rip a CD with a pregap? I've ripped about 30 now and according to 'cdparanoia -Q', not a single one has had a pregap.

Sure and I guess that's the most common way people play their discs.

If you're asking me personally, probably most of my discs have gaps between tracks, though it isn't something to which I spend a lot of time paying attention.

Well enjoy whatever you decide to do.

Thanks greynol.

if there's actually something in the pre-gap of the first track, EAC displays the track in a nice red color. so it's hard to miss. (happened to me with Oceansize's 'Everyone Into Position' and Qotsa's "Songs for the Deaf")

for the normal gaps between tracks I also use the default "append to previous track"

The length of the first track pregap is the only thing that determines the color that EAC displays. Whether or not it contains something has nothing to do with it.

I must disagree. I've seen many CD's that have 2 seconds and 32 frames of the pregap before Track 01 and it is not in a red color as your post suggests...
I know it can be called "manufacturing error" because there is nothing except for silence...

You'll see that I did not specify a number. It has been a very long time since I've visited this issue and IIRC, it was anything greater than 6 seconds that shows up in red. I believe I posted this number a while back but I could not find this post.

Regarding whether HTOA is silence or not, you should be sure to test it with a drive that is capable of extracting this information.

I appreciate your desire to challenge what you may think is misinformation, but you're not correct in this instance.

EDIT:
Yes, I just verified it. If the pregap before the first track is greater than 6 seconds (or 8 seconds depending on how you count it), the first track will show as red, otherwise it will not. The contents of the pregap (digital silence vs. samples with non-zero amplitude) is irrelevant.

I understand that EAC appends pre-gaps to the previous track and that this what AR's verification is based on. Does EAC just drop a short, silent pre-gap before track #1? Is that copasetic with AR?

The only pre-gap I've run into so far with cdrdao analysis is a 00:00:32 pre-gap before track #1.

EAC can prepend gaps to the next track, rip single file images which include HTOA at the very beginning, or leave gaps out completely. It can also rip whatever range you ask of it.

As for AR, entries are based on the TOC of the disc, though it doesn't keep a hash of the data before the first track. This means that a copy of a disc that is the same as the original except that there is no pregap will be seen as an entirely different entity from the original that has the pregap, but what's in the pregap is inconsequential.

When you say does EAC drop a short silent pre-gap before the first track, what do you mean? Are you talking about burning a disc with EAC? Otherwise, EAC grabs; it doesn't drop, unless you mean drop as in leave out in which case you would have probably asked if EAC drops the silent pre-gap before track #1.

Since I'm trying to make sense out of your question, are you curious about only the special case where the pregap before the first track is silent or are you interested in the general case where the pregap doesn't have to be silent? Also, when you say silent, do you mean null samples or a pregap that contains only low level noise? The pregap can be any of the above, including samples that represent audible data that isn't noise; even when it is only 32 frames long.

Hi greynol,

I'm trying to create an AR-verifiable series of FLAC files from my CDs. I've got the offset set correctly in rubyripper and from what I've read, pre-gaps need to be included in order to verify with AR. I believe they are usually appended to the previous track, but I'm not sure what to do if there is a pre-gap before track #1. Should it be prepended to track #1? The goal is to create a set of files that would verify via the AR perl script.

I was trying to work with someone to improve the existing scripts, but it never got off the ground. Now that tripleflac is here (even though I don't use it) and AR2 is around the corner, my desire has waned. Once again, it would appear that Windows users have the clear advantage when it comes to DAE.

Anyhow, you're going to need to use a CUE sheet with a pregap line before the 01 index of track 1. As stated earlier, AR is based on hashes for tracks with gaps appended, but the starting sector for each track is still necessary.

Also, the correction used just to compensate for you drive's read offset isn't always the best choice when your pressing doesn't exist in the database. It's a shame that AR2 is going to ignore even more data to get around this considering there are better methods already being used with the current database.

Does this mean pre-gaps should be appended to the previous track except in the case of track #1 in which case it's pre-gap should be pre-pended? Maybe a CD ripped to separate FLAC files without a CUE sheet can never be verified against AR?

What do you mean? I shouldn't be using the EAC/AR read offset to rip CDs?

Yes.
No, the gap before track 2 (if it exists) is to be appended to the end of track 1 and the gap before track 1 is not prepended.

If you have no way of recreating the correct TOC, then you can't verify with AR.

It has to do with the nature of different pressings and whether the one you're ripping exists in the database. Search the forum if you want to learn more about this.

So track #1's pre-gap doesn't exist on one of the FLAC files? It only exists in the TOC?


Will this work?

1. separate FLAC files with pre-gaps appended to the previous track
2. TOC CUE sheet as generated by 'cdrdao read-toc --device /dev/hda cuesheet.cue'

Is ripping with the AR offset a bad idea now?

It doesn't have to, no. If it does (like with a single-file image) then whatever method you use to access AR needs to way to index the data (like with a cue sheet).

The size of the pregap will affect the TOC. The data that comprises the pregap comes after the TOC.

It could if implemented properly.

I never said that. I said that the proper offset will do you no good if your pressing doesn't exist in the database.

What do you think about separate files vs. a single file and cue sheet? Separate files seem to have better compatibility, but single files are coming around. A single file and cue sheet seems like it does a better job matching the medium it is representing.

I used to use single files but changed to separate tracks. Either way, you can get a complete image, so burning isn't really an issue. It just depends on how many hoops you want to jump through and having the right tools at your disposal.

Playback is a different matter, but on my PC I've been able to use either for quite some time now. In fact, a single file image can be more versatile since a cue can be modified fairly easily so that tracks begin with gaps if you like. Can't seem to leave them out though.

I would think you wouldn't get a complete image if track #1 contains a non-silent pre-gap unless you use a single file since the convention seems to be appending pre-gaps to the previous track.

Re-read post #8 in this discussion.

The post numbers seem very inconsistent. Is that .halverhahn's post?


The AR offset is still the best one to use isn't it? You wrote before "isn't always the best choice" which has me a bit confused. Actually, I guess it doesn't even matter any more since tripleflac can check for AR accuracy regardless of offset.

Yes.

Depends on what you're trying to do. If you're trying to get AR to verify but don't have the same pressing in the database then the answer is no. I'm feeling like a broken record here.

Unless there's a brand new version available, this is not correct.

I got that information from Ramon's post here:

http://www.hydrogenaudio.org/forums/index....w=&st=&

tripleflac is a Windows app so I can't use it, but just the fact that this type of "offset-independent" AR checking can be done is very encouraging.

It may seem that way, but you conclusion is incorrect. If you read down a little further you'll see step 3 in this post:
http://www.hydrogenaudio.org/forums/index....st&p=564191

The ability for tripleflac to check is absolutely offset-dependent.

I understand that the AR offset is involved in the calculation, but my point is that a rip can be verified via tripleflac regardless of the read offset used with the rip.

You still aren't correct. You cannot use tripleflac to verify the rip unless it is first offset corrected which tripleflac is not currently capable of doing. With respect to this part of the verification process, tripleflac is no different than ARcue.

Can ARcue tell you how far off your rip is from the AR offset like tripleflac can?

No, and that was what I was trying to get implemented, in addition to getting a hash for the offset-corrected data without actually having to write a new file, which goes beyond the capability of tripleflac even when combined with CUE Tools.

Very nice. I'd love to see either of those features implemented in ARcue so I can get onboard the AR train.