Extracting FLAC files from CD with EAC |
![]() ![]() |
Extracting FLAC files from CD with EAC |
Jun 1 2012, 00:18
Post
#26
|
|
![]() Group: Super Moderator Posts: 9259 Joined: 1-April 04 Member No.: 13167 |
So you fail to get an AR match and what is returned is a confidence number (and CRC?) from a different pressing? If the presumably correct hash value came from others with the same pressing, then yes.Can't it easily figure out the pressing by the other 12 of 13 tracks on the CD? If all of the confidences fall within unique ranges then you would think so, yes.If the confidence number shown were 21/22/23 then it would be readily apparent (to me, anyway) that AR found the right track in its database, without my having to understand the quirks of the whole process in detail. What if there were multiple elements for each track within the same range?EDIT: I forgot to mention that not everyone extracts all the tracks from an album. More popular tracks will have higher confidences than less popular ones. I suppose an intelligent algorithm could account for an average percentage increase in confidence for popular tracks. This post has been edited by greynol: Jun 1 2012, 02:47 -------------------- Everything sounds the same until it is proven otherwise.
|
|
|
|
Jun 1 2012, 21:32
Post
#27
|
|
|
Group: Members Posts: 7 Joined: 29-May 12 Member No.: 100265 |
@ Greynol: I've done about 7 extractions with this disk and the only time I got an error (this happened a second time) was with C2 enabled (once with "Test and Copy" and once with "Copy"). It only seems to occur when C2 is enabled. All the other times, I got a good result. All those rips I mentioned in my last post were of the same disk. So that is good news, I hope.
So if I understand correctly, I should do the following: - Secure Mode > Accurate Stream enabled/ C2 disabled - Then hit "Copy Selected Tracks - Compressed" (Don't use "Test and Copy") - If the log says "All tracks accurately ripped" then I am done and have made a perfect rip. However, if I have the following line: "Some tracks could not be verified as accurate" then what should I do with the problem track(s)? More importantly, is this what I should do for every rip (not just this one disk)? |
|
|
|
Jun 1 2012, 22:29
Post
#28
|
|
![]() Group: Super Moderator Posts: 9259 Joined: 1-April 04 Member No.: 13167 |
I would continue to rip with C2 pointers, check AR results and generate a second (test) CRC for tracks that can't be verified using burst mode for discs which appear to be in good condition and in secure mode without C2 pointers for discs that do not appear to be in good condition. If you have a second drive that requires a different read offset correction then I would use it to generate a second CRC instead.
I also noticed that you have the error recovery level set to high. I would set it to medium. While I have occasionally seen this problem with EAC and believe it is likely a fixable bug, I would not allow it to dictate my wasting an inordinate amount of time with an inefficient process. What, you say all this manual reconfiguring and re-ripping is also inefficient? Well go ahead and use secure mode without C2 pointers and be glad you have a drive that doesn't cache audio data. Otherwise, maybe try a different program like dBpoweramp, CueRipper or foobar2000. What to do about tracks that cannot be verified by AR? You can try fixing them with CueTools or within EAC using the CueTools plugin. For discs that are in the AR database but none of the tracks can be verified, use CueTools to check them against an alternate pressing (good thing you're creating cue sheets This post has been edited by greynol: Jun 2 2012, 01:11 -------------------- Everything sounds the same until it is proven otherwise.
|
|
|
|
Jun 3 2012, 21:29
Post
#29
|
|
|
Group: Members Posts: 7 Joined: 29-May 12 Member No.: 100265 |
Ok. I think I am going to try out a few more disks and see what kind of results I get. Thank you for your help so far greynol.
|
|
|
|
![]() ![]() |
|
Lo-Fi Version | Time is now: 20th May 2013 - 15:52 |