Yes, I believe so. I think I first read about it from Pio2001, but have also read it from others who seem to have the same level of deep understanding as he does.

Personally, no, I don't recall. I may have with others I have helped in the past, but most likely not. There's always the possibility that one has occurred but gone undetected because errors are typically identified through inconsistencies (that is to say errors not identified by C2 pointers). The only data I've posted to the forum is this, but I don't think there was a consistent error across different drives.

Cheers Greynol. I think I am on safe ground

Pio2001 sure knows his stuff. I was impressed with his input on a thread a while back

When going the extra step in finding errors, these are the main methods in order of descending confidence:

• Comparing against a different original copy (from the same master, applying a different offset may be necessary)
• An AccurateRip match(*) so long as yours isn't the only submission (essentially the same thing as the one above, except that the data must be from the exact same pressing, not just the same master)
• Ripping with a drive based on a different chipset
• Comparing secure without C2 to burst or secure with C2
• Burst T&C
• Secure (no C2) or Secure (C2 and T&C) with 100% track quality or re-reads only at the very very end of a track (probably no less confident than Burst T&C)
• Secure without C2 with re-reads somewhere besides the very very end of a track with no errors reported (the fewer sets of re-reads required the better) a matching test CRC can improve confidence, but only slightly and not enough to change the ranking

(*) In the case of AccurateRip, it's placement is only relevant when it can verify a rip. Any other result is inconclusive.

Good list there.

These problems are only just becoming important to me. Our library has all of my CDs in it. Now I am going through the other half's. Lets just say she wasn't quite as careful as me with her originals!

If you haven't already, check out this post:
http://www.hydrogenaudio.org/forums/index....st&p=541915

Hi,

Thanks for the great guide.

When ripping however, do I just Copy (Shift + F5), or do I choose "Copy & Test" (Shift + F6)

Edit: Oooh, I found my answer, should've searched this topic beforehand.

I'm not sure why it's quoted differently than the rest, however, this is what I've found:

-T comment="%e"

adds the contents of %e to the comment field of each file, the value of %e being whatever "comment" EAC has found, which, in my case, was nothing, so a "; " was inserted into the comment field,

-T "comment=EAC (Secure Mode)"

adds the literal text "EAC (Secure Mode)" to the comment field of each file, with no quotes, however, there will first be a space and then a semicolon inserted between each field which is added, therefore, as this point the comment field should contain " ;EAC (Secure Mode)".

It doesn't help to move the variable %e to the last comment entry, as EAC doesn't seem to check whether the varible is empty before inserting the semicolon followed by a space, which then results in a comment field which looks like this, "EAC (Secure Mode); ".

I wonder if EAC populates %e from a cue file?

%e is populated by the value specified on the "Compression options" > "Offset" tab. (press F11 to open the dialogue, select the "offset" tab and look to the bottom of the tab).

I'm not sure why you are getting a semicolon; I can only assume that you have "Write following text into ID3 tag comment field" selected and a semicolon in the text field.

Yes, "Write following text into ID3 tag comment field" was indeed selected, but no, the field is empty, as I didn't want EAC to populate the comment field. (the offset tab doesn't seem like the best place for the comment tag selection)

As well, these tags, "-T comment=EACv095b4 -T comment=newcomment" produce this comment field, "EACv095b4; newcomment", so it seems to me that EAC is inserting a space followed by a semicolon to divide up the comment field.

BTW, this is my current EAC FLAC config, "-8 -S -V -T "artist=%a" -T "title=%t" -T "album=%g" -T date=%y -T tracknumber=%n -T genre=%m -T CRC=%b -T totaltracks=%x -T freedb=%f -T DAE=EACv095b4 -T CDR=Plextor716A %s"

I've added seektables via -S and several extra tags, CRC, FreeDBID, DAE etc.

Ah, I didn't see that you had two -T comment= switches. That'll be why then. I'm not sure why people would use two switches...

Actually, I personally don't use two comment tags, as my config shows, however, the example EAC config that starts this thread does, "-T comment="%e" -T "comment=EAC (Secure Mode)". This was the part of the configuration string that produce this result, " ;EAC (Secure Mode)" in each of the files' comment fields.

This output does depend upon which ID3 tag option is selected on the "Offset" tab, which I now understand, thanks!

So, from what I can see now, using the following recommended config, "-6 -V -T "artist=%a" -T "title=%t" -T "album=%g" -T "date=%y" -T "tracknumber=%n" -T "genre=%m" -T comment="%e" -T "comment=EAC (Secure Mode)" %s", will result in one of the following comment fields in each FLAC file:

tracknumber ;EAC (Secure Mode)
CRC ;EAC (Secure Mode)
FreeDBId ;EAC (Secure Mode)
text ;EAC (Secure Mode)

(italics indicate variable contents)

I hope this is clear.

Crystal. I'm not sure why people wouldn't just do:


... though.

However, the most important point is that users should be aware of the origins of %e. They should also research enough about FLAC and FLAC tagging to adapt the suggested command line to suit their personal needs. If they are not interested in recording the tracknumber, CRC or freedb id, and are never going to bother with the bespoke text on the "Offset" tab, they may as well just use:


... or:

Sure, however, it wasn't easy to find out where "%e" originated. Did I miss that section in the EAC documentation, the HA forum or this thread? If so, I apologize for my lack of diligence.


I couldn't agree more ... so here I am!


True, however, personally, I'm interested in just how far some people have taken this tagging thing as I'm involved in tagging some complicated collections. For instance, there are quite a few vorbis tags, especially when classical, compositional or remixed music is involved. I'm quite curious, does anyone use any special EAC / FLAC configurations when ripping non-mainstream music?

All research into any program should begin at its official site.

http://www.exactaudiocopy.de/en/index.php/...sion-questions/
(This is in the FAQ which is available from EAC's Help menu, believe it or not).

Also, EAC has an official discussion forum:
http://www.digital-inn.de/forum271

My drive supports overread in lead-in but not in lead-out. I think that the only way to workaround this is to rip the first track separately with overread in lead-in/out enabled, then go for the rest with overread disabled in this kind of situation

Eli thanx so much for this tutotorial it is very useful :-)