XLD/AccurateRip: tracks not in DB; is there a way to look-up manually?

Topic: XLD/AccurateRip: tracks not in DB; is there a way to look-up manually? (Read 15175 times) previous topic - next topic

0 Members and 1 Guest are viewing this topic.

XLD/AccurateRip: tracks not in DB; is there a way to look-up manually?

2011-08-24 14:10:57

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

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

XLD/AccurateRip: tracks not in DB; is there a way to look-up manually?

Reply #1 – 2011-08-24 23:40:40

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.

XLD/AccurateRip: tracks not in DB; is there a way to look-up manually?

Reply #2 – 2011-09-14 09:05:16

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

XLD/AccurateRip: tracks not in DB; is there a way to look-up manually?

Reply #3 – 2011-09-14 14:43:49

Quote from: mrmarbach on 2011-09-14 09:05:16

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

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

XLD/AccurateRip: tracks not in DB; is there a way to look-up manually?

Reply #4 – 2011-09-14 19:50:10

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

I'll just plug on now. Thanks again.

XLD/AccurateRip: tracks not in DB; is there a way to look-up manually?

Reply #5 – 2011-09-14 19:54:58

Quote from: mixminus1 on 2011-09-14 14:43:49

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.

XLD/AccurateRip: tracks not in DB; is there a way to look-up manually?

Reply #6 – 2011-09-14 21:08:51

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.

XLD/AccurateRip: tracks not in DB; is there a way to look-up manually?

Reply #7 – 2011-09-14 21:10:49

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.

XLD/AccurateRip: tracks not in DB; is there a way to look-up manually?

Reply #8 – 2011-09-14 21:33:19

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

XLD/AccurateRip: tracks not in DB; is there a way to look-up manually?

Reply #9 – 2011-09-14 22:51:55

Quote from: spoon on 2011-09-14 21:33:19

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.

XLD/AccurateRip: tracks not in DB; is there a way to look-up manually?

Reply #10 – 2011-09-15 08:27:45

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.

XLD/AccurateRip: tracks not in DB; is there a way to look-up manually?

Reply #11 – 2011-09-15 09:01:25

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

XLD/AccurateRip: tracks not in DB; is there a way to look-up manually?

Reply #12 – 2011-09-15 09:13:06

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.

XLD/AccurateRip: tracks not in DB; is there a way to look-up manually?

Reply #13 – 2011-09-15 18:37:13

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.

XLD/AccurateRip: tracks not in DB; is there a way to look-up manually?

Reply #14 – 2011-10-28 02:23:27

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

Notice