Skip to main content

Notice

Please note that most of the software linked on this forum is likely to be safe to use. If you are unsure, feel free to ask in the relevant topics, or send a private message to an administrator or moderator. To help curb the problems of false positives, or in the event that you do find actual malware, you can contribute through the article linked here.
Topic: Restucturing/adding EAC related articles (Read 30901 times) previous topic - next topic
0 Members and 1 Guest are viewing this topic.

Restucturing/adding EAC related articles

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!

Restucturing/adding EAC related articles

Reply #1
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...

Restucturing/adding EAC related articles

Reply #2
Briefly looking at the site I noticed this:

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

Restucturing/adding EAC related articles

Reply #3
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...

Restucturing/adding EAC related articles

Reply #4
"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).

Restucturing/adding EAC related articles

Reply #5
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.

Restucturing/adding EAC related articles

Reply #6
Bump.

New article finished: EAC compression options.


As always, some feedback would be highly appreciated!

Restucturing/adding EAC related articles

Reply #7
New article finished: 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.

Restucturing/adding EAC related articles

Reply #8
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?

Restucturing/adding EAC related articles

Reply #9
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.

Restucturing/adding EAC related articles

Reply #10
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...

Restucturing/adding EAC related articles

Reply #11
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. 


Restucturing/adding EAC related articles

Reply #13
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).

Restucturing/adding EAC related articles

Reply #14
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).

Restucturing/adding EAC related articles

Reply #15
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?

Restucturing/adding EAC related articles

Reply #16
More errors in EAC options:

From Fill up missing offset samples with silence:
Quote
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.

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

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

Restucturing/adding EAC related articles

Reply #17
From Fill up missing offset samples with silence:
Quote
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?


Quote
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?

Restucturing/adding EAC related articles

Reply #18
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

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.

Restucturing/adding EAC related articles

Reply #19
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.

Restucturing/adding EAC related articles

Reply #20
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 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!

Restucturing/adding EAC related articles

Reply #21
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.

Restucturing/adding EAC related articles

Reply #22
Little update: freedb/database options added.

Nothing special here, only the following doesn't seem to work correctly in EAC:
Quote
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"?

Restucturing/adding EAC related articles

Reply #23
New article: WAV editor options.

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

Restucturing/adding EAC related articles

Reply #24
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:
Quote
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.

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