I'm doing the whole cd backup in flac format and I have a few questions:

1.My CD drive doesn't support Lead-In/Lead-Out. Now I realize I'm not going to get a 100% perfect copy, but really am I going to miss it since EAC fills up the missing data with silence, and if I am understanding correctly that data is essentially inaudible, is it really an issue? My only two other are options are to use my other drive, which supports lead-in lead-out, but also caches thus resulting in rips that take about ten times longer. Or to buy a new drive, which I don't have the cash for right now or the inclination.
2.Are cue sheets necessary? I'm ripping into multiple files, so if I wanted to reconstruct the cd I could just use the flac files as each track or would that method lose something additional that the cue sheet is going to give me?
3.I've been putting the CRC checksum in the comments, and in the log files I have been generating. But I was also going to apply replay gain. That is going to add size to the file and make the checksums useless? Also, does replay gain transcode with the flac files if I got to mp3 or vorbis?
4.I'm getting a lot of tracks not matching on AccurateRip, reporting a possible different pressing. Is this fairly common? It seems to undermine AccurateRip that I just ignore bad matches. I am fairly certain I am getting clean rips, because these are new cds and eac is getting 100% or very close to 100% track qualities.

Thanks for any help anyone can give me on these few points.

Can't answer all your questions, but

2. Cue sheets are not "necessary", but it's easy to create and store them now since you're going through the time and trouble to rip the CDs. You may regret not having them in the future. Others may give more compelling examples of why you want them now.

3. Replay gain typically doesn't transcode well because other codecs may not give the same values. Better to calculate replay gain values in the the new format.

1. Lack of lead-in/lead-out support on your drive only cuts off a few milliseconds from the beginning or end of a disc. CDs generally start and end with a second or so of silence, so it's a non-issue. Technically, you won't have exact copies of your CD, but I've never ripped a CD where it made an audible difference.

2. I don't see any reason to use cue sheets. You can get gaps marked exactly as they were on the original discs by using CUEs, but again this doesn't make any audible difference when playing it. That, and I never burn CDs. I could be wrong about this, though.

3. That depends on whether you're making checksums on the audio data itself (which is what EAC does, I believe) or on the file. ReplayGain tags don't change the audio data, thus the checksum of the audio data will be the same.

You can transfer ReplayGain values when you transcode, but when you're transcoding to lossy the peak values can change significantly, and the gain values to a lesser extent. So you will need to do a new ReplayGain scan on your lossy files to get accurate RG values.

4. I don't use AccurateRip so I can't tell how common it is for discs to not match. But if test & copy CRCs match, and EAC doesn't give any errors, you should have a good rip.

You're right about this.

Depends on whether RG is being applied directly to the audio data or not.

Should is the operative here. EAC's reporting of errors provides little confidence and should be taken with a big fat grain of salt.

It depends on your disc collection, but it is not uncommon at all to have different pressings than the ones stored in the AR database.

How do I control this? I am currently using foobar to apply the replay gain. Also how do I go about checking the CRC on just the audio or the file as a whole?

I've also been hearing about burst mode and test and copy. What exactly does test and copy doing that makes it pick ups errors that a normal rip wouldn't?

My drive also supports, lead-in, but not lead-out. Is there anyway to enable just lead-in and not lead-out in EAC? So that I have a perfect rip for everything except the last track?

It may be more useful to tell us what you're doing step by step before further confusing the issue by asking more questions; most if not all of which have already been answered in one form or another on this forum and many of which have been re-asked and re-answered quite recently. It would behoove you to familiarize yourself with the search function.

You really don't need to worry about your lossless files containing replaygained data unless you're using wavegain or are converting from wave to flac, adding replaygain info to the metadata and converting back to wave again while intentionally having the decoding process apply replaygain to the audio data. I apologize for unnecessarily complicating matters by speaking in general terms earlier, but at that point you had not given any specifics.

Also, have a look at wiki...
http://wiki.hydrogenaudio.org/index.php?ti...Lossless_Backup

Here's a link regarding T&C in burst mode... http://www.hydrogenaudio.org/forums/index....mp;#entry508268

My apologies for answering EAC-related questions in the flac forum.

Test & copy rips each track twice. If both rips are identical (=same CRC) then there were no errors.

This is not true in the case of consistent errors which can happen whether you're ripping in burst mode or in secure mode.

Here's a recent discussion I had with the author or Rubyripper:
http://www.hydrogenaudio.org/forums/index....showtopic=57021

Again, this is well off-topic for the flac forum.

Greynol is right, this is probably the wrong forum for my questions, I guess I was zoning out when I started this thread. If a mod could move it over to a more appriopate place, I would appreciate it.

To be more specific about what I am doing as far as CRC/Replay Gain goes, I'm ripping to FLAC in EAC and then applying Replay Gain in foobar. I am using default foobar settings to do so. For vorbis this put the RG into the metadata (I think) so I would assume it would do the same for FLAC. Correct me if I am wrong about this, but CRC is a checksum based on filesize? So adding metadata like replay gain or even, comments, would change that filesize and thus invalidate the CRC checksums I am having EAC write to the log/comments.

Thanks for the info so far, its good stuff.

EAC's CRC is calculated from the raw PCM data only. It uses the standard 32-bit algorithm but may or may not include samples that are null in both channels when computing the checksum depending on how EAC is configured. If you decode your flacs back to wave, the PCM data won't change and neither will the CRC, regardless of anything you do with the metadata.

I personally don't see any benefit to keeping these checksums or being concerned about them since flac stores an md5 checksum in order to verify integrity during testing or decoding. Again, the md5 checksum is not influenced by anything other than the raw PCM data.

If you want to calculate crc or md5, you could use an external program to generate a list and check that list once in a while. I don't know how to check the crc value when it's stored in the metadata of the file.
And then, differences only tell you that there's something wrong, not providing a repair option like par2 and quickpar can. As already mentioned flac files contain an md5 value for the audio data.

Just to be clear, I take this to mean, you will scan the flac files with foobar's replaygain tool, to add replaygain metadata to them. This doesn't change the audio data, it only tells players (like foobar itself) what gain to apply to the files when playing them (assuming you're using the player's replaygain option).

Is this what you mean?






If you are adding replaygain tags with foobar, you've presumably already done ripping and CRC validation with EAC 'Test and Copy'. So why would you need to keep the checksums the same after that?

For checking the files later, say after transfering between mediums or storing on a dvd for awhile.
Basically EAC has a bunch of comments it can throw in, and no comments is not an option, so while I'm sure I could do a custom tag and leave it blank, I thought the CRC checksum in the comment tag sounded intersting for the reasons I gave above. I didn't realize flac already did this automatically, as greynol pointed out.

You've configured EAC to create flac files, correct?

If so, no comments is certainly an option. If you're referring to the fact that EAC automatically creates an "Encoded" field when writing ID3 tags, I would counter by saying that you should not be applying ID3 tags to flac files. This is what is advised by Josh, at least.

OT: Monkey's Audio includes a checksum to verify the integrity of the compressed audio-portion of the file which makes checking files that are archived quite easy. Of course this is much more necessary for MAC since it's decoding speed is much much slower.

Actually, Add ID3 tag is not selected. But the next tab (offset) it refers to writing to the ID3 tag. The would guess that selecting the last option and leaving it blank would not apply the tag.

If "Add ID3 tag" is not selected, whatever is in the ID3 Tag tab or the comment section in the Offset tab is no longer relevant.

Since you've mentioned the Offset tab, make sure you leave the "Use offset correction for encoding and decoding" setting unchecked (this is a different offset setting from the one regarding your question about overreading).

Despite having ID3 unchecked, EAC still uses the value I select in the offset tab. I can view the comment along with the one I am manually feeding the encoder in foobar and other players.

I would guess that the term "ID3" is just statically in the gui and its actually writing vorbis comments, but I'd need to hex edit the file to check for sure, and I honestly have no idea how I would spot the differance between vorbis and id3.

What exactly do you have configured for your Additional command-line options?

used to be -6, but -8 doesn't seem to be taking that much longer (then again it doesn't really seem to compress much more either).

I just tested out the blank comment thing, and I get this in the comment field "; EAC (Secure Mode)". So it writes a semi-colon instead of nothing, wierd. I'm using EAC 0.99 prebeta 3, by the way.

That's your problem.

...and if you use,???

Ah good eyes, I feel dumb. Still it should just be writing vorbis comments instead of ID3 right? I might want to do something like -T comment "%e EAC(Secure Mode)"...

To get more on topic of flac, should I be embedding a cue sheet or just have a separate file, for reconstruction purposes? Also I was looking on the wiki about FLAC's replay gain switch, I couldn't find out if I could put that switch in and have it do ablum gain somehow? If not its not a huge deal to do it in foobar afterwards, I'm just curious.

Right.

Then make sure you get the syntax right...
I'm not sure what happens if you try to put two separate comment lines in there like what's in your previous command line.

It's a matter of personal preference, though it doesn't make sense to me to embed a cue sheet with each track.

Not possible without some sort of helper program since EAC encodes only one track at a time.

Just for the record, I took the commandline I was using directly from the EAC FLAC recommend settings stickied thread. (Except for the -8, which was -6)

Thanks for all your help.

You're welcome.

So you did.

Well there's nothing I can do about that. It goes to show that it's really not a good idea to have stickies like that, especially when they begin by advocating the use of a different program than the one listed in the subject line. I am extremely annoyed by this, but that's a different subject.

FWIW, I recommend following what's in the wiki over what's in that thread, though the discussion may be worthwhile reading.