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: XLD CD accurately ripped by CUE file saying not (Read 3630 times) previous topic - next topic
0 Members and 1 Guest are viewing this topic.

XLD CD accurately ripped by CUE file saying not

Probably a stupid question but one that I'm a little stumped over. I'm ripping a load of my old CDs using XLD on my Mac and backing them up on my external. I ripped Idlewild's Post Electric Blues and got a log showing everything was accurately ripped.

Quote
AccurateRip Summary (DiscID: 00109c6c-0091b913-890a820c)
    Track 01 : OK (v1+v2, confidence 24/24)
    Track 02 : OK (v1+v2, confidence 24/24)
    Track 03 : OK (v1+v2, confidence 24/24)
    Track 04 : OK (v1+v2, confidence 24/24)
    Track 05 : OK (v1+v2, confidence 24/24)
    Track 06 : OK (v1+v2, confidence 24/24)
    Track 07 : OK (v1+v2, confidence 24/24)
    Track 08 : OK (v1+v2, confidence 24/24)
    Track 09 : OK (v1+v2, confidence 24/24)
    Track 10 : OK (v1+v2, confidence 24/24)
    Track 11 : OK (v1+v2, confidence 24/24)
        ->All tracks accurately ripped.

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


yet when I have opened the CUE file today in XLD to convert to a copy to ALAC for iTunes, it is saying AccurateRip: NO at the bottom of the application window!
Any reason why this would be and is my CD rip still accurate? I've had rips where the CD wasn't found on the DB show accurate a few weeks/months later when enough submissions had been made of it, but never one that showed accurate suddenly no longer be. All the other rips I did around that time are showing YES for it.
Any help to calm my OCD down would be appreciated before I have to dig out the CD again!

XLD CD accurately ripped by CUE file saying not

Reply #1
Just had a quick look over the log file and it lists a 12th track which I believe was a data track and thus not ripped with the others. Would that be the reason perhaps why it is saying it is not an accurate rip simply because that bit is missing and thus is not 'complete'?

Quote
TOC of the extracted CD
    Track |  Start  |  Length  | Start sector | End sector
    ---------------------------------------------------------
        1  | 00:00:00 | 03:57:59 |        0    |    17833 
        2  | 03:57:59 | 02:50:64 |    17834    |    30647 
        3  | 06:48:48 | 03:21:15 |    30648    |    45737 
        4  | 10:09:63 | 03:24:22 |    45738    |    61059 
        5  | 13:34:10 | 03:08:64 |    61060    |    75223 
        6  | 16:42:74 | 04:58:00 |    75224    |    97573 
        7  | 21:40:74 | 05:07:74 |    97574    |  120672 
        8  | 26:48:73 | 02:06:70 |    120673    |  130192 
        9  | 28:55:68 | 03:23:17 |    130193    |  145434 
      10  | 32:19:10 | 03:47:31 |    145435    |  162490 
      11  | 36:06:41 | 04:28:54 |    162491    |  182644 
      12  | 43:07:20 | 01:42:55 |    194045    |  201749

XLD CD accurately ripped by CUE file saying not

Reply #2
Do you have access to a Windows computer? Try CUETools, tag the files with <ACCURATERIPID> value 00109c6c-0091b913-890a820c and verify.

XLD CD accurately ripped by CUE file saying not

Reply #3
yet when I have opened the CUE file today in XLD to convert to a copy to ALAC for iTunes, it is saying AccurateRip: NO at the bottom of the application window!

I'm at work now, so can't verify, but if'm not wrong that label only shows that, opening a folder as a disk, XLD cannot find an entry in AR db for it. If it says "yes" then clicking on the nearest button you have the possibility to check the (virtual) CD for AR as if you were ripping it now.

Give it a closer look.
... I live by long distance.

XLD CD accurately ripped by CUE file saying not

Reply #4
yet when I have opened the CUE file today in XLD to convert to a copy to ALAC for iTunes, it is saying AccurateRip: NO at the bottom of the application window!

I'm at work now, so can't verify, but if'm not wrong that label only shows that, opening a folder as a disk, XLD cannot find an entry in AR db for it. If it says "yes" then clicking on the nearest button you have the possibility to check the (virtual) CD for AR as if you were ripping it now.

Give it a closer look.


However it found the entry in the ARDB when it was ripped judging from the log file saying the rip was accurate, and it was ripped and then opened with the same program (XLD) so I can't see why that would be a problem.

XLD CD accurately ripped by CUE file saying not

Reply #5
However it found the entry in the ARDB when it was ripped judging from the log file saying the rip was accurate, and it was ripped and then opened with the same program (XLD) so I can't see why that would be a problem.

By my experience, sometimes it happens so maybe it's simply a bug, or it has something to do with the way XLD calculate AR id from track lengths and specifically with that missing 12th track: when it works (and often it does) it operate even without a cue file, only the FLAC file of each track so I think the cue file itself is not taken into account to identify the source.
Anyway that "no" doesn't mean that the single tracks you have are not accurately ripped, we know from the ripping log that they are, but that the set of files in that folder doesn't represent a disk with a valid AR db entry.
... I live by long distance.

XLD CD accurately ripped by CUE file saying not

Reply #6
DiscID: 00109c6c-0091b913-890a820c
0C = 12 tracks
The data track was used during the original rip to calculate the ID.
korth

 

XLD CD accurately ripped by CUE file saying not

Reply #7
However it found the entry in the ARDB when it was ripped judging from the log file saying the rip was accurate, and it was ripped and then opened with the same program (XLD) so I can't see why that would be a problem.

By my experience, sometimes it happens so maybe it's simply a bug, or it has something to do with the way XLD calculate AR id from track lengths and specifically with that missing 12th track: when it works (and often it does) it operate even without a cue file, only the FLAC file of each track so I think the cue file itself is not taken into account to identify the source.
Anyway that "no" doesn't mean that the single tracks you have are not accurately ripped, we know from the ripping log that they are, but that the set of files in that folder doesn't represent a disk with a valid AR db entry.



DiscID: 00109c6c-0091b913-890a820c
0C = 12 tracks
The data track was used during the original rip to calculate the ID.


Thanks the both of you, I was puzzled as hell before I saw the data track was part of the original disc and afterwards I kinda guessed it would be that but thanks for putting my mind at rest!