IPB

Welcome Guest ( Log In | Register )

 
Reply to this topicStart new topic
XLD CD accurately ripped by CUE file saying not
LTP
post Feb 11 2013, 12:03
Post #1





Group: Members
Posts: 23
Joined: 7-January 11
Member No.: 87155



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!
Go to the top of the page
+Quote Post
LTP
post Feb 11 2013, 12:55
Post #2





Group: Members
Posts: 23
Joined: 7-January 11
Member No.: 87155



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
Go to the top of the page
+Quote Post
Porcus
post Feb 11 2013, 13:09
Post #3





Group: Members
Posts: 1842
Joined: 30-November 06
Member No.: 38207



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


--------------------
One day in the Year of the Fox came a time remembered well
Go to the top of the page
+Quote Post
Nessuno
post Feb 11 2013, 14:07
Post #4





Group: Members
Posts: 422
Joined: 16-December 10
From: Palermo
Member No.: 86562



QUOTE (LTP @ Feb 11 2013, 12:03) *
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.

This post has been edited by Nessuno: Feb 11 2013, 14:08


--------------------
... I live by long distance.
Go to the top of the page
+Quote Post
LTP
post Feb 11 2013, 15:12
Post #5





Group: Members
Posts: 23
Joined: 7-January 11
Member No.: 87155



QUOTE (Nessuno @ Feb 11 2013, 13:07) *
QUOTE (LTP @ Feb 11 2013, 12:03) *
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.
Go to the top of the page
+Quote Post
Nessuno
post Feb 11 2013, 15:31
Post #6





Group: Members
Posts: 422
Joined: 16-December 10
From: Palermo
Member No.: 86562



QUOTE (LTP @ Feb 11 2013, 15:12) *
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.
Go to the top of the page
+Quote Post
korth
post Feb 11 2013, 15:56
Post #7





Group: Members
Posts: 436
Joined: 13-March 11
Member No.: 88969



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


--------------------
korth
Go to the top of the page
+Quote Post
LTP
post Feb 11 2013, 16:09
Post #8





Group: Members
Posts: 23
Joined: 7-January 11
Member No.: 87155



QUOTE (Nessuno @ Feb 11 2013, 14:31) *
QUOTE (LTP @ Feb 11 2013, 15:12) *
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.



QUOTE (korth @ Feb 11 2013, 14:56) *
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!
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: 18th September 2014 - 23:58