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: AccurateRip reports errors, EAC doesn't (Read 13957 times) previous topic - next topic
0 Members and 1 Guest are viewing this topic.

AccurateRip reports errors, EAC doesn't

I've been setting ripping process on my laptop machine and was testing different software and settings.
Most of the time I was ripping the same CD, Chris Isaac's Forever Blue.
And it was always ripped O.K., verified by AccurateRip.
Then I decided to set up my desktop PC with the same settings, so instead of copying screen by screen, I saved all setting in a config/profile file on laptop and then I moved that file onto desktop PC and loaded settings.
Then I tried to rip the same CD and EAC reported that there were no errors, but AccurateRip reported ** Rip not accurate ** on several tracks.
That was strange, so I tried again and I've got the same error but on the different tracks.
I had detected drive read features ant they were:
- drive supports Accurate Stream
- driive doesn't cache audio data
- drive is capable of retrieving C2 error info.
I also tested with damaged CD and it was retrieving C2 info.
However, I thought that for some reason that might be misdetected, so I tried changing cache setting and C2 error setting in various combinations and ripping CD. Process was slower, but still, I was getting errors on different tracks.
I thought that it might be because when I copied profile, it copied full settings including drive settings, so I renamed two AccurateRip files in EAC (I don't know how alse to uninstall it) and restarted EAC. Then I renamed  them back. That re-installed AccurateRip, but I haven't noticed that it downloaded drive capabilities from AccurateRip database, like it did at the first installation.
Anyway, it still haven't helped. There were still errors in ripping.
Then, as a last resort, because I ran out of ideas, I cleaned CD with cleaning fluid and I finally got correct rip.
Now, I'm really puzzled.
The disc looked like new before cleaning, almost never played, and I chose it because it existed in AccurateRip database with high confidence (33).
1. But even if it was dirty. Shouldn't EAC in that case report some kind of error in it's report? Report always ended with "No errors occured", but CRCs didn't match with AccurateRip.
2. I thought if I have different pressing, where all the tracks report different CRC like in this report, that I can asume that CD is ripped O.K. if EAC doesn't report an error.
But this shows that if such disc is dirty then error due to dirt will pass unnoticed.
3. If I rip CD that doesn't exist in AccurateRip database (or has different pressing) on two different machines (laptop and desktop), and I get the same AccurateRip CRC results, can I consider it ripped correctly then?
I have many such CDs.
4. What happens with drive settings when you copy full profile from one machine to another with different drive?
Some of the drive settings are different and even locked by AccurateRip.

My desktop drive is NEC DVD_RW ND-3520A

AccurateRip reports errors, EAC doesn't

Reply #1
If the CD reported accurate on one machine (by accuraterip), and not on another, then you can be sure:

it is in the database
it is being ripped inaccurately (on the otehr machine).

AccurateRip reports errors, EAC doesn't

Reply #2
First, you can trust EAC's test to determine if the "Drive caches audio data setting" should be enabled.

Second, NEC ND-35XX drives do NOT provide reliable C2 error information to EAC.  Furthermore, EAC's  "Examine C2 Feature" routine will not tell you whether the C2 error information setting can be used reliably.

Third, EAC's "No errors occured" message is pretty useless (besides being misspelled).

Fourth, AccurateRip CRCs will likely never match EAC CRCs since they are calculated using a different algorithm.

Fifth, use EAC's test and copy function when AccurateRip can't verify that  all of the tracks are extracted accurately.  There are further iterations on this theme that give more trustworthy results that involve switching between burst and secure modes and/or generating test CRCs using different drives.  Test and copy CRCs don't guarantee an accurate rip because it is possible for errors to be consistent.  Using different drives can help in reducing the likelihood of consistent errors so long as they are based on completely different chipsets.

AccurateRip reports errors, EAC doesn't

Reply #3
Did you adjust the drives read offset on your PC?

AccurateRip reports errors, EAC doesn't

Reply #4
I have the same drive. Its read offset is +48, so check if that's what your drive has been detected to use.

I don't know if it is of any importance, but I'm running the latest firmware for this drive, which is version 3.07. NEC provides firmware updaters on their site.

AccurateRip reports errors, EAC doesn't

Reply #5
I have the same drive. Its read offset is +48, so check if that's what your drive has been detected to use.

I don't know if it is of any importance, but I'm running the latest firmware for this drive, which is version 3.07. NEC provides firmware updaters on their site.


Thanks.
AccurateRip, when installed, found my drive in it's database and set it on +48.
I never updated drive's firmware, so that's the next step.

AccurateRip reports errors, EAC doesn't

Reply #6
I have updated drive's firmware and first ripping went O.K.
We'll see.

AccurateRip reports errors, EAC doesn't

Reply #7
It happened again, with updated drive's firmware.
This time with different CD ABBA Gold Greatest Hits.
There was a mismatch on one track.
In the second ripping it was all fine.
But, without AccurateRip, I wouldn't know.
Now, it seems that my drive/EAC is fairly unreliable, and for the discs that don't exist in AccurateRip database, I'll be highly suspicious that they are ripped O.K., because I cannot rely on EAC's reports.

Therefore, for such discs that don't exist in AccurateRip's database, the best procedure I can think of would be:

1. Rip them with dbPowerAmp
2. Physical discs that are ripped O.K. I mark with soft tip pen. The ones that AccurateRip doesn't have in database, I leave unmarked.
3. dbPowerAmp stores AccurateRip report in ripping log, equivalent to EAC's ripping log file.
4. dbPowerAmp renames such log files so they are easily recognised e.g. "ABBA Gold Greatest Hits - unconfirmed"
5. dbPowerAmp automatically at a preset time, or manually, looks for such files in a defined folder structure and  compares them with AccurateRip's database to check if they have been added to the database in the meantime.
6. If it finds them it compares results and if they are the same it renames log file so it has it's regular name e.g. removes "- unconfirmed".
7. If the results are different it doesn't touch log file.
8. If the disc still doesn't exist in the database, it doesn't do anything.
9. In all three cases (under 6, 7, 8), it produces report.
10. According to the report, for the
(6) discs that are confirmed I label physical discs with soft tip pen.
(7) discs that differ, I try to clean and re-rip using different tecniques until I get a matching rip.
(8) do nothing, check later in a few months time again. 

Is something like this possible?

I put dbPowerAmp in process because I know that EAC cannot automatically AccurateRip's results.
Even if I store such results manually using copy-paste, do you know if it's possible to access AccurateRip's database in any form later, to compare results?

For the AccurateRip's logs to work with EAC, wouldn't it be possible to rewrite AccurateRip to e.g. write it's report into file, when you click on O.K. with some file name like AccurateRipCDxxxxxxxxxx.log, where xxxxxxxx can be disc ID.
Then the other tools like REACT, MAREO, etc. can take care of such file and move it further.
It would be nicer, of course, to have album name in filename instead, but developers complained that communication between EAC and AccurateRip is a problem, and EAC needs to be re-written too.
With discID in filename, no info from EAC is needed, nor editing AR database either (I hope).

AccurateRip reports errors, EAC doesn't

Reply #8
dBpoweramp R12 will write an accurateRip result to the ID tag of the file, later I will release a program which can scan for unconfirmed tracks against the database.

AccurateRip reports errors, EAC doesn't

Reply #9
dBpoweramp R12 will write an accurateRip result to the ID tag of the file, later I will release a program which can scan for unconfirmed tracks against the database.


But it's not possible with the current version, as I understand.
Which tags will be supported?
ID3v2? APEv2?
And which file formats will be supported?
mp3? FLAC?
I don't see a big reason why it has to be written in a tag.
Probabbly it would be easier to implement, if it just writes what is already displayed on a screen, in a log file as ascii.
And it would work for both dbPowerAmp and EAC, unless it's intentional not to work with EAC. 
There are more programmers available, who can write utils handling ascii files, then the ones who can process tags.
I believe that someone can easily write a script that will insert tag from ASCII file using REACT, or something equivalent with dbPowerAmp.
Also, you wouldn't need any utility or to open each file to verify that CD was ripped O.K. if you want to check later.

AccurateRip reports errors, EAC doesn't

Reply #10
Disable C2 in EACs settings. It might be that the drive doesn't provide for reliable C2 information. I didn't observe this my drive though, but I only started using AccurateRip recently.

AccurateRip reports errors, EAC doesn't

Reply #11
Disable C2 in EACs settings. It might be that the drive doesn't provide for reliable C2 information. I didn't observe this my drive though, but I only started using AccurateRip recently.


If you read my first post, you'll see that I already did that, as well as caching and different combinations of those. 

AccurateRip reports errors, EAC doesn't

Reply #12
mp3 / flac, id3v2, ape2 all supported.

ID Tags were chosen because that is the kind of information the ID Tag is for, it is like saying that ReplayGain should be put in an ascii file for ease of use.

There is nothing intentional to spoil EAC, it is upto the program to write log files, or add to ID tags, accuraterip does not even know filenames of tracks being ripped.

AccurateRip reports errors, EAC doesn't

Reply #13
mp3 / flac, id3v2, ape2 all supported.

Excellent! Any idea when that new version will be released?

ID Tags were chosen because that is the kind of information the ID Tag is for, it is like saying that ReplayGain should be put in an ascii file for ease of use.

I agree that logical destination for that information is in tags. However, having the info in ascii log file as an interrim or additional format would have a number of side benefits, for the EAC in the first place, as I explained before.

There is nothing intentional to spoil EAC, it is upto the program to write log files, or add to ID tags, accuraterip does not even know filenames of tracks being ripped.

I would understand even if it's intentional and dbPowerAmp wants to protect it's investment into AccurateRip.
As I explained before, AccurateRip doesn't need any more info that it doesn't know already, to write a log.
Log can have AccurateRip's disc ID in a filename and some other string like AccurateRipCDID, you can search for and filter files. So someone can later write a script/util that will search through folder structure for files e.g. AccurateRipCDID*.log and process them, copy info into tags etc. for applications on EAC side, wher e dbPowerAmp has no interest in investing time in development.

I've just finished ripping my 8th english CD. Only 3 of them were in AccurateRip database. With Croatian ones situation can be only worse.
I hope that sample is not big enough and ratio will improve as I rip more CDs.
But still, I feel that AccurateRip's database is not filled enough yet, as we would all like.
And one of the ways to help us achieve that would be to help EAC users' community to use it and benefit of it as well. I have a feeling that relying on dbPowerAmp's base of users only, will just slow down the process.
As a commercial program, dbPowerAmp will always have more polished and integrated software and give incentive to buy it.
For me, I would be very close to that decision if such functionality exists.
I'll have to check further if dbPowerAmp satisfies my other requirements (e.g. ripping to FLAC and mp3 and applying replaygain to both in a single go).
Thanks for doing such a good work so far anyway.

AccurateRip reports errors, EAC doesn't

Reply #14
>Excellent! Any idea when that new version will be released?

It is out now, R12.

>I have a feeling that relying on dbPowerAmp's base of users only, will just slow down the process.

For the last 2 version we have defaulted with AccurateRip installed and ready to go, the next version of EAC will do the same.

AccurateRip reports errors, EAC doesn't

Reply #15
It just occured to me that EAC highly recommended installing Adaptec's ASPI drivers and not to rip with the build-in ATAPI interface of Windows.

This setting is found in "EAC-EAC Options->Interface Tab". In order to select the first option though ("External ASPI Interface"), you need to install the ASPI drivers from Adaptec. And that's a bit of a problem because out-of-the-box they can give some problems, unless you tweak them to perfection (last time I installed them, I had to change registry settings). I believe this is because ASPI comes with Adaptec's hardware and needs a few changes to work with all ATAPI hardware.

ASPI was considered "100% Bugfree ™" while the build-in Windows interface was considered "Officially Broken ™". One of the reasons, IIRC, was that the Windows interface does not provide for really thorough error-detection while reading. So this might be exactly why you're experiencing those problems. It's worth a shot, but better check what exactly you should install and not simply grab the first thing you find on the net.

I will probably install them myself. When I do, I'll post here the optimal procedure of installing ASPI.

AccurateRip reports errors, EAC doesn't

Reply #16
It just occured to me that EAC highly recommended installing Adaptec's ASPI drivers and not to rip with the build-in ATAPI interface of Windows.

This setting is found in "EAC-EAC Options->Interface Tab". In order to select the first option though ("External ASPI Interface"), you need to install the ASPI drivers from Adaptec. And that's a bit of a problem because out-of-the-box they can give some problems, unless you tweak them to perfection (last time I installed them, I had to change registry settings). I believe this is because ASPI comes with Adaptec's hardware and needs a few changes to work with all ATAPI hardware.

ASPI was considered "100% Bugfree ?" while the build-in Windows interface was considered "Officially Broken ?". One of the reasons, IIRC, was that the Windows interface does not provide for really thorough error-detection while reading. So this might be exactly why you're experiencing those problems. It's worth a shot, but better check what exactly you should install and not simply grab the first thing you find on the net.

I will probably install them myself. When I do, I'll post here the optimal procedure of installing ASPI.


It could be something with that.
My laptop uses native Win32 interface and has no problems.
This, desktop one, has external ASPI interface:

But, I haven't installed them separately.
I don't know how it got here. I suspect it was installed with Nero software, because I have Nero installed on desktop, but not on laptop.
I'll try to change those settings and see if there is any difference.



>Excellent! Any idea when that new version will be released?

It is out now, R12.


I see. I downloaded it and installed. I installed reference version (21day trial), because that's the only version that supports accurate ripping.

>I have a feeling that relying on dbPowerAmp's base of users only, will just slow down the process.

For the last 2 version we have defaulted with AccurateRip installed and ready to go, the next version of EAC will do the same.

I think, you mean that free version also contains AccurateRip.
That's good.
Probably, without secure ripping, there are more inaccurate results, but then people see them and have incentive to buy reference version with secure ripping.

AccurateRip reports errors, EAC doesn't

Reply #17
>Excellent! Any idea when that new version will be released?

It is out now, R12.


My first impression is that I like the interface, but it seems that some key functionality for me is missing.

E.g.
1. I cannot create CD archive by burning individual FLAC files, because it doesn't support cue sheets in any form.
That's announced for the R13.

2. It cannot encode in two formats (flac and mp3) in a single go, but I can encode in e.g. flac first and then convert them in mp3's later.

3. ReplayGain cannot be calculated and written in tags automatically at the end of ripping process, but has to be done manually later.

4. mp3files cannot be adjusted by ReplayGain in a manner like mp3gain.exe does it, so they can be played with any mp3 player, not only ReplayGain aware ones.

At least, that's how it looks to me, maybe I'm wrong and I haven't read everything throughly (although I don't see manual, I'm just reading help files.)

I'll check for other things, but the 1. is enough to put me off.

If the software has all the functionality I need, I would buy it in no time.
The price is not an issue. It's reasonable at current level.
I'm fed up with dealing with so many applications to achieve what I need:
- EAC
- AccurateRip plugin
- FLAC (+metaflac)
- LAME
- Flacattack
- Mp3Gain
- Burrn

Having all under same roof would be a winner for me.

Any idea when R13 will be released?
Will it allow me to rip CD in idividual FLAC files and create cue sheets, so I can then re-create original audio CD?

AccurateRip reports errors, EAC doesn't

Reply #18
>2. It cannot encode in two formats (flac and mp3) in a single go, but I can encode in e.g. flac first and then convert them in mp3's later.

You need the Multi-Encoder in the beta forum.

>3. ReplayGain cannot be calculated and written in tags automatically at the end of ripping process, but has to be done manually later.

Install the DSP effects, one is ReplayGain, but this will not work with the multi encoder.

R13 is a fair way off.

------

>One of the reasons, IIRC, was that the Windows interface does not provide for really thorough error-detection while reading

On NT based system ASPI uses the Windows SCSI Pass through, so you are just adding an extra layer which can go wrong. SCSI Pass through has never limited error detection.

AccurateRip reports errors, EAC doesn't

Reply #19
>2. It cannot encode in two formats (flac and mp3) in a single go, but I can encode in e.g. flac first and then convert them in mp3's later.

You need the Multi-Encoder in the beta forum.

>3. ReplayGain cannot be calculated and written in tags automatically at the end of ripping process, but has to be done manually later.

Install the DSP effects, one is ReplayGain, but this will not work with the multi encoder.

R13 is a fair way off.

------

>One of the reasons, IIRC, was that the Windows interface does not provide for really thorough error-detection while reading

On NT based system ASPI uses the Windows SCSI Pass through, so you are just adding an extra layer which can go wrong. SCSI Pass through has never limited error detection.


As Multi-Encoder is in beta forum, I would asume that it's in sort of beta version.
Also, on DSP pages it says that DSP is in beta testing.
If one pays for the software it's expected to get finished/stable version. 
And, as you said, both 2. and 3. cannot be used at the same time.
Maybe, I'm not the right user for it, or it's not right product for me.
Unfortunatelly, I'll have to stick with EAC and fight with the bunch of other tools for the time being 

AccurateRip reports errors, EAC doesn't

Reply #20

ID Tags were chosen because that is the kind of information the ID Tag is for, it is like saying that ReplayGain should be put in an ascii file for ease of use.

I agree that logical destination for that information is in tags. However, having the info in ascii log file as an interrim or additional format would have a number of side benefits, for the EAC in the first place, as I explained before.


IIRC, AutoFLAC allows you to pull the AccurateRip screen text to a log file during your EAC ripping process.

-brendan

AccurateRip reports errors, EAC doesn't

Reply #21
IIRC, AutoFLAC allows you to pull the AccurateRip screen text to a log file during your EAC ripping process.
-brendan

Thanks,
But, as I see, it can only encode to FLACs. So, to be able to rip and encode in mp3s as well, I would have to start that as a separate process and rip again.
It's probably quicker to Copy-Paste AccurateRip screen, then to rip the whole CD for the second time. 
As AutoFlac is written in some kind of script language, I would asume that similar can be achieved with REACT, if nobody has done it already.

AccurateRip reports errors, EAC doesn't

Reply #22
They are both written in AutoIT.  Its *very* easy to pick up and modify the code for either.

-brendan

AccurateRip reports errors, EAC doesn't

Reply #23
They are both written in AutoIT.  Its *very* easy to pick up and modify the code for either.

-brendan


Maybe for you, but not for me