Jump to content

jimclip

  • Posts

    6
  • Joined

  • Last visited

  • Country

    country-ZZ

Retained

  • Member Title
    Newbie
  1. @Jedi82: Yes, you just look at the XLD AR log to make sure the analysis didn't find any errors. Cue sheets are a totally separate issue and have nothing to do with AR checking really; even if the XLD AR log showed errors, that would give you no reason to modify the CUE sheet. This feature in XLD is useful in instances where AR wasn't queried on the original rip (thus of course the original log file would not show AR confidence numbers), or if the log is missing, or if you want to make sure files haven't been corrupted during transmission/copying. And as others have already said, if the XLD AR log shows no errors, that's as about as sure as you're gonna get. Of course that certainty is probably increased somewhat if you also have the original log file showing matches on the Test & Copy checksums, which is the other half of the testing equation. @goldsdad, thanks for the info about XLD being able to handle a folder of audio files just like a CD -- without a cue sheet....just tried it, nice!
  2. The purpose of this function is to check the file or files with the AccurateRip database to see if the audio data matches the rips by other people. It's the same thing that MOST people do at the time of ripping, which is to let EAC or XLD query the AR database and report the results in the logfile. But I've seen a number of torrents (often older ones but not necessarily) where Test and Copy was used but the ripper was not set to also test the results against the AR database. So if the original CUE file is still present, you can check it using this feature. And despite what the 1st reply says, you CAN check CDs that have been ripped to separate tracks, so long as the original CUE file is still present (which is true for single file+cue too, unless the cue was embedded). Whether the CD was ripped to a single file+cue or individual tracks, simply drag the CUE to XLD (or drag the lossless file itself if it's a single file with the cue sheet embedded), and XLD should open an extraction window showing the track names, track times, and pre-gap lengths. If XLD gives you an error that it can't open, open the cue sheet with TextEdit and make sure the FILE names of each song (the part right before .wav, not the Title) exactly match the names of the FLAC file(s), including the style of the track number, periods, dashes and spaces too (sometimes an apostrophe gets dropped in file transfer, or people re-title the files from "06 - Kashmir" to "6. Kashmir", for example). Just one apostrophe or one space that's used in the CUE sheet but is missing from the corresponding file's name is enough to give you an error when you first drag the cue to XLD. Once the extraction window is open, simply go under the File menu and select "Check File With AccurateRip". The log it generates shows the confidence match for the rip just like if the AR database had been queried at the time of ripping. This is also useful in cases where someone rips a CD the day it is released and the log reports that the CD was not found in the AR database. As long as you still have the cue, you can check it again post-rip, and within a few days or a month there should have been enough other people who have ripped it so that you'll get some number of confidence in your check. Hope that helps. I love XLD, the developer TMKK has really been upping the ante with a lot of great new features recently, including the ability to burn just in the last few weeks!
  3. Well, I thought my problem was solved, but it appears not. Regarding XLD hanging up when Pregap Detection starts and can't eject the CD without restarting, or the Mac itself freeezing>>> I contacted XLD's developer a while back and he advised me to check the "Don't Detect Pregap" option, because he said once I actually ripped the CD, XLD would detect the pregaps anyway. Well, unless I'm missing something, XLD does NOT detect the pregaps at all with that setting checked. I took a CD that I knew for sure had pregaps, ripped it both with and without Detect Pregap checked (ripped to FLAC, individual files, using the standard ripping setting "Include Pre-gap For All Tracks". In the resulting logfiles, the one that detected the gaps prior to ripping shows "Gap Status: Analyzed, Appended", while the other logfile (as you'd logically expect) shows "Gap Status: Not Analyzed". Moreover, I also exported a CUE sheet at the conclusion of each of the two rips: Again, as expected, the pregap analyzed rip showed various pre-gap lengths in the form of INDEX 00 followed by varying time values on the tracks that had pregaps, while the Pregap NOT-Analyzed rip just showed the standard INDEX 01 00:00:00 for EVERY track. What's strange is that both rips showed as verified accurate with the AccuRip database in the logfiles. But how can the rip be accurate if the pregaps weren't analyzed and appended?? And of course there's the fact that I ended up with 2 totally different cue sheets (which in theory should match), since one reflects the CD's pregap Index points and the other doesn't. It doesn't seem that proper rips can be made without pregap detection, and yet the pregap scanning process is buggy for me and others; it gets hung up more than half the time and I have to restart the machine....not good. And I'm also confused by the Pregap NOT-analyzed rip checking out as OK with AR database. Thoughts anyone??? I've also emailed the developer a follow-up email now that I've confirmed that pre-gaps are not being detected after all. I'll report back if I get a reply. Cheers, Don
  4. @Goldsdad....sorry I overlooked your earlier post. I disabled Pre-Gap scan (I had to recreate all my profiles to reflect the small change; unless I'm missing something you can't simply modify existing profiles), and so far have had no problems. I don't think it's a fluke as it was hanging on every CD today until disabling that setting. So far two rips and no worries. I was concerned that it would mess up the Accurate Rip, but the log showed that all is well. As you said, it still discovers pre-gaps DURING ripping...just not BEFORE ripping. @jhwalker, did disabling the auto-pregap detect help you? I have iTunes set to not automatically open when I insert discs, but I've also tried letting iTunes mount the disc first. Neither method seemed to make a difference; both were capable of producing the hangup. In any case, between goldsdad's advice and tmkk telling me to disable it - and given that it doesn't seem to affect AccurateRip – this matter is now resolved for me. Hope this works for others too. I can't tell you how many times I've had to quit all apps and restart due to this glitch....finally !!! Yes, I'm also a little surprised that the developer hadn't even heard of this before. Sorry to the OP for hijacking his thread
  5. Yes, I keep XLD updated via auto-update, I'm running 129.0 dated late Feb. 2011. It happened to me again today when ripping a CD which is why I searched and found this thread, so the current version hasn't fixed it for me. After a restart and eject, it was ok and ripped normally. As I said, it doesn't happen every time, but well over 50 percent of the time, which is more than enough to be very annoying since once the disc is stuck it requires one or more restarts to "dislodge" it. I actually emailed XLD developer tmkk about this today....his response was that "he's never experienced nor heard reports of this problem in the roughly 2 years that XLD has been capable of ripping." His suggestion was to disable the pre-gap detection feature, but I'm not sure how that would negatively affect the rip, and I don't think it would jibe with AccuRip. I suspect the lack of pre-gaps would be more apparent on gapless/live CDs, but regardless, just turning it off is like the old medical anecdote: "My arm hurts when I bend it like this. Well don't bend it like that." So it doesn't appear that a fix will be forthcoming. Since it happens w my external DVD too, it doesn't appear limited to certain drives or internal vs. external. Oh well...guess we'll keep banging away at it. @jhwalker, is it possible that you've just been lucky so far w your Mac Book Pro, given that it doesn't happen every time for most people?
  6. I'm having the same problems. For the record, I'm using a 2010 Mac Mini aluminum with a superdrive HL-DT-ST DVDRW GA32N, Firmware Revision KC08. Even with pristine CDs I'm having the same problem with the drive getting "hung" during pregap detection. I've had LIMITED success by making sure my settings and desired encoder are already set in XLD before inserting the CD (then quit XLD), so that as soon as the CD appears on the desktop I can launch XLD and hit open CD without having to adjust the settings. If I open the XLD Prefs window or change the encoder profile with the CD already mounted it will hang up 100 percent of the time. 1. My C2 pointers setting has always been unchecked, so this suggestion didn't apply to me. 2. Like some others have said, I don't think this is an itunes issue, it's only XLD. In fact, when I first insert the CD, it shows up automatically in iTunes, but as soon as I select "Open Audio CD" in XLD it automatically unmounts from iTunes (and from the Finder) to begin the pregap detection process. The progress window comes up in XLD but the bar never actually begins moving. 3. Sometimes I get lucky and everything works correctly, so this problem doesn't happen every single time, probably 70 percent of the time (esp. if I mess with the settings after the CD's already mounted). 4. Neither Toast nor Disk Utility are useful for ejecting the CD...both programs report that there isn't even a drive connected to my machine! When the CD is unmounted for pregap detection it's like the drive is "unplugged". 5. I have the same problem with my Lacie external DVD/CD drive, so this problem does appear to be bigger than just issues with the internal Mac Mini drive...it's more systemic. 6. Sometimes it takes me more than one restart to eject the CD, the machine doesn't always respond to the Eject button during startup. To finally get the CD ripped it may take several restarts, making sure to already have my XLD encoder settings set. This is so frustrating !!! Others please keep commenting and making suggestions. Is anyone having this problem on machines other than Minis?
×
×
  • Create New...