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: Exact Audio Copy V0.99 prebeta 3 (Read 115085 times) previous topic - next topic
0 Members and 1 Guest are viewing this topic.

Exact Audio Copy V0.99 prebeta 3

Reply #50 –
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  ) ?

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

- Spike

Exact Audio Copy V0.99 prebeta 3

Reply #51 –
Does EAC work on Vista?

Exact Audio Copy V0.99 prebeta 3

Reply #52 –
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.

Exact Audio Copy V0.99 prebeta 3

Reply #54 –
Quote from: footballking3420 on
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.

Exact Audio Copy V0.99 prebeta 3

Reply #55 –
Quote from: j8ee on
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
M-Audio Delta AP + Revox B150 + (JBL 4301B | Sennheiser Amperior | Sennheiser HD598)

Exact Audio Copy V0.99 prebeta 3

Reply #56 –
Code: [Select]
[color=#FF0000]From .log:[/color]

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
     [b]Track not fully ripped for AccurateRip lookup[/b]
     Copy OK

No errors occurred

End of status report


[color=#FF0000]From .cue:[/color]


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

Exact Audio Copy V0.99 prebeta 3

Reply #57 –
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

Exact Audio Copy V0.99 prebeta 3

Reply #58 –
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.
"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"

Exact Audio Copy V0.99 prebeta 3

Reply #59 –
Quote from: Societal Eclipse on
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 from: Societal Eclipse on
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.

Exact Audio Copy V0.99 prebeta 3

Reply #60 –
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
:Foobar 2000:
:MPC --standard:
:iRiver H320 Rockboxed:

Exact Audio Copy V0.99 prebeta 3

Reply #61 –
Quote from: greynol on
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: [Select]
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.

Exact Audio Copy V0.99 prebeta 3

Reply #62 –
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

Exact Audio Copy V0.99 prebeta 3

Reply #63 –
Quote from: gsa999 on
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.

Exact Audio Copy V0.99 prebeta 3

Reply #64 –
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
 

Exact Audio Copy V0.99 prebeta 3

Reply #66 –
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.

Exact Audio Copy V0.99 prebeta 3

Reply #67 –
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.

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

Exact Audio Copy V0.99 prebeta 3

Reply #68 –
Quote from: Fandango on
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 from: Fandango on
But what if 2,5% is not enough?
I'd say tough shit. Go buy another copy.

Quote from: Fandango on
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 from: Fandango on
And if such a thing is a good business idea... I'm very sceptical.
Just entertaining the idea, though I'm actually with you on this one...

Quote from: greynol on
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.

Exact Audio Copy V0.99 prebeta 3

Reply #69 –
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. 

Exact Audio Copy V0.99 prebeta 3

Reply #70 –
Quote from: Synthetic Soul on
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

Exact Audio Copy V0.99 prebeta 3

Reply #71 –
Quote from: gsa999 on
Quote from: Synthetic Soul on
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: [Select]
-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.

Exact Audio Copy V0.99 prebeta 3

Reply #72 –
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

Exact Audio Copy V0.99 prebeta 3

Reply #73 –
I am starting to get tired of this "accuraterip" thingie 

Code: [Select]
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?? 

EDIT

OK. More fuel to the fire 
Ripped again the CD with my other Plextor unit. Result:
Code: [Select]
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.
[!--sizeo:1--][span style=\"font-size:8pt;line-height:100%\"][!--/sizeo--]
Moderation: CODE to CODEBOX[/size]

Exact Audio Copy V0.99 prebeta 3

Reply #74 –
Quote from: Keykey on
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