After greynol detected (and fixed) some errors in the HA-wiki regarding EAC articles (see this thread), 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

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.

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:

"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!



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?




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?




OK, but what happens if the drive is not able to retrieve these info? Will EAC freeze or crash?




This does also work with other file formats.




OK, will be changed...

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.

I was aware of 1, but not 2. Very interesting.

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.

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.


As always, some feedback would be highly appreciated!

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.




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.

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.

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).

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.




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:
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.

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:
Null samples anywhere within a track will not be counted; not just at the beginning or the end.

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.

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?




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.




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?

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.

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.

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

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 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.

Oh yes, you're right. So this option is really essential when you want to use AR.





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.

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 think it's best just to stick to verifiable facts.

Thanks for the reply.

Little update: freedb/database options added.

Nothing special here, only the following doesn't seem to work correctly in EAC:


Can anybody confirm this/reproduce the "error"?

New article: WAV editor options.

Next would be restructuring of EAC's drive options - but this could take a while...

Mods please delete my topic 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:



Where exactly are these "many important options"?

Upon checking 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 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.