IPB

Welcome Guest ( Log In | Register )

 
Reply to this topicStart new topic
XLD/AccurateRip: tracks not in DB; is there a way to look-up manually?, Was: XLD/AccurateRip problem (TOS#6ócan folk TRY to be more specific?)
mrmarbach
post Aug 24 2011, 14:10
Post #1





Group: Members
Posts: 4
Joined: 24-August 11
Member No.: 93251



Newbie here. Managing OK with XLD so far.

I just ripped a CD which was flagged up in the track-selection screen as AccurateRip YES (I double checked this afterwards). But then on reading the log it claims the tracks are not in the AccurateRip database.

The Metadata which XLD found was for a collection of discs including this one. I have the original single-disc release. I don't know if it can tell there is a slight difference of some sort, and hence the problem.

Anyway, is there some way of manually looking in the AccurateRip database to try to find the information and perhaps match the checksums?

Supplementary newbie question: bearing in mind lack of AccurateRip confirmation, does this otherwise look like a perfect rip? Are there any of the variables here I should be checking - apart from the total lack of reported errors.

Any other comments on the log below?

many thanks
N

CODE
X Lossless Decoder version 20110821 (136.1)

XLD extraction logfile from 2011-08-24 14:33:31 +0200

/ Boulez-Conducts/Schoenberg/Carter/Berio/Kurtag/Xenakis/Birtwistle/Grisey/Ferneyh

Used drive : HL-DT-ST DVDRW GS21N (revision SA18)

Ripper mode : CDParanoia III 10.2
Disable audio cache : OK for the drive with a cache less than 2750KiB
Make use of C2 pointers : YES
Read offset correction : 667
Max retry count : 100
Gap status : Analyzed, Appended

TOC of the extracted CD
Track | Start | Length | Start sector | End sector
---------------------------------------------------------
1 | 00:00:33 | 25:52:00 | 33 | 116432
2 | 25:52:33 | 27:09:65 | 116433 | 238672
3 | 53:02:23 | 18:36:05 | 238673 | 322377

AccurateRip Summary
Track 01 : Not Found
Track 02 : Not Found
Track 03 : Not Found
->0 track(s) accurately ripped, 0 track(s) not, 3 track(s) not found

All Tracks
Statistics
Read error : 0
Skipped (treated as error) : 0
Edge jitter error (maybe fixed) : 0
Atom jitter error (maybe fixed) : 0
Drift error (maybe fixed) : 0
Dropped bytes error (maybe fixed) : 0
Duplicated bytes error (maybe fixed) : 0

Track 01
Filename : /Users/nicolashodges/Music/XLD rips/01 Track 01.flac
Pre-gap length : 00:02:33

CRC32 hash : 5F75513E
CRC32 hash (skip zero) : 34520953
AccurateRip signature : B5E50424
->Track not present in AccurateRip database.
Statistics
Read error : 0
Skipped (treated as error) : 0
Edge jitter error (maybe fixed) : 0
Atom jitter error (maybe fixed) : 0
Drift error (maybe fixed) : 0
Dropped bytes error (maybe fixed) : 0
Duplicated bytes error (maybe fixed) : 0
Inconsistency in error sectors : 0

Track 02
Filename : /Users/nicolashodges/Music/XLD rips/02 Track 02.flac
Pre-gap length : 00:08:10

CRC32 hash : 9DFC8386
CRC32 hash (skip zero) : B30889FC
AccurateRip signature : 51A71558
->Track not present in AccurateRip database.
Statistics
Read error : 0
Skipped (treated as error) : 0
Edge jitter error (maybe fixed) : 0
Atom jitter error (maybe fixed) : 0
Drift error (maybe fixed) : 0
Dropped bytes error (maybe fixed) : 0
Duplicated bytes error (maybe fixed) : 0
Inconsistency in error sectors : 0

Track 03
Filename : /Users/nicolashodges/Music/XLD rips/03 Track 03.flac
Pre-gap length : 00:08:08

CRC32 hash : 5C34E938
CRC32 hash (skip zero) : 0550E30B
AccurateRip signature : 82F46DA8
->Track not present in AccurateRip database.
Statistics
Read error : 0
Skipped (treated as error) : 0
Edge jitter error (maybe fixed) : 0
Atom jitter error (maybe fixed) : 0
Drift error (maybe fixed) : 0
Dropped bytes error (maybe fixed) : 0
Duplicated bytes error (maybe fixed) : 0
Inconsistency in error sectors : 0

No errors occurred

End of status report


This post has been edited by db1989: Aug 24 2011, 14:27
Reason for edit: Please enclose large logs, etc. within [codebox] tags
Go to the top of the page
+Quote Post
kornchild2002
post Aug 24 2011, 23:40
Post #2





Group: Members
Posts: 2073
Joined: 8-April 05
From: Cincinnati, OH
Member No.: 21277



I am sure someone else can chime in here with a little more information but AccurateRip no longer keeps their online database of key discs in an easily accessible list (according to their website). You can check here for the off chance that the CD you ripped is in there. Even then the pressing that you have could be different from the version/pressing that is in the AccurateRip database. There isn't anything in XLD (at least that I have found) forcing it to search for the CD in the AccurateRip database. If XLD can't find it, it can't find it.

Other than that, your CD rip looks like it was fine as XLD isn't reporting any errors aside from not finding the CD in the AccurateRip database. I have many, many albums not in the AccurateRip database (I just ripped one last week) simply because not enough people have ripped them. So I have a bunch of CDs that were ripped without AccurateRip comparison results yet XLD reports no issues and I am fine with that. I can't do anything if the CD isn't in AccurateRip. That is why you have CD rippers like XLD.
Go to the top of the page
+Quote Post
mrmarbach
post Sep 14 2011, 09:05
Post #3





Group: Members
Posts: 4
Joined: 24-August 11
Member No.: 93251



Thanks for the helpful response.

Further newby questions:

- Ripping an archive CDR of a commercial disc, I get "AccurateRip YES", all tracks ripped with no errors, and all tracks NG. This seems to me to mean that I have ripped perfectly the CDR, but that the CDR wasn't itself a perfect rip in the first place. Correct?

- Ripping a CD (not in AccurateRip) using the two engines I get different results: both have the same "CRC32 Hash" values for all tracks, but the XLD Secure Ripper says there are damaged sectors. Do the identical "CRC32 Hash" values mean that regardless of the damaged sectors, the two rips are identical and both perfect?

I thought moving into bit-perfect ripping would be a simple YES/NO situation, but I'm getting more neurotic to understand what's really happening as I do each CD... <sigh>

Thanks in advance...
Go to the top of the page
+Quote Post
mixminus1
post Sep 14 2011, 14:43
Post #4





Group: Members
Posts: 688
Joined: 23-February 05
Member No.: 20097



QUOTE (mrmarbach @ Sep 14 2011, 01:05) *
- Ripping an archive CDR of a commercial disc, I get "AccurateRip YES", all tracks ripped with no errors, and all tracks NG. This seems to me to mean that I have ripped perfectly the CDR, but that the CDR wasn't itself a perfect rip in the first place. Correct?

What do you mean by "NG"?

QUOTE
- Ripping a CD (not in AccurateRip) using the two engines I get different results: both have the same "CRC32 Hash" values for all tracks, but the XLD Secure Ripper says there are damaged sectors. Do the identical "CRC32 Hash" values mean that regardless of the damaged sectors, the two rips are identical and both perfect?

Well, they're definitely both identical - they may both be perfect, or they may both contain the exact same error(s). The only way to know is to rip using (at least) a different drive (which is the whole point of AccurateRip). The "damaged sector" thing seems to me to be similar to EAC's "timing errors" warning: something wasn't absolutely perfect during the rip, but the data was read correctly anyway.

QUOTE
I thought moving into bit-perfect ripping would be a simple YES/NO situation, but I'm getting more neurotic to understand what's really happening as I do each CD... <sigh>

Repeat after me: there's no such thing as bit-perfect ripping...there's no such thing as bit-perfect ripping...oh, and click your heels three times. wink.gif

The Red Book audio CD standard was never designed to ensure bit-perfect extraction of the PCM audio data from an audio CD. It was designed for computationally-easy (by 1984 standards) real-time playback, with concealment, i.e. interpolation, being its method of dealing with errors, not bit-perfect correction as is common on CD/DVD-ROMs, hard drives, etc.

Now, you most certainly *can* get verified bit-perfect audio extraction from an audio CD, it's just that it's not a given, and AFAIK, there is really no way to be 100.00% sure that you achieved such using only one drive, without AccurateRip.

That being said, since the simple act of playing back an audio CD in a standalone CD player cannot, by definition, achieve confirmed bit-perfect playback, personally, I don't worry about: if a rip sounds fine, it is fine. At some point, you just have to stop the hand-wringing and realize that "good enough" is going to have to be just that.

If you can confirm a rip via AccurateRip or a rip on a second local drive, great - may your slumber be deep and peaceful smile.gif . If not, do a test and copy on your drive and see what you get: matching CRCs? It still may not be a 100.00% bit-perfect rip, but that's as close as you're going to get, so ditto on the slumber. Non-matching CRCs? Listen to it and see what you think.


--------------------
"Not sure what the question is, but the answer is probably no."
Go to the top of the page
+Quote Post
mrmarbach
post Sep 14 2011, 19:50
Post #5





Group: Members
Posts: 4
Joined: 24-August 11
Member No.: 93251



Thanks for the excellent reply.

NG is what it says after each track, meaning presumably "No Go" or something like that, such as here:

QUOTE
AccurateRip Summary
Track 01 : NG
Track 02 : NG
Track 03 : NG
Track 04 : NG
->0 track(s) accurately ripped, 4 track(s) not, 0 track(s) not found

All Tracks
Statistics
Read error : 0
Jitter error (maybe fixed) : 0
Retry sector count : 0
Damaged sector count : 0


Unfortunately as I work in classical music, and quite obscure branches of it at that, rather few of my discs have turned up in AccurateRip. I guess that's just the way it is. As for matching CRCs, the ones I mentioned are from two different drives (different drive models, in a MacBook and iMac). So I guess that's me covered to a certain extent at least.

I am certainly happy to just shrug my shoulders and enjoy the music at some point. smile.gif But I need to remain neurotic a little longer in order to establish a workflow and a certain amount of understanding, so that I know for sure where to put the <shrug> crying.gif

I'll just plug on now. Thanks again.
Go to the top of the page
+Quote Post
greynol
post Sep 14 2011, 19:54
Post #6





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



QUOTE (mixminus1 @ Sep 14 2011, 06:43) *
Now, you most certainly *can* get verified bit-perfect audio extraction from an audio CD, it's just that it's not a given, and AFAIK, there is really no way to be 100.00% sure that you achieved such using only one drive, without AccurateRip.

AccurateRip doesn't necessarily provide bullet-proof guarantees, either.


--------------------
I should publish a list of forum idiots.
Go to the top of the page
+Quote Post
mixminus1
post Sep 14 2011, 21:08
Post #7





Group: Members
Posts: 688
Joined: 23-February 05
Member No.: 20097



Would that be due to offset issues, or the algorithm used to calculate the CRC? I seem to recall a discussion awhile back about some bug in ARv1 regarding every n sample in the right(?) channel potentially causing incorrect calculations.


--------------------
"Not sure what the question is, but the answer is probably no."
Go to the top of the page
+Quote Post
kornchild2002
post Sep 14 2011, 21:10
Post #8





Group: Members
Posts: 2073
Joined: 8-April 05
From: Cincinnati, OH
Member No.: 21277



Right especially since I can rip a CD with audible errors during the ripping process itself. I can do that multiple times and soon enough, the results will be in AccurateRip with some level of confidence so that when someone else actually accurately rips an audio CD, AccurateRip will report that it doesn't match its database. There are other examples too but AccurateRip is not a sure fire way of ensuring accuracy. It can be used as another order of confidence in assuming rips are accurate but it is not perfect.
Go to the top of the page
+Quote Post
spoon
post Sep 14 2011, 21:33
Post #9


dBpowerAMP developer


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



>AccurateRip with some level of confidence

If by some you mean 1, then yes your incorrect rip could appear in the database with a confidence of 1, which would be removed as soon as a 2nd person submits that disc.

I do not know about you, but that does not overly worry me, as AccurateRip is a positive verification system.


--------------------
Spoon http://www.dbpoweramp.com
Go to the top of the page
+Quote Post
greynol
post Sep 14 2011, 22:51
Post #10





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



QUOTE (spoon @ Sep 14 2011, 13:33) *
If by some you mean 1, then yes your incorrect rip could appear in the database with a confidence of 1, which would be removed as soon as a 2nd person submits that disc.

Until a CD-R either burned with offset correction or a burner with no offset relative to the reference used (there are a number of models of such a burner by at least one major manufacturer) was submitted to the database at a later date.

Does the AR database contain multiple entries of an errant rip propagated through later generation copies? The answer can't really be anything but yes.


--------------------
I should publish a list of forum idiots.
Go to the top of the page
+Quote Post
spoon
post Sep 15 2011, 08:27
Post #11


dBpowerAMP developer


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



Offsets are no longer an issue for Programs which check across pressings, if I was doing accurate rip today it would be done without the need for offset detection.


--------------------
Spoon http://www.dbpoweramp.com
Go to the top of the page
+Quote Post
greynol
post Sep 15 2011, 09:01
Post #12





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



...which would make it even easier for submissions from later generations of an errant rip to find a home.

Anyway, I think I've made my point; well until the next time someone makes erroneous claims, at least.


--------------------
I should publish a list of forum idiots.
Go to the top of the page
+Quote Post
spoon
post Sep 15 2011, 09:13
Post #13


dBpowerAMP developer


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



Enlighten me please how someone ripping a CD-R effects my rip of a non CD-R (assuming the non CD-R has been ripped before by more than one person).

>...which would make it even easier for submissions from later generations of an errant rip to find a home.

You are assuming the backend would do away with offsets, no discs would be still stored as per pressings, it is just the client which would not need to go through the process of finding an offset.


--------------------
Spoon http://www.dbpoweramp.com
Go to the top of the page
+Quote Post
greynol
post Sep 15 2011, 18:37
Post #14





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



Checking a CD-R against AccurateRip was raised in this discussion. There is no need to enlighten you on your non sequitur.

I could have broadened the comment to include ways in which AccurateRip is not a "100.00%" guarantee for your rip of a non CD-R but didn't feel it necessary since it would drag this discussion further off-topic. Besides, it's already been done to death in other discussions.

Point taken about my assumption that per-pressing information would be discarded. Even still, blind checking across multiple offsets can only serve to hurt, in the specific case I raised relevant to this discussion, an individual relying on the database to determine the accuracy of his CD-R.

This post has been edited by greynol: Sep 15 2011, 23:00


--------------------
I should publish a list of forum idiots.
Go to the top of the page
+Quote Post
SteveN1
post Oct 28 2011, 02:23
Post #15





Group: Members
Posts: 1
Joined: 28-October 11
Member No.: 94748



Greetings all,

A newbie to lossless here, trying to convert flac to m4a with XLD. I've noticed that it's nearly impossible to get some albums to pass the AccurateRip tests, and I suspect this may be due to the offset (a file won't have an offset, I assume).

Is there an easy way to tell if my converted file is 'equivalent' to the original flac file using XLD?

Cheers,
- SteveN
Go to the top of the page
+Quote Post

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: 30th August 2014 - 08:19