IPB

Welcome Guest ( Log In | Register )

4 Pages V  < 1 2 3 4 >  
Reply to this topicStart new topic
Exact Audio Copy V0.99 prebeta 3, Updated Aug. 18. PB3 out.
Spikey
post Jul 4 2007, 07:47
Post #51





Group: Members
Posts: 113
Joined: 4-July 06
Member No.: 32545



So, worth upgrading yet?

Any news on when the next version will be out/what features are being planned (other than stopping 'reading' an ejected CD tongue.gif ) ?

Awesome work guys, AccurateRip is a neat addition. I'm so happy I found EAC (and HA!)

- Spike
Go to the top of the page
+Quote Post
hellokeith
post Jul 9 2007, 01:13
Post #52





Group: Members
Posts: 288
Joined: 14-August 06
Member No.: 34027



Does EAC work on Vista?
Go to the top of the page
+Quote Post
footballking3420
post Jul 9 2007, 03:57
Post #53





Group: Members
Posts: 56
Joined: 28-September 06
Member No.: 35719



QUOTE
Any news on when the next version will be out/what features are being planned (other than stopping 'reading' an ejected CD ) ?


On the official EAC forums, the creator said in one topic that it will take at least 3 months for the next version of EAC to be released.


--------------------
[url=http://filesharingpiracy.blogspot.com/][/url]
Go to the top of the page
+Quote Post
uli-76
post Jul 9 2007, 05:09
Post #54





Group: Members
Posts: 35
Joined: 1-February 03
From: Germany - nrw
Member No.: 4824



QUOTE
Does EAC work on Vista?
Yes, it works on Vista.


--------------------
EAC-Bundle -> http://ankhy.de/eac-bundle
Go to the top of the page
+Quote Post
Fandango
post Jul 9 2007, 16:49
Post #55





Group: Members
Posts: 1549
Joined: 13-August 03
Member No.: 8353



QUOTE (footballking3420 @ Jul 9 2007, 04:57) *
QUOTE
Any news on when the next version will be out/what features are being planned (other than stopping 'reading' an ejected CD ) ?


On the official EAC forums, the creator said in one topic that it will take at least 3 months for the next version of EAC to be released.

In the official release thread he also said that there will be a second prebeta very soon, but only bug fixes and it's not the next version.
Go to the top of the page
+Quote Post
smz
post Jul 10 2007, 14:23
Post #56





Group: Members
Posts: 601
Joined: 15-February 04
From: Venezia, Italia
Member No.: 12025



QUOTE (j8ee @ Jul 2 2007, 14:42) *
Is the AccurateRip.dll file in the EAC folder?


Sorry for not answering for such a long time. I've been out of town for a while...

Yes, AccuratRip.dll *IS* in the EAC folder.

Anyway, I must say that I'm experiencing other problems with my CD and DVD drives (InCD not working any more) so I suspect there could be something really wrong with my system. I plan to make a fresh install ASAP, then I'll let you know if my problems with AccurateRip still persist.

Many thanks.

Sergio


--------------------
Sergio
Revox B150 + (JBL 4301B | Sennheiser HD430)
Go to the top of the page
+Quote Post
Societal Eclipse
post Jul 11 2007, 01:20
Post #57





Group: Members
Posts: 222
Joined: 22-April 03
From: Fairfax, VA, USA
Member No.: 6127



CODE
From .log:

Track 10

Filename D:\Data\Audio Extraction\Borknagar - Empiricism - 10 - The View of Everlast.wav

Pre-gap length 0:00:01.72

Peak level 99.8 %
Test CRC 8CB6AD32
Copy CRC 8CB6AD32
Track not fully ripped for AccurateRip lookup
Copy OK

No errors occurred

End of status report


From .cue:


FILE "Borknagar - Empiricism - 10 - The View of Everlast.wav" WAVE
TRACK 10 AUDIO
TITLE "The View of Everlast"
PERFORMER "Borknagar"
INDEX 00 00:00:00
INDEX 01 00:01:72


This CD has one further track (#11 in EAC), a multimedia track that I did not rip. The extraction doesn't seem to have stopped early. Is this just some meaningless confusion on the program's part due to the mixed audio/data? This was in test/copy tracks mode if it matters.

This post has been edited by Societal Eclipse: Jul 11 2007, 01:22


--------------------
"Have you ever been with a woman? It's like death. You moan, you scream and then you start to beg for mercy, for salvation"
Go to the top of the page
+Quote Post
greynol
post Jul 11 2007, 03:01
Post #58





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



Based on your cue, it looks like you might be prepending gaps, though apending them probably isn't going to solve your problem.

Anyhow, this is another problem that I've verified with the new version. Hopefully Andre is fully aware of it, but it wouldn't hurt to drop a message over at Digital-Inn...

http://www.digital-inn.de/exact-audio-copy...1-released.html

This post has been edited by greynol: Jul 11 2007, 03:17


--------------------
Your eyes cannot hear.
Go to the top of the page
+Quote Post
Societal Eclipse
post Jul 11 2007, 05:22
Post #59





Group: Members
Posts: 222
Joined: 22-April 03
From: Fairfax, VA, USA
Member No.: 6127



I use Append Gaps to Previous Track (Default) and create cues of every type. I just grabbed that from the first cue I opened.

Would the gap between the last audio track and the next data track be considered part of the audio portion?

Someone already mentioned the "Track not fully ripped for AccurateRip lookup" part in that thread but he didn't explain the situation he got it from so I'll post there too.

This post has been edited by Societal Eclipse: Jul 11 2007, 05:27


--------------------
"Have you ever been with a woman? It's like death. You moan, you scream and then you start to beg for mercy, for salvation"
Go to the top of the page
+Quote Post
greynol
post Jul 11 2007, 08:23
Post #60





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



QUOTE (Societal Eclipse @ Jul 10 2007, 21:22) *
I use Append Gaps to Previous Track (Default) and create cues of every type. I just grabbed that from the first cue I opened.

This got me thinking about how EAC can now test ranges and made me wonder if it could use AR to check rips with gaps prepended, so I did some testing.

It seems that in the case where a track has a pregap that gets prepended and the next track has no pregap, AR will verify this track as accurate. The previous track will not verify as accurate since the pregap that is supposed to be appended to the end would be missing. I guess the prepended pregap simply gets ignored as if it were extra data included in a ripped range. I'm not sure if this is a good thing.

In the case where tracks with missing appended pregaps couldn't be verified, I would get the not fully ripped error, unless adjacent tracks were also ripped; in which case it would say they were not accurate. This is also consistent with the behavior of a ripped range.

QUOTE (Societal Eclipse @ Jul 10 2007, 21:22) *
Would the gap between the last audio track and the next data track be considered part of the audio portion?
Yes [the gap that is shown in a noncompliant cue, but not the lead-out/lead-in area between the two sessions (or whatever is the proper terminology)].

Despite the fact that the new version of EAC/AR can't look-up the last audio track on an enhanced disc, this track would be no different than if it had been extracted using a previous version of EAC which could look it up. This is assuming overreading is not enabled or overread samples from the lead-out are null, of course, since the new version of EAC can now overread these samples.

This post has been edited by greynol: Jul 11 2007, 09:05


--------------------
Your eyes cannot hear.
Go to the top of the page
+Quote Post
hybridfan
post Jul 11 2007, 11:17
Post #61





Group: Members
Posts: 160
Joined: 11-July 03
From: UK
Member No.: 7707



I was looking around CD's to rip and found that Dido "Life For Rent" gave me a strange error at the start, something about online AccurateRip but ripped ok, I think this is because it has some data as the last track sad.gif


--------------------
:Foobar 2000:
:MPC --standard:
:iRiver H320 Rockboxed:
Go to the top of the page
+Quote Post
greynol
post Jul 13 2007, 17:41
Post #62





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



QUOTE (greynol @ Jul 11 2007, 00:23) *
This got me thinking about how EAC can now test ranges and made me wonder if it could use AR to check rips with gaps prepended, so I did some testing.

"Testing" was the operative word here. After communicating this issue to Andre, I went back to generate some logs to post at Digital-Inn (which is currently down at the moment).

Seems that EAC/AR behavior is inconsistent between testing and copying tracks when gaps are prepended to the next track (see track 6)...

CODE
Gap handling : Appended to previous track

Track 4
Copy CRC CA12E747
Accurately ripped (confidence 13) [60C93C31]

Track 5
Copy CRC D0CBAB8F
Accurately ripped (confidence 13) [8999CC69]

Track 6
Pre-gap length 0:00:03.00

Copy CRC 6D02608B
Accurately ripped (confidence 13) [776D32F5]
------------------------------------------------------------
Gap handling : Appended to next track

Track 4
Copy CRC CA12E747
Accurately ripped (confidence 13) [60C93C31]

Track 5
Copy CRC 1AD2FBA9
Not accurately ripped (confidence 13) [3F16D318], but should be [8999CC69]

Track 6
Pre-gap length 0:00:03.00

Copy CRC B37ADF68
Not accurately ripped (confidence 13) [A722A42F], but should be [776D32F5]

Track 7
Copy CRC CE5862BF
Accurately ripped (confidence 13) [0ECC85AA]
------------------------------------------------------------
Gap handling : Appended to next track

Performing a test extraction only

Track 4
Test CRC CA12E747
Accurately ripped (confidence 13) [60C93C31]

Track 5
Test CRC 1AD2FBA9
Not accurately ripped (confidence 13) [3F16D318], but should be [8999CC69]

Track 6
Pre-gap length 0:00:03.00

Test CRC B37ADF68
Accurately ripped (confidence 13) [776D32F5]

Track 7
Test CRC CE5862BF
Accurately ripped (confidence 13) [0ECC85AA]

My previous post on the issue only took into account what happens when EAC is used to test tracks. I had no idea that the results would be different when the tracks were actually copied to the hard drive.

This post has been edited by greynol: Jul 13 2007, 17:51


--------------------
Your eyes cannot hear.
Go to the top of the page
+Quote Post
gsa999
post Jul 16 2007, 10:27
Post #63





Group: Members
Posts: 129
Joined: 8-May 06
Member No.: 30540



Hi
Just installed the new version of EAC (into a seperate folder) and tested ripping a CD into MP3 at 320. My settings on the external compression tag are:

-b 320
I also have the 320 k/bits/s set in the drop down box

Previously when viewing the tag in dbPoweramp it just had one Encoder Settings line which said "Constant bit rate 320 kbps (Insane)". I still have this line showing but I now have a second Encoder Settings line showing which says:

lame.exe -h -b 320-b 320 - does anyone know why it has a -h and why -b 320 appears twice.
I don't have - h in my command line options!

Also in the log file it says that I am using "Native Win32 interface for Win NT & 2000", but I am not. I have the Nero wnaspi32.dll installed and the Installed External Interface ASPI selection set.

Finally do I have to do anything special to get accuraterip working. It seems to load OK (says communicating with accuraterip) when a CD is inserted but I am not seeing any output either in the log or on screen about an accurate rip. I have the accuraterip.dll in the EAC folder. The drive settings are set to use AccurateRip. Even though I installed the new version into a seperate folder it has automatically picked up the correct offset for the drive though - can't work out how it would have done that! I also notice there is no AccurateRipCache folder.

Thanks
Go to the top of the page
+Quote Post
Synthetic Soul
post Jul 16 2007, 13:49
Post #64





Group: Super Moderator
Posts: 4887
Joined: 12-August 04
From: Exeter, UK
Member No.: 16217



QUOTE (gsa999 @ Jul 16 2007, 10:27) *
Hi
Just installed the new version of EAC (into a seperate folder) and tested ripping a CD into MP3 at 320. My settings on the external compression tag are:

-b 320
I also have the 320 k/bits/s set in the drop down box

Previously when viewing the tag in dbPoweramp it just had one Encoder Settings line which said "Constant bit rate 320 kbps (Insane)". I still have this line showing but I now have a second Encoder Settings line showing which says:

lame.exe -h -b 320-b 320 - does anyone know why it has a -h and why -b 320 appears twice.
I don't have - h in my command line options!
Do you have "LAME MP3 Encoder" selected, rather than "User Defined Encoder"?


--------------------
I'm on a horse.
Go to the top of the page
+Quote Post
knutinh
post Jul 17 2007, 00:10
Post #65





Group: Members
Posts: 569
Joined: 1-November 06
Member No.: 37047



Wouldnt the next logical step of accurate rip be that instead of actually ripping a CD, the user only slips in the disk long enough that the "ripping" application is positive that it is there, then instead of downloading a crc, you download a encrypted version of a complete, error-free rip with proper gaps and tags, that can only be decrypted by using the said random bits from your physical disk? =)

-k
Go to the top of the page
+Quote Post
Fandango
post Jul 17 2007, 01:18
Post #66





Group: Members
Posts: 1549
Joined: 13-August 03
Member No.: 8353



QUOTE (knutinh @ Jul 17 2007, 01:10) *
Wouldnt the next logical step of accurate rip be that instead of actually ripping a CD[...]? =)

No! dry.gif
Go to the top of the page
+Quote Post
greynol
post Jul 17 2007, 01:46
Post #67





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



I think the next logical step (in that direction at least) would be to reconstruct bad data using something similar to the way in which par2 works. Even still, we're talking about massive amounts of data. I would imagine there would be legal issues as well.


--------------------
Your eyes cannot hear.
Go to the top of the page
+Quote Post
Fandango
post Jul 17 2007, 02:59
Post #68





Group: Members
Posts: 1549
Joined: 13-August 03
Member No.: 8353



My guess is that it's also not going to happen.

First of all you have to realize that creating ECC data of CDs is highly inefficient because it is material that could be compressed quite nicely (~55-70%), therefore ECC data from compressed audio will also be smaller. And small ECC files is a top priority when we are dealing with ten to hundred thousands of CDs.

So is it possible to make use of lossless compression in combination with error correction? Probably, but it will have a negative effect on the redundancy: because even a small bit error in the uncompressed source can result in a big multi byte/kbyte/mbyte difference in the compressed output. And since it's the compressed image the ECC would be made from, using error recovery in combination with lossless compression doesn't seem to be so much more efficient than doing it with the original source after all. Read errors are random and unpredictable, when the erroneous audio is then compressed (on the user/client side) the parts that need to be corrected become even bigger, that's the problem.

So this leaves us with the uncompressed audio data which is usually between ~350MB and ~800MB for an album. Let's look at the worst case scenario, a full length CD.

I took the longest CD I had in my collection, that gave me a 792MB WAV file. As the redundancy level I used 2,5%, that should cover mildly damaged CDs or the usual CRC mismatches that can even occur on "brand-new" CDs, shouldn't it? IMHO this could be a horrible underestimination.

Using Quickpar 0.9 and tweaking the block size for the best efficiency, the ECC data would be 13,5MB. Now compare that to the few bytes of the current AR database entries, even the average album will demand much more storage space and especially traffic.

Ok, if we say that 20MB is the average size of the ECC data for average album and there will be 50.000 CDs in the database that also contain these error correction data, then this would need a relatively moderate amount 1TB disc space for a redundancy of 2,5%! But what if 2,5% is not enough? Why not 15%? And what's the "average" amount of unrecoverable sectors anyway? The AR project would need very good answers to questions like that and to other ones, too.

It would be a nice feature, if it could successfully recover otherwise unrecoverably damaged CDs, but I really doubt it is still possible to do this for free under the current circumstances of the project. A high redundancy would probably mean that you would have to pay for it. And if such a thing is a good business idea... I'm very sceptical. unsure.gif

PS: Of course, the error correction must be track based, but I ignored this for the sake of simplicity in my example.

This post has been edited by Fandango: Jul 17 2007, 03:17
Go to the top of the page
+Quote Post
greynol
post Jul 17 2007, 06:47
Post #69





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



QUOTE (Fandango @ Jul 16 2007, 18:59) *
Probably, but it will have a negative effect on the redundancy: because even a small bit error in the uncompressed source can result in a big multi byte/kbyte/mbyte difference in the compressed output.
With Monkey's Audio, absolutely, but this isn't the case with frame independent formats like flac and tak. But you're right, fixing a frame or two will take more data than fixing a few samples. To be honest, I didn't even think about it at this level of detail.

QUOTE (Fandango @ Jul 16 2007, 18:59) *
But what if 2,5% is not enough?
I'd say tough shit. Go buy another copy. wink.gif

QUOTE (Fandango @ Jul 16 2007, 18:59) *
It would be a nice feature, if it could successfully recover otherwise unrecoverably damaged CDs, but I really doubt it is still possible to do this for free under the current circumstances of the project.
I, for one, would never expect such a service to be free. Also, such a project wouldn't necessarily have anything to do with AR or Illustrate for that matter. I was only pondering the next step after AR from a technological standpoint.

QUOTE (Fandango @ Jul 16 2007, 18:59) *
And if such a thing is a good business idea... I'm very sceptical. unsure.gif
Just entertaining the idea, though I'm actually with you on this one...

QUOTE (greynol @ Jul 16 2007, 17:46) *
Even still, we're talking about massive amounts of data. I would imagine there would be legal issues as well.

...and this isn't exactly a new idea, nor is it an original one.

This post has been edited by greynol: Jul 17 2007, 06:48


--------------------
Your eyes cannot hear.
Go to the top of the page
+Quote Post
Fandango
post Jul 17 2007, 16:11
Post #70





Group: Members
Posts: 1549
Joined: 13-August 03
Member No.: 8353



Another thing that comes close to the ECC idea and is also more on topic again... plans for one of the next versions of EAC are to add consecutive re-reads of CDs also after the rip was finished unsuccessfully. So using two or more different drives on the same rip instead of creating a new rip for each attempt.

I can also imagine automatic read mode switching for when a track fails to verify would be a valuable feature... all in one go (i.e. ripping attempt). Well, we'll see in a year or two what Mr. Wiethoff has up his sleeve. wink.gif laugh.gif
Go to the top of the page
+Quote Post
gsa999
post Jul 17 2007, 19:43
Post #71





Group: Members
Posts: 129
Joined: 8-May 06
Member No.: 30540



QUOTE (Synthetic Soul @ Jul 16 2007, 13:49) *
Do you have "LAME MP3 Encoder" selected, rather than "User Defined Encoder"?

Yes I do have LAME MP3 Encoder set. If I have it set as User Defined Encoder it returns an error for the command line - b 320. I had it set as LAME MP3 Encoder in the old version of EAC
Go to the top of the page
+Quote Post
Synthetic Soul
post Jul 17 2007, 20:05
Post #72





Group: Super Moderator
Posts: 4887
Joined: 12-August 04
From: Exeter, UK
Member No.: 16217



QUOTE (gsa999 @ Jul 17 2007, 19:43) *
QUOTE (Synthetic Soul @ Jul 16 2007, 13:49) *
Do you have "LAME MP3 Encoder" selected, rather than "User Defined Encoder"?
Yes I do have LAME MP3 Encoder set. If I have it set as User Defined Encoder it returns an error for the command line - b 320. I had it set as LAME MP3 Encoder in the old version of EAC
That is why you are getting -b 320 twice. When using "LAME MP3 Encoder" EAC will fill in some of the command line itself, most petinently using the bitrate dropdown to set the -b switch, and (presumably) using the high/low quality radio buttons to set the -h switch. So you are adding -b 320 (additonal command line) and EAC is also adding -b 320 (from the bitrate dropdown).

Either remove the -b 320 from the additional command line parameters, or, as per the wiki, use "User defined encoder" and set the addional command line parameters to:

CODE
-b320 %s %d

As you are using "User defined encoder" the value of the bitrate dropdown will then be ignored - in fact EAC will not add anything else to the command line.


--------------------
I'm on a horse.
Go to the top of the page
+Quote Post
landy
post Jul 18 2007, 08:59
Post #73





Group: Members
Posts: 143
Joined: 3-January 05
Member No.: 18805



sorry for not reading all the post but have they added an open/close tray feature (not mentioned in the list in the first post)? i would kill for that as atm i have to use imgburn and its open close tray buttons because my tray is covered and the external button does not trigger the button on my dvd drive
Go to the top of the page
+Quote Post
Keykey
post Jul 18 2007, 14:21
Post #74





Group: Members
Posts: 80
Joined: 20-January 05
Member No.: 19190



I am starting to get tired of this "accuraterip" thingie dry.gif

CODE
Exact Audio Copy V0.99 prebeta 1 from 25. May 2007

EAC extraction logfile from 18. July 2007, 15:09

Black Stone Cherry / Black Stone Cherry

Used drive : PLEXTOR CD-R PREMIUM Adapter: 1 ID: 0

Read mode : Secure
Utilize accurate stream : Yes
Defeat audio cache : Yes
Make use of C2 pointers : No

Read offset correction : 30
Overread into Lead-In and Lead-Out : Yes
Fill up missing offset samples with silence : Yes
Delete leading and trailing silent blocks : No
Used interface : Installed external ASPI interface

Used output format : User Defined Encoder
Selected bitrate : 32 kBit/s
Quality : High
Add ID3 tag : No
Command line compressor : C:\Archivos de programa\Exact Audio Copy\wapet.exe
Additional command line options : %d -t "Artist=%a" -t "Title=%t" -t "Album=%g" -t "Year=%y" -t "Track=%n" -t "Genre=%m" mac.exe %s %d -c3000


TOC of the extracted CD

Track | Start | Length | Start sector | End sector
---------------------------------------------------------
1 | 0:00.00 | 3:24.57 | 0 | 15356
2 | 3:24.57 | 3:06.38 | 15357 | 29344
3 | 6:31.20 | 3:50.53 | 29345 | 46647
4 | 10:21.73 | 3:47.03 | 46648 | 63675
5 | 14:09.01 | 3:35.57 | 63676 | 79857
6 | 17:44.58 | 3:36.02 | 79858 | 96059
7 | 21:20.60 | 3:12.19 | 96060 | 110478
8 | 24:33.04 | 4:01.74 | 110479 | 128627
9 | 28:35.03 | 3:05.21 | 128628 | 142523
10 | 31:40.24 | 3:23.35 | 142524 | 157783
11 | 35:03.59 | 3:15.61 | 157784 | 172469
12 | 38:19.45 | 3:04.49 | 172470 | 186318
13 | 41:24.19 | 4:59.05 | 186319 | 208748


Range status and errors

Selected range

Filename C:\RIPEOS EAC\Black Stone Cherry - Black Stone Cherry.wav

Peak level 96.6 %
Range quality 99.9 %
Test CRC 8D5B5030
Copy CRC 8D5B5030
Copy OK


AccurateRip summary

Track 1 not ripped accurately (confidence 2) [84FDF9AE], but should be [FB7BADB3]
Track 2 not ripped accurately (confidence 2) [B14B058F], but should be [0BACEEC7]
Track 3 not ripped accurately (confidence 3) [039DDA42], but should be [8E43B458]
Track 4 not ripped accurately (confidence 2) [8AF11500], but should be [C8ABE228]
Track 5 not ripped accurately (confidence 2) [BAB00501], but should be [160EF745]
Track 6 not ripped accurately (confidence 2) [7FD8E5C2], but should be [4E4A231F]
Track 7 not ripped accurately (confidence 2) [3AAACB21], but should be [CB67F5D7]
Track 8 not ripped accurately (confidence 2) [75769552], but should be [A67CDE2B]
Track 9 not ripped accurately (confidence 2) [18309262], but should be [8FDD7F12]
Track 10 not ripped accurately (confidence 2) [05F0B14A], but should be [F8EE8DF9]
Track 11 not ripped accurately (confidence 2) [78D79C20], but should be [0147FFE2]
Track 12 not ripped accurately (confidence 2) [DB6FD94C], but should be [94317C71]
Track 13 not ripped accurately (confidence 2) [8915171B], but should be [E0ECBABD]

Not all tracks ripped accurately

End of status report


I just don't believe it. My drive is one of the best available and I have never seen it do a bad rip and I have done hundreds... The drive is properly configured in Secure Mode.

May I be wrong in my appreciations?? blink.gif

EDIT

OK. More fuel to the fire tongue.gif
Ripped again the CD with my other Plextor unit. Result:
CODE
Exact Audio Copy V0.99 prebeta 1 from 25. May 2007

EAC extraction logfile from 18. July 2007, 15:43

Black Stone Cherry / Black Stone Cherry

Used drive : PLEXTOR CD-R PX-W4012A Adapter: 3 ID: 0

Read mode : Secure
Utilize accurate stream : Yes
Defeat audio cache : Yes
Make use of C2 pointers : No

Read offset correction : 98
Overread into Lead-In and Lead-Out : Yes
Fill up missing offset samples with silence : Yes
Delete leading and trailing silent blocks : No
Used interface : Installed external ASPI interface

Used output format : User Defined Encoder
Selected bitrate : 32 kBit/s
Quality : High
Add ID3 tag : No
Command line compressor : C:\Archivos de programa\Exact Audio Copy\wapet.exe
Additional command line options : %d -t "Artist=%a" -t "Title=%t" -t "Album=%g" -t "Year=%y" -t "Track=%n" -t "Genre=%m" mac.exe %s %d -c3000


TOC of the extracted CD

Track | Start | Length | Start sector | End sector
---------------------------------------------------------
1 | 0:00.00 | 3:24.57 | 0 | 15356
2 | 3:24.57 | 3:06.38 | 15357 | 29344
3 | 6:31.20 | 3:50.53 | 29345 | 46647
4 | 10:21.73 | 3:47.03 | 46648 | 63675
5 | 14:09.01 | 3:35.57 | 63676 | 79857
6 | 17:44.58 | 3:36.02 | 79858 | 96059
7 | 21:20.60 | 3:12.19 | 96060 | 110478
8 | 24:33.04 | 4:01.74 | 110479 | 128627
9 | 28:35.03 | 3:05.21 | 128628 | 142523
10 | 31:40.24 | 3:23.35 | 142524 | 157783
11 | 35:03.59 | 3:15.61 | 157784 | 172469
12 | 38:19.45 | 3:04.49 | 172470 | 186318
13 | 41:24.19 | 4:59.05 | 186319 | 208748


Range status and errors

Selected range

Filename C:\RIPEOS EAC\Black Stone Cherry - Black Stone Cherry.wav

Peak level 96.6 %
Range quality 99.9 %
Test CRC 8D5B5030
Copy CRC 8D5B5030
Copy OK

No errors occurred

End of status report


Test and Copy CRCs match in both rips so I don't think my rips are "inaccurate" as that thingie tries to make me believe. I think I am definitely quitting that "new EAC feature" unless somebody proves me wrong.

Greetings.

Moderation: CODE to CODEBOX


This post has been edited by Synthetic Soul: Jul 18 2007, 14:54
Go to the top of the page
+Quote Post
bryanb
post Jul 18 2007, 14:49
Post #75





Group: Members
Posts: 20
Joined: 20-December 03
From: Austin, TX
Member No.: 10587



QUOTE (Keykey @ Jul 18 2007, 08:21) *
Read offset correction : 30
Overread into Lead-In and Lead-Out : Yes
Fill up missing offset samples with silence : Yes
Delete leading and trailing silent blocks : No
Used interface : Installed external ASPI interface


I was seeing similar behavior and when reading the AccurateRip page on the EAC site, one of the bullets says:
  • If the option “Remove leading and trailing silence” is disabled, most probably not the full track is extracted and can not be checked against the AccurateRip database

I see where you have it disabled in your config. I originally had it disabled too and after turning it back on, my results have been better.


Bryan
Go to the top of the page
+Quote Post

4 Pages V  < 1 2 3 4 >
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: 2nd October 2014 - 11:50