After greynol detected (and fixed) some errors in the HA-wiki regarding EAC articles (see this thread (http://www.hydrogenaudio.org/forums/index.php?showtopic=56495)), the suggestions was made to restructure all the available EAC guides/tips/how-to's and adding some information here and there, so we get a good and particularly correct EAC guide.
So this thread is meant to discuss about this ongoing process.
Created today: EAC configuration wizard (http://wiki.hydrogenaudio.org/index.php?title=EAC_Configuration_Wizard)
Edit: When you find some phrases with bad formulation or simply wrong info (hopefully not ), feel free to edit the relating article. You help is highly appreciated!
Hey guys, I'm still alive. I had a lot to do in the last time, so I couldn't spend much time for "my" EAC wiki articles. I hope this will change, and I can work a little more on the wiki.
So, here's the next big block: The EAC options dialog (http://wiki.hydrogenaudio.org/index.php?title=EAC_Options).
I've tried not to copy all the explanations you can find on some places in the web (which are mostly taken/copied/translated from the Coster Factory), but to be a little more creative.
So again: If you find some errors (technically, grammatical, or whatsoever), then do not hesitate to change the articles(s) directly in the wiki. If you don't have a wiki account, then just place your suggestions in this thread or send me a PM.
And yes, some feedback or opinions would be really nice! I've started my work mostly because there were found some errors in the wiki regarding EAC. I'll do my best not to place new errors in the wiki, but I also have to say that I'm not a real expert. So, if you find errors or phrases which could be mistaken easily, then just give me a shout...
Briefly looking at the site I noticed this:
[blockquote]Error recovery priority
[blockquote](Default: Medium, Recommended: High)[/blockquote][/blockquote]This setting specifies how many rereads will be done in a case of reading errors. Changing this option to high leads to a better error correction. On the other side, the ripping process will last longer for scratched CDs. But nevertheless, it is recommended to set this option to high so that it is more likely that EAC can correct these errors.
"Changing this option to high leads to a better error correction" is not necessarily true. This setting can actually increase the chances for errors going unreported.
I'm not sure about the extractions and compression priority being recommended at high. Did you conduct a test or something to show that it gives a speed increase while ripping without running other applications at the same time?
Retrieve UPC/ISRC codes in CUE sheet generation, you need a caveat since there are drives that cannot do this properly with EAC.
Create '.m3u' playlist on extraction produces playlists for wave files only, unless this changed recently.
Use X simultaneous external compressor thread(s) is fine if process can be run on separate processors (multi-core, multi-cpu, hyperthreading).
Thanks for the feedback, greynol!
"Changing this option to high leads to a better error correction" is not necessarily true. This setting can actually increase the chances for errors going unreported.
Yes, there I really didn't know that should be recommended. If this option is set to "high", then EAC will do more re-reads. So I understand that on scratched CDs, this may lead to errors slipping through because when a bad sector gets read with the same (wrong) result, EAC will assume that it was read correctly.
On the other hand, exactly that (the re-reads) is the strategy of EAC in secure mode. So I also assume that setting this option to "high" will increase the possibility that EAC can actually correct errors.
So this is a double-edged sword: Better chance to find errors or besser chance to correct errors.
What would you recommend?
I'm not sure about the extractions and compression priority being recommended at high. Did you conduct a test or something to show that it gives a speed increase while ripping without running other applications at the same time?
OK, without other applications running, this doesn't matter at all. Even with "idle" ripping will take the same time. But when you have other applications running (I let run SuperPI while ripping), it will speed up things a little. But this also depends on the length CD. And there the bottleneck is not the ripping process in EAC itself, the external compressor will always benefit much more from higher process priority.
But while testing, I've found out two funny things (maybe bugs of EAC?):
1. Usually after an external compressor returns, the time it needed to compress a file will be added to the total time display in the status window. Only if it is the last track that was compressed, this does not happen. So the time needed to compress the last track is always sweeped under the carpet.
2. The "extraction and compression priority" - as the name implies - sets not only the priority of EAC, but also of the external compressor. This does work, if this setting is set to "idle" or "normal". But when set to "high", the process priority of the external compressor will always the "normal" and not "high".
Did anybody find out this before?
Retrieve UPC/ISRC codes in CUE sheet generation, you need a caveat since there are drives that cannot do this properly with EAC.
OK, but what happens if the drive is not able to retrieve these info? Will EAC freeze or crash?
Create '.m3u' playlist on extraction produces playlists for wave files only, unless this changed recently.
This does also work with other file formats.
Use X simultaneous external compressor thread(s) is fine if process can be run on separate processors (multi-core, multi-cpu, hyperthreading).
OK, will be changed...
"Changing this option to high leads to a better error correction" is not necessarily true. This setting can actually increase the chances for errors going unreported.
Yes, there I really didn't know that should be recommended. If this option is set to "high", then EAC will do more re-reads. So I understand that on scratched CDs, this may lead to errors slipping through because when a bad sector gets read with the same (wrong) result, EAC will assume that it was read correctly.
On the other hand, exactly that (the re-reads) is the strategy of EAC in secure mode. So I also assume that setting this option to "high" will increase the possibility that EAC can actually correct errors.
So this is a double-edged sword: Better chance to find errors or besser chance to correct errors.
What would you recommend?
Setting the option to "high" will increase the possibility for EAC to get consistent data, but consistent data doesn't always translate to accurate data.
I recommend that the decision be left to the user with full information about the consequences of their choice. Low might even be preferred by someone who may be interested in simply checking to see if a disc potentially has errors. My personal experience is that it is rare for EAC to get a correct result in 4 or 5 sets of re-reads as opposed to 3.
But while testing, I've found out two funny things (maybe bugs of EAC?):
1. Usually after an external compressor returns, the time it needed to compress a file will be added to the total time display in the status window. Only if it is the last track that was compressed, this does not happen. So the time needed to compress the last track is always sweeped under the carpet.
2. The "extraction and compression priority" - as the name implies - sets not only the priority of EAC, but also of the external compressor. This does work, if this setting is set to "idle" or "normal". But when set to "high", the process priority of the external compressor will always the "normal" and not "high".
I was aware of 1, but not 2. Very interesting.
Retrieve UPC/ISRC codes in CUE sheet generation, you need a caveat since there are drives that cannot do this properly with EAC.
OK, but what happens if the drive is not able to retrieve these info? Will EAC freeze or crash?
It isn't a matter of drives not being able (since they can provide the correct information with other programs), it's that the information that EAC puts in a CUE sheet is garbage. IIRC, this is the case with many Lite-On drives.
Create '.m3u' playlist on extraction produces playlists for wave files only, unless this changed recently.
This does also work with other file formats.
I wonder when this changed (I never really moved away from V0.95pb5).
OK, I've changed the description and recommendation of "error recovery priority" and added a note to the UPC/ISRC thing.
Hope that the former gives enough background information now for making an own decision.
Bump.
New article finished: EAC compression options (http://wiki.hydrogenaudio.org/index.php?title=EAC_Compression_Options).
As always, some feedback would be highly appreciated!
New article finished: EAC compression options (http://wiki.hydrogenaudio.org/index.php?title=EAC_Compression_Options).
You haven't really made it very clear that the following options are completely
ignored if EAC is configured to use a User Defined Encoder:
- Bit rate (unless you use %r in the additional command line options)
- Quality setting (unless you use %l and %h in the additional command line options)(*)
- Use CRC check (unless you use %c in the additional command line options)
(*) You did mention %l and %h, but the information is not straight forward since you state, "To achieve the best possible quality, make sure High quality is selected" without being specific as to when this may happen (eg. toggles between -f and -h when LAME MP3 Encoder is selected as the parameter passing shceme).
Under Parameter passing scheme you state, "When doing so, all these additional command-line options have a higher priority than other settings in this tab" and "when you specify a particular bit rate by additional command-line option, then the Bit rate setting will not have an effect anymore". I don't think this is true. If you configure EAC to LAME MP3 Encoder as the parameter passing scheme, for example it will pass -b <bitrate> regardless of what you put in in the additional command line options. We see this all the time with people configuring EAC to do VBR per the wiki and forgetting to configure a User Defined Encoder. They end up getting VBR files, but with a minimum bitrate.
Thanks again greynol (my only friend when it comes to feedback on my articles )!
I've changed some phrasing here and there to make clear which options are ignored under which circumstances. Should be a little more coherent now.
Under Parameter passing scheme you state, "When doing so, all these additional command-line options have a higher priority than other settings in this tab" and "when you specify a particular bit rate by additional command-line option, then the Bit rate setting will not have an effect anymore". I don't think this is true. If you configure EAC to LAME MP3 Encoder as the parameter passing scheme, for example it will pass -b <bitrate> regardless of what you put in in the additional command line options. We see this all the time with people configuring EAC to do VBR per the wiki and forgetting to configure a User Defined Encoder. They end up getting VBR files, but with a minimum bitrate.
But here I can't reconstruct this behavior of EAC. For instance, when selecting "LAME MP3 Encoder" as parameter passing scheme, bit rate of 128 (via bit rate option), "high quality" and passing "-V 0" as additional command-line parameter, EAC puts togehter following command-line for LAME: "lame.exe -h -b 128-V 0"
This results in MP3 files which are actually encoded with -V 0, because LAME (3.97) seems to take only the last bitrate parameter to determine the bitrate used while encoding.
Could you elaborate on this a little more?
lame -h -b 128 -V0 results in a file that is vbr but bitrates will go no lower than 128 kbits.
What are you trying to accomplish with this particular guide exactly?
In terms of the external compression tab, I don't think it adds very much beyond the individual articles for each encoder. If anything, I think may add confusion.
What are you trying to accomplish with this particular guide exactly?
In terms of the external compression tab, I don't think it adds very much beyond the individual articles for each encoder. If anything, I think may add confusion.
As I already stated before beginning with the "project", all other EAC guides (in the HA wiki or the ones in the internet I know) don't provide much background info. They suggest ticking/unticking some options but don't tell what these options really do. And that's exactly what I try to do with my articles.
OK, in the case of the compression options, it's a little bit difficult, bacause there are many possibilities how they can be configured and many settings have some side effects.
Well, actually it would be nice to have a real EAC beginner evaluating all this stuff (if it's understandable and not confusing, etc.). Perhaps I concentrated too much on it and couldn't see the wood for the trees...
Well I tip my hat to you for trying.
This isn't exactly an easy task which is probably why so few have attempted it. It's definitely one of those things I didn't want to touch with a 10 foot pole.
So, here's the next big block: The EAC options dialog (http://wiki.hydrogenaudio.org/index.php?title=EAC_Options).
Aaah! I wish this particular guide was around when I ripped all my CDs not to long ago. However, it is always better to have things late than never!
Thanks @exec!
I was just looking over the EAC options and noticed this:
"An ASPI (Advanced SCSI Programming Interface) is used for communication between EAC and the used drive. Despite of the name, this interface is also used for communication with ATAPI (IDE) drives. EAC can use the native Win32 interface of Windows NT/2000/XP/Vista. But in general it is not recommended to use this native interface because bugs and errors could not be excluded."
I take serious exception with this statement. I have seen nothing but unconfirmed third-party information about this and seriously believe it to be little more than FUD. Many here agree with me on this.
Regarding the use of CDRDAO, I suggest first trying the native burning and using CDRDAO if the native interface doesn't work (the same advice as for the native win32 interface).
If anything ASPI will have more problems on anything newer than Windows 2000 than native SCSI Pass Through (because ASPI uses SCSI Pass Through, it is just a useless layer).
I take serious exception with this statement. I have seen nothing but unconfirmed third-party information about this and seriously believe it to be little more than FUD. Many here agree with me on this.
Yeah, I couldn't find any proof of this either. But on every guide I've found, I was always told "don't use the native interface beause of bugs..." (mainly copies from the EAC tooltip). Honestly, this interface seems to be part of Windows since NT 4.0. If there were so many bug in there, MS would have fixed it, wouln't they?
I'm now searching for any reason to really suggest a thrid party ASPI interface. If I can't find one, I'll probably change this paragraph.
If anything ASPI will have more problems on anything newer than Windows 2000 than native SCSI Pass Through (because ASPI uses SCSI Pass Through, it is just a useless layer).
In the case of EAC, does "native Win32 interface" mean SPT? Then SPT would be "more native" than ASPI...
What happens on Win95/98/Me. Is there an ASPI layer necessary to run EAC?
More errors in EAC options:
From
Fill up missing offset samples with silence:
If this option is disabled, some samples will possibly be missing in the resulting WAV files and it is likely that AccurateRip will report tracks as not accurately ripped (wrong checksums may be calculated because of these missing samples).
AR will not calculate a CRC if there are missing samples. Furthermore, AR will not report anything as not accurately ripped using the version of EAC that you've referenced.
For this setting to work properly, the offset correction has to be configured correctly, so that EAC knows how many silent samples have to be added to which track (see EAC drive options).
It makes absolutely no difference if the offset correction is configured correctly of if it's even configured. The setting will
always work properly.
From
No use of null samples for CRC calculations:
With this option enabled, null samples (silence) at the beginning and the end of a track will not be counted for CRC checksums.
Null samples anywhere within a track will not be counted; not just at the beginning or the end.
So when the drive offset is configured correctly, this option should be disabled to get comparable CRC checksums.
This doesn't make much sense.
The reason for disabling the setting is basically two-fold: general compatibility with other programs such as dBpoweramp and errors resulting in an inconsistent offset between rips.
Skip track extraction on read or sync errors:
You should probably state that it's still possible for there to be an accurate rip even though EAC has detected an error (sometimes the most consistent data actually is accurate data, even if it occurs less than 8 of 16 attempts).
Error recovery priority:
I really like the way you've described this function, but it is correctly labeled,
Error recovery quality.
From Fill up missing offset samples with silence:
If this option is disabled, some samples will possibly be missing in the resulting WAV files and it is likely that AccurateRip will report tracks as not accurately ripped (wrong checksums may be calculated because of these missing samples).
AR will not calculate a CRC if there are missing samples.
Does this mean, if this is option is disabled and my drive can't overread, then AR will fail in verifying the first/last track?
For this setting to work properly, the offset correction has to be configured correctly, so that EAC knows how many silent samples have to be added to which track (see EAC drive options).
It makes absolutely no difference if the offset correction is configured correctly of if it's even configured. The setting will always work properly.
OK, this really bullshit what I've written.
Which leads to my next question: How does EAC decide how many offset samples have to be filled with silence (if the drive can't overread)? To be able to always add the correct number of samples, EAC has to know how many samples "hide" in the lead in/lead out.
The reason for disabling the setting is basically two-fold: general compatibility with other programs such as dBpoweramp and errors resulting in an inconsistent offset between rips.
What do you mean by "errors resulting in an inconsistent offset between rips"?
And another question about the interface option: As default (after EAC was installed), "Installed external ASPI interface" is ticked, but greyed out (when you don't have an ASPI driver installed) in the interface tab. What is used as default in this case?
From Fill up missing offset samples with silence:AR will not calculate a CRC if there are missing samples.
Does this mean, if this is option is disabled and my drive can't overread, then AR will fail in verifying the first/last track?
AR won't fail in verifying one of the edge tracks; there will be no attempt made to verify
any tracks. It's just like disabling AR altogether (though this doesn't necessarily have to be the case for tracks other than one of the ones on the end, just that it happens to be the way it's written). Try and find out for yourself.
It makes absolutely no difference if the offset correction is configured correctly of if it's even configured. The setting will always work properly.
OK, this really bullshit what I've written.
Which leads to my next question: How does EAC decide how many offset samples have to be filled with silence (if the drive can't overread)? To be able to always add the correct number of samples, EAC has to know how many samples "hide" in the lead in/lead out.
EAC knows based on the number entered for the offset correction (whichever one of the two is chosen). Don't get hung up on how many samples are hiding in the lead-in/lead-out. Any non-zero offset automatically means that there will be samples in one of those two regions, at least from the drive's perspective.
The reason for disabling the setting is basically two-fold: general compatibility with other programs such as dBpoweramp and errors resulting in an inconsistent offset between rips.
What do you mean by "errors resulting in an inconsistent offset between rips"?
Literally what I have said. Drives without the accurate stream feature is the most obvious situation. Here's something to mull over...
http://www.hydrogenaudio.org/forums/index....showtopic=57884 (http://www.hydrogenaudio.org/forums/index.php?showtopic=57884)
And another question about the interface option: As default (after EAC was installed), "Installed external ASPI interface" is ticked, but greyed out (when you don't have an ASPI driver installed) in the interface tab. What is used as default in this case?
I'm sure the one that is selected. On my system, the default has the native interface selected with the top two grayed-out. An ASPI layer must have been installed on your system independently from installing EAC, or was automatically installed as part of your OS. My system has Windows XP Pro SP2 and did not come with an external driver nor does it have any hardware that would have required one.
I took the liberty to make some modifications to the Compression Options page (EDIT: just the External Compression (http://wiki.hydrogenaudio.org/index.php?title=EAC_Compression_Options#External_Compression) part) and wasn't sure what to make of this:
"Note that there may be some external compressors returning codes which EAC wrongly interprets as error code. If you experience such problems, try disabling this option."
Where did you get this information?
I was going to blow it away, but thought I'd ask first.
From Fill up missing offset samples with silence:AR will not calculate a CRC if there are missing samples.
Does this mean, if this is option is disabled and my drive can't overread, then AR will fail in verifying the first/last track?
AR won't fail in verifying one of the edge tracks; there will be no attempt made to verify any tracks. It's just like disabling AR altogether (though this doesn't necessarily have to be the case for tracks other than one of the ones on the end, just that it happens to be the way it's written). Try and find out for yourself.
Oh yes, you're right. So this option is really essential when you want to use AR.
I took the liberty to make some modifications to the Compression Options page (EDIT: just the External Compression (http://wiki.hydrogenaudio.org/index.php?title=EAC_Compression_Options#External_Compression) part) and wasn't sure what to make of this:
"Note that there may be some external compressors returning codes which EAC wrongly interprets as error code. If you experience such problems, try disabling this option."
Where did you get this information?
I was going to blow it away, but thought I'd ask first.
I coudn't find any info which return codes EAC expects (<0 and >0?) and which are considered as error codes. And I also don't know which return codes are used by all the encoders. So isn't it possible that an encoder returns a code which EAC interprets as error, but it isn't? Unfortunately I can't tell you any example were this happens.
If you think this explanation is needless, go ahead and delete it altogether.
Again, thanks for your help!
You're entirely welcome.
Fill up missing offset samples with silence
So this option is really essential when you want to use AR.
It was one of four settings that would disable AR altogether in V0.95. Only two of the four continue to disable AR in V0.99 and they are this one (which is actually tied to the overreading setting; at least one of them must be enabled for AR to work) and the delete leading and trailing silent blocks option. Needless to say, the fill up missing offset samples with silence setting should always be enabled. In the event that overreading is enabled, it does nothing.
I coudn't find any info which return codes EAC expects (<0 and >0?) and which are considered as error codes. And I also don't know which return codes are used by all the encoders. So isn't it possible that an encoder returns a code which EAC interprets as error, but it isn't? Unfortunately I can't tell you any example were this happens.
I think it's best just to stick to verifiable facts.
Thanks for the reply.
Little update:
freedb/database options (http://wiki.hydrogenaudio.org/index.php?title=EAC_freedb/Database_Options) added.
Nothing special here, only the following doesn't seem to work correctly in EAC:
Windows freedb file format (Default: enabled): This is a Windows-optimized file format with the advantage that a new file is not created for every entry in the database resulting in less waste of hard disk space. Unfortunately, this particular function does not seem to work properly in EAC. There is always a new file created for every CD entry.
Can anybody confirm this/reproduce the "error"?
New article: WAV editor options (http://wiki.hydrogenaudio.org/index.php?title=EAC_WAV_Editor_Options).
Next would be restructuring of EAC's drive options - but this could take a while...
Mods please delete my topic (http://www.hydrogenaudio.org/forums/index.php?showtopic=66173) since the suggestions there can be addressed here. (Sorry I just stumbled on this thread today.) (Done)
My main issue with the EAC guides are these statements in the Config Wizard guide:
Please note that the configuration done by the wizard is not sufficient for perfect rips. To achieve this, a manual configuration has to be done after finishing the wizard.
When perfect results are expected, we are not done after running through the EAC wizard, because many important options are not covered by the wizard.
Where exactly are these "many important options"?
Upon checking EAC Options (http://wiki.hydrogenaudio.org/index.php?title=EAC_Options) guide, I can only find one option recommended to be changed from the defaults (No use of null samples for CRC calculations) that is necessary to get the best rips possible. (Are there any others I missed?) I don't see why users need to wade through that much information to find that one recommendation.
The EAC Drive Options (http://wiki.hydrogenaudio.org/index.php?title=EAC_Drive_Configuration) guide also has a lot of information (including a recap of the config wizard) and only one of which is necessary: "Unless you know that you can use this setting (C2) reliably, disable it. If you choose to enable it, make sure you also use Test & Copy."
My suggestion really is to keep all the absolutely necessary information for ripping in one page. If people want to know what an option is and why a recommendation is recommended, they can read all about it in another page.
First of all: thanks for your PM.
Well, the most important EAC config page (drive configuration) is not finished (or revised) yet. I'm currently working on it (but I don't have much time, sorry), mostly to give some more background info and to fit in the other config guides.
When I got you right, you possibly want to have an EAC config page where a quick setup is described. Might be a good idea, but...
I don't think that there is only one way to corretly setup EAC. That really depends on personal preferences (e.g. use secure ripping mode or T&C). And I think that there are thousands of guides out there telling you how to onfigure EAC, but no one explains all the options in detal. But that's my intention.
So I can only describe all the EAC options in detail, so that everyone can find our his optimal settings on his own.
Maybe there will be a quick setup EAC guide somtimes in our HA wiki, you never know...
Drive feature descriptions in that article need no revision. You may want to gut the wizard section from the article if it's redundant.
Regarding Secure mode or T&C (I assume you mean T&C in conjunction with burst mode), it really shouldn't be an either/or situation. T&C in secure mode can sometimes reveal errors that would have otherwise gone undetected without T&C; not just for C2 rips, but non-C2 rips as well!
I think a quick setup guide is a great idea, so long as it is truly quick. It should do just as twostar is suggesting: run the wizard and list the settings which should be changed from the default. When it comes to what features your drive has and how it affects a ripping strategy, this might be a bit difficult. I suppose recommending people copy first (shift+F5), check for AR verification, and then perform a test pass (F8) if necessary. This is more efficient than T&C, though it does complicate the logging process. From there it only takes one sentence to tell people with a C2 rip where CRCs don't match to retry the rip without C2.
Drive feature descriptions in that article need no revision. You may want to gut the wizard section from the article if it's redundant.
Well, the drive options section is not completed. The current article only focuses on the most important options. I'll try to cover all the other settings as well. While doing this, I'll also make the drive options match the look and feel of the other settings pages.
But I'll keep that idea of an EAC quick guide in mind...
I think a quick setup guide is a great idea
how about uploading a good/basic cfg file and doing a link, 'click here for cfg'? or a reg.
maybe this http://portableapps.com/node/5583 (http://portableapps.com/node/5583) could be a start?
p.s. The guides could then focus on how to setup things for specific drive and on how to actually clicky around to get the desired results (like T&C mode secure vs T&C mode burst vs using my kitchen knife)
You would still have detect drive features even with a .cfg file.
I wrote up a quick setup guide. Most of it is copied and pasted from the existing wiki guides. Please feel free to add/edit and give feedback. Thanks.
-----------------------------------------------------------------------------------------------------
The purpose of this guide is to quickly and easily setup EAC and still get the best rips possible.
Before you start, download and unzip LAME (http://www.rarewares.org/mp3-lame-bundle.php) if you will be ripping to MP3.
Here are the steps of the install and configuration process:
1. Run the EAC V0.99 prebeta 4 installer available here (http://www.exactaudiocopy.de/en/index.php/resources/download/). Just keep clicking next until you finish. (Optionally you can opt not to install FLAC, CDRDAO and the eBay icons.)
2. When you first run EAC, it will start with a configuration wizard. The first option to pick is I prefer to have accurate results.
3. On the next page, click I don't trust these values, detect the features for my drive.
4. Now, insert an Audio CD (Original, factory-pressed CD only. No CD-Rs, CD-RWs or bootlegs.) into your drive. EAC will now perform some tests in order to determine your drive's capabilities, and display the results within a few minutes. Do not run any other hardware intensive program during detection.
5. Next you will asked to pick a codec. Either LAME (MP3) or FLAC is recommended. If you pick LAME, you will be asked to locate the LAME.EXE you unzipped earlier. Whichever codec you choose, have EAC use the recommended settings.
6. Enter any email address (even fake email addresses are ok) in the freedb configuration screen.
7. Next part is to select a file naming scheme of your preference.
8. Last option to pick is I am an expert, let me use the full potential of EAC.
9. Look for the Accuraterip icon on the bottom right of the EAC screen. If it's there, Accuraterip is already configured. If not, replace the CD with others in your collection until Accuraterip recognizes one with a pop-up message. Just click configure.
10. After Accuraterip is configured, click EAC, Drive Options and make sure Drive is capable of retrieving C2 error information is unchecked.
11. Then click EAC, EAC Options. In the extraction tab, make sure No use of null samples for CRC calculations is unchecked.
12. Optionally, in the extraction tab enable Automatically write status report after extraction.
Additional Information:
- Learn how to use EAC with other codecs here (http://wiki.hydrogenaudio.org/index.php?title=EAC_Compression_Options).
- If your CDs are in excellent condition, you can get faster rips by ripping with burst mode. A burst mode rip is secure if verified by Accuraterip.
If the CD cannot be verified by Accuraterip, perform a test rip (F8). If the CRC column indicates ok then the rip was secure.
Looks good to me. Only two thoughts:
In the first part, you generally describe the walkthrough of the wizard. In my opinion, this can be skipped and a link to the wizard page (http://wiki.hydrogenaudio.org/index.php?title=EAC_Configuration_Wizard) should be presented. OK, the single steps are covered a little bit more in detail there, but I think it's sufficient for a quick guide. Otherwise we create kind of redundant articles (again).
- If your CDs are in excellent condition, you can get faster rips by ripping with burst mode. A burst mode rip is secure if verified by Accuraterip.
If the CD cannot be verified by Accuraterip, perform a test rip (F8). If the CRC column indicates ok then the rip was secure.
You also can get accurate rips with CDs which are not in exelent condition (as long as verified by AR). So, I wouldn't mention this in a quick guide, because this is already part of the burst T&C vs. secure mode "diskussion".
>10. After Accuraterip is configured, click EAC, Drive Options and make sure Drive is capable of retrieving C2 error information is unchecked.
I advise against this. It will introduce the same problems as the Coaster Factory's quick start guide. People will take the suggestion as the be-all-end-all, when it is indeed possible to get accurate rips with the feature (sometimes even easier than not using the feature).
Thanks for the feedback exec and greynol.
@exec
Rather than link to the wizard page, can we rename the wizard page to the quick start guide and add the other recommendations?
@greynol
I forgot to copy this recommendation instead from the Drive Options guide: "Unless you know that you can use this setting (C2) reliably, disable it. If you choose to enable it, make sure you also use Test & Copy."
Setting the option to "high" will increase the possibility for EAC to get consistent data, but consistent data doesn't always translate to accurate data.
This totally wrong & a newbie idea,
HIGH will mean EAC will re-check the data more times than it would normally, the whole point of EAC's algorithms are based on re-reading data! (LOL) and that an error won't always occur at the same exact position, if you think more reads "doesn't translate into accurate data" then you shouldn't be using EAC at all
So the more re-reads the surer you can be EAC is right when it reports "No Errors Occurred"
HIGH will mean EAC will re-check the data more times than it would normally
Untrue. High means that EAC will attempt up to 5 sets of 16 re-reads before giving up. If EAC determines that it needs to perform re-reads and is able to get at least 8 out of 16 identical results on the first set it will move on without performing any additional re-reads on the questionable area. IOW, this particular situation would be no different than if the recovery were set to low.
So the more re-reads the surer you can be EAC is right when it reports "No Errors Occurred"
Complete and utter nonsense. I'll trust the "No Errors Occurred" message from a rip that requires re-reads with the recovery set to low long before I will trust a rip that requires re-reads with the recovery set to high when more than three rows of "Error correction" illuminate.
You're a bit confused, westgroveg. Besides the fact that you don't really seem to understand the differences between error recovery quality levels, it would also appear that you are completely ignorant of the fact that errors can (and often do) repeat themselves. The more chances you give EAC to perform re-reads, the greater the chance that it will pass bad data off as good when an error has consistency.
For your edification:
http://www.hydrogenaudio.org/forums/index....st&p=512047 (http://www.hydrogenaudio.org/forums/index.php?s=&showtopic=57021&view=findpost&p=512047)
...but don't just take my word when Spoon will tell you the same thing:
http://www.hydrogenaudio.org/forums/index....st&p=532158 (http://www.hydrogenaudio.org/forums/index.php?s=&showtopic=59290&view=findpost&p=532158)
if you think more reads "doesn't translate into accurate data" then you shouldn't be using EAC at all
...and there are plenty of people with drives capable of providing C2 pointers who don't for this very reason.
I thought I'd raise an issue with what seems to be inconsistent suggestions in the EAC Options wiki (http://wiki.hydrogenaudio.org/index.php?title=EAC_Options). My concern stemmed from a recommendation I gave in this post:
http://www.hydrogenaudio.org/forums/index....st&p=703050 (http://www.hydrogenaudio.org/forums/index.php?s=&showtopic=80583&view=findpost&p=703050)
I don't see why we are so conservative with starting external compressors queued in the background and yet suggest that the compression priority be set to high.