IPB

Welcome Guest ( Log In | Register )

2 Pages V   1 2 >  
Reply to this topicStart new topic
Restucturing/adding EAC related articles
exec
post Aug 17 2007, 11:19
Post #1





Group: Members
Posts: 204
Joined: 30-January 07
From: Germany
Member No.: 40168



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 wink.gif), feel free to edit the relating article. You help is highly appreciated!

This post has been edited by exec: Aug 17 2007, 13:32
Go to the top of the page
+Quote Post
exec
post Jan 14 2008, 00:02
Post #2





Group: Members
Posts: 204
Joined: 30-January 07
From: Germany
Member No.: 40168



Hey guys, I'm still alive. laugh.gif 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...
Go to the top of the page
+Quote Post
greynol
post Jan 14 2008, 00:26
Post #3





Group: Super Moderator
Posts: 10000
Joined: 1-April 04
From: San Francisco
Member No.: 13167



Briefly looking at the site I noticed this:

QUOTE
Error recovery priority
(Default: Medium, Recommended: High)
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).


--------------------
I should publish a list of forum idiots.
Go to the top of the page
+Quote Post
exec
post Jan 14 2008, 12:36
Post #4





Group: Members
Posts: 204
Joined: 30-January 07
From: Germany
Member No.: 40168



Thanks for the feedback, greynol!

QUOTE (greynol @ Jan 14 2008, 00:26) *
"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?


QUOTE (greynol @ Jan 14 2008, 00:26) *
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?


QUOTE (greynol @ Jan 14 2008, 00:26) *
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?


QUOTE (greynol @ Jan 14 2008, 00:26) *
Create '.m3u' playlist on extraction produces playlists for wave files only, unless this changed recently.


This does also work with other file formats.


QUOTE (greynol @ Jan 14 2008, 00:26) *
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...
Go to the top of the page
+Quote Post
greynol
post Jan 14 2008, 18:11
Post #5





Group: Super Moderator
Posts: 10000
Joined: 1-April 04
From: San Francisco
Member No.: 13167



QUOTE (exec @ Jan 14 2008, 03:36) *
QUOTE (greynol @ Jan 14 2008, 00:26) *
"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.

QUOTE (exec @ Jan 14 2008, 03:36) *
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.

QUOTE (exec @ Jan 14 2008, 03:36) *
QUOTE (greynol @ Jan 14 2008, 00:26) *
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.

QUOTE (exec @ Jan 14 2008, 03:36) *
QUOTE (greynol @ Jan 14 2008, 00:26) *
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).

This post has been edited by greynol: Jan 14 2008, 18:12


--------------------
I should publish a list of forum idiots.
Go to the top of the page
+Quote Post
exec
post Jan 15 2008, 15:25
Post #6





Group: Members
Posts: 204
Joined: 30-January 07
From: Germany
Member No.: 40168



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.
Go to the top of the page
+Quote Post
exec
post Jan 23 2008, 15:15
Post #7





Group: Members
Posts: 204
Joined: 30-January 07
From: Germany
Member No.: 40168



Bump.

New article finished: EAC compression options.


As always, some feedback would be highly appreciated!
Go to the top of the page
+Quote Post
greynol
post Jan 23 2008, 19:23
Post #8





Group: Super Moderator
Posts: 10000
Joined: 1-April 04
From: San Francisco
Member No.: 13167



QUOTE (exec @ Jan 23 2008, 06:15) *
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.


--------------------
I should publish a list of forum idiots.
Go to the top of the page
+Quote Post
exec
post Jan 24 2008, 17:16
Post #9





Group: Members
Posts: 204
Joined: 30-January 07
From: Germany
Member No.: 40168



Thanks again greynol (my only friend when it comes to feedback on my articles wink.gif)!


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.


QUOTE (greynol @ Jan 23 2008, 19:23) *
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?
Go to the top of the page
+Quote Post
greynol
post Jan 24 2008, 17:27
Post #10





Group: Super Moderator
Posts: 10000
Joined: 1-April 04
From: San Francisco
Member No.: 13167



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.


--------------------
I should publish a list of forum idiots.
Go to the top of the page
+Quote Post
exec
post Jan 24 2008, 17:43
Post #11





Group: Members
Posts: 204
Joined: 30-January 07
From: Germany
Member No.: 40168



QUOTE (greynol @ Jan 24 2008, 17:27) *
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...
Go to the top of the page
+Quote Post
greynol
post Jan 25 2008, 04:09
Post #12





Group: Super Moderator
Posts: 10000
Joined: 1-April 04
From: San Francisco
Member No.: 13167



Well I tip my hat to you for trying. smile.gif

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


--------------------
I should publish a list of forum idiots.
Go to the top of the page
+Quote Post
rohangc
post Jan 25 2008, 05:20
Post #13





Group: Members
Posts: 570
Joined: 1-December 02
From: India
Member No.: 3948



QUOTE (exec @ Jan 13 2008, 18:02) *
So, here's the next big block: The EAC options dialog.


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!
Go to the top of the page
+Quote Post
greynol
post Jan 25 2008, 07:10
Post #14





Group: Super Moderator
Posts: 10000
Joined: 1-April 04
From: San Francisco
Member No.: 13167



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

This post has been edited by greynol: Jan 25 2008, 07:27


--------------------
I should publish a list of forum idiots.
Go to the top of the page
+Quote Post
spoon
post Jan 25 2008, 10:16
Post #15


dBpowerAMP developer


Group: Developer (Donating)
Posts: 2749
Joined: 24-March 02
Member No.: 1615



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


--------------------
Spoon http://www.dbpoweramp.com
Go to the top of the page
+Quote Post
exec
post Jan 25 2008, 11:49
Post #16





Group: Members
Posts: 204
Joined: 30-January 07
From: Germany
Member No.: 40168



QUOTE (greynol @ Jan 25 2008, 07:10) *
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.


QUOTE (spoon @ Jan 25 2008, 10:16) *
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?
Go to the top of the page
+Quote Post
greynol
post Jan 26 2008, 04:06
Post #17





Group: Super Moderator
Posts: 10000
Joined: 1-April 04
From: San Francisco
Member No.: 13167



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.


--------------------
I should publish a list of forum idiots.
Go to the top of the page
+Quote Post
exec
post Jan 26 2008, 12:50
Post #18





Group: Members
Posts: 204
Joined: 30-January 07
From: Germany
Member No.: 40168



QUOTE (greynol @ Jan 26 2008, 04:06) *
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 (greynol @ Jan 26 2008, 04:06) *
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. wink.gif
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.


QUOTE (greynol @ Jan 26 2008, 04:06) *
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?

This post has been edited by exec: Jan 26 2008, 14:02
Go to the top of the page
+Quote Post
greynol
post Jan 26 2008, 18:51
Post #19





Group: Super Moderator
Posts: 10000
Joined: 1-April 04
From: San Francisco
Member No.: 13167



QUOTE (exec @ Jan 26 2008, 03:50) *
QUOTE (greynol @ Jan 26 2008, 04:06) *
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. wink.gif

QUOTE (exec @ Jan 26 2008, 03:50) *
QUOTE (greynol @ Jan 26 2008, 04:06) *
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. wink.gif
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.

QUOTE (exec @ Jan 26 2008, 03:50) *
QUOTE (greynol @ Jan 26 2008, 04:06) *
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

QUOTE (exec @ Jan 26 2008, 03:50) *
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.

This post has been edited by greynol: Jan 26 2008, 18:55


--------------------
I should publish a list of forum idiots.
Go to the top of the page
+Quote Post
greynol
post Jan 27 2008, 21:16
Post #20





Group: Super Moderator
Posts: 10000
Joined: 1-April 04
From: San Francisco
Member No.: 13167



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.

This post has been edited by greynol: Jan 27 2008, 21:44


--------------------
I should publish a list of forum idiots.
Go to the top of the page
+Quote Post
exec
post Jan 28 2008, 14:07
Post #21





Group: Members
Posts: 204
Joined: 30-January 07
From: Germany
Member No.: 40168



QUOTE (greynol @ Jan 26 2008, 18:51) *
QUOTE (exec @ Jan 26 2008, 03:50) *
QUOTE (greynol @ Jan 26 2008, 04:06) *
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. wink.gif


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



QUOTE (greynol @ Jan 27 2008, 21:16) *
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!
Go to the top of the page
+Quote Post
greynol
post Jan 28 2008, 17:30
Post #22





Group: Super Moderator
Posts: 10000
Joined: 1-April 04
From: San Francisco
Member No.: 13167



You're entirely welcome.

QUOTE (exec @ Jan 28 2008, 05:07) *
QUOTE (greynol @ Jan 26 2008, 04:06) *
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.

QUOTE (exec @ Jan 28 2008, 05:07) *
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.

This post has been edited by greynol: Jan 28 2008, 18:13


--------------------
I should publish a list of forum idiots.
Go to the top of the page
+Quote Post
exec
post Jan 28 2008, 22:19
Post #23





Group: Members
Posts: 204
Joined: 30-January 07
From: Germany
Member No.: 40168



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

This post has been edited by exec: Jan 28 2008, 22:20
Go to the top of the page
+Quote Post
exec
post Feb 4 2008, 20:15
Post #24





Group: Members
Posts: 204
Joined: 30-January 07
From: Germany
Member No.: 40168



New article: WAV editor options.

Next would be restructuring of EAC's drive options - but this could take a while...
Go to the top of the page
+Quote Post
twostar
post Oct 6 2008, 15:43
Post #25





Group: Members
Posts: 487
Joined: 5-August 02
From: Manila
Member No.: 2939



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.

This post has been edited by Synthetic Soul: Oct 6 2008, 16:08
Go to the top of the page
+Quote Post

2 Pages V   1 2 >
Reply to this topicStart new topic
1 User(s) are reading this topic (1 Guests and 0 Anonymous Users)
0 Members:

 



RSS Lo-Fi Version Time is now: 23rd September 2014 - 23:43