jean2

Hi,

I created a thread on the AccurateRip forum about a very peculiar AccurateRip result while using EAC.

http://forum.dbpoweramp.com/showthre...5082#post75082

I don't really want to duplicate all posts here and fragment the discussion, but I believe this is relevant to many users of EAC, so I would invite the interested parties to jump over there. I'm particularly interested in what Andre has to say...

Have fun...

Jean

greynol

Looks like you spotted another instance where AR is verifying a bad rip.

Reading your response to Spoon regarding using dBpoweramp to further investigate the matter, I think it would be beneficial for you to know the difference between the usage of C2 pointers in EAC and in dBpoweramp.

In EAC with C2 pointers enabled, data is read just once and EAC will determine whether re-reads are necessary based solely on the C2 pointers. There are many drives that will not always provide adequate information to cause EAC to perform re-reads when an error has occurred. Your drive could easily be one of them. In order increase your chances that no errors are being skipped you should also use test & copy. Also, when re-reads are performed, C2 pointers are not used. This increases the chances of getting consistent errors without a warning.

dBpoweramp takes a different approach with C2 pointers. When combined with an ultra-secure pass, the data will be read another time in order to determine whether a C2 pointer has failed to detect an inconsistent error, like using EAC w/C2 pointers and test & copy. The first difference is that unlike the EAC C2 w/T&C approach, dBpoweramp keeps track of where any inconsistencies exist (whether they're flagged by C2 pointers or not flagged by C2 pointers) as well as where any consistent errors exist (as flagged by C2 pointers) and will perform re-reads in those areas. The second difference is that dBpoweramp will use C2 pointers to drop bad data (reducing the likelihood of accepting consistent errors as good data).

jean2

Trust me, I don't take any joy into that, and I would have prefered for this to not exist. I feel it's a real PITA, and I hate being the bearer of bad news.

I told you that I would watch for it. I had a strong suspicion that the random undetected errors I had with the Lite-On and Samsung were not related to the disks (most of my disks are in good condition), but related to a firmware or chipset bug. That's why I decided to buy a PX-230A and restart ripping my CD collection from scratch.

Ok, I realise that I spoke too soon. I did not study dBpoweramp enough. Ok, I'll try to do that when I can put my hands on this CD.

Note that I have other ideas on how to work around this, but I'm not sure how practical they are and I'll wait for Andre to get up to speed with the thread.

Thanks a lot, I appreciate your advices !

Jean

greynol

Oh, I feel the same way. The thumbs up relates back to the point you were making with our previous conversation.

Looks like the trouble is consistently occurring with more than one drive, unless you think the problem is with your Plextor-badged BENQ.

jean2

I believe that the Plextor PX-230A (BenQ badged) is giving me the right track, as far as we can define a "right" track when the pressing has a defect.

I was surprised that it was the Lite-On having troubles. I've had more undetected errors with the Samsung, I believe. Maybe it's because the Samsung is twice as fast, so more disks goes through it.

I was also surprised that my old HP DVD 400i was giving the same error. It's supposedly a BenQ dw800a and I assume it's not using a MediaTek chipset like the Lite-On and Samsung (I assume it's a Philips chipset).

Yeah, more questions than answers at this point...

Have fun...

Jean

greynol

I have a different pressing of this disc. Maybe I can help you determine what ist the "right" track like I did with gib in this thread...

http://www.hydrogenaudio.org/forums/...howtopic=60952

Teller

The AR database has 6 distinct record sets for the disc in question.
1st has a confidence level 13 for most tracks and level 4 for track 17
2nd has a confidence level range of 13 to 28 for tracks 1 to 16 with a confidence level of 8 for track 17
3rd has a confidence level range of 2 to 3 for tracks 1 to 16 with a confidence level of 10 for track 17
4th has a confidence level of 2 for all tracks 1 to 16 with a confidence level of 17 for track 17
5th has a confidence level range of 0 to 2 for tracks 1 to 16 with a confidence level of 2 for track 17
6th has a confidence level 0 for tracks 1 to 16 with a confidence level of 2 for track 17

greynol

Probably more than 6 distinct pressings since the drive offset determination only covers a window of 3,527 samples.

This is very useful information, Mr. Teller. I wasn't able to find this out with my pressing since it's the only one in the DB within the window, but here are the confidences:

Tacks 1 - 16: 26 to 29
Track 17: 17

greynol

Over at the dBpoweramp forum it appears that the problem is only happening with EAC:
http://forum.dbpoweramp.com/showpost...7&postcount=15

jean2

I've done more tests and added more data to the thread, and I'm not so sure it's the case, EAC may not be the main culprit after all.

Jean

jean2

No disrespect, but I don't have a clue what you are talking about. Especially pressings with a confidence of 0. And I don't know how my results would fit with those.

Maybe you could share your results with Spoon on the other thread, he may know what you are talking about and make use of that info.

Have fun...

Jean

greynol

I'm not so sure EAC isn't the main culprit. It seems the problem is consistent one way when ripping in secure mode and another when ripping in burst mode. I think there may be a problem during the synchronization process between 2MB bursts when ripping this disc with some drives.

With accurate stream-capable drives it would seem that this synchronization night not be necessary. Martin has previously mentioned that taking it away would eliminate the need for cache flushing (except for re-reads, of course) which would produce significantly faster rips.

If my suspicion is correct maybe this will provide another reason to consider modifying the ripping routine.

greynol

Jean,

Could you rip the first 50-or-so blocks from one of the tracks in this disc using F7 and the "Snap Track" button and post the file here so I can try to recreate your pressing?

jean2

Ok, if I did it properly, you should have the first 50 blocks of track 01 and track 17. Ripped using the LH-20A1P in secure mode. Enjoy ;-)

By the way, are you in the Bay Area ?

Jean

Attached Files

Simple-Minds-CD1-extracts.zip (40,4 KB, 3 views)

greynol

Hi. Well unfortunately it looks like the data is different. Sometimes pressings only differ by an offset, but not this time.