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 settings for secure ripping: are mine okay? (Read 27281 times) previous topic - next topic
0 Members and 2 Guests are viewing this topic.

XLD settings for secure ripping: are mine okay?

I know its been discussed already somewhere but are the settings below OK for ripping from FLAC?



Kind Regards

XLD settings for secure ripping: are mine okay?

Reply #1
Sure, they're "OK", i.e. they'll work, but ripping will be a lot slower than it needs to be.

In particular, you're using AccurateRip (good), but you have "Test before copy" set to "Always"...why?  See that nifty option below, "Only when the track does not exist in AccurateRip DB"?  See how that's designed to go hand-in-hand with "Query AccurateRip database to check integrity"?

Also, I've never seen a good explanation for what "Verify suspicious sectors" actually does, but again, with both AccurateRip and T&C (test and copy) on no match selected, I don't see what benefit that could have...maybe it could help on really scratched discs, dunno.

Likewise, try some test rips in Burst mode instead of XLD Secure...if it's significantly faster with that particular drive, then just stick with Burst.  Again, AccurateRip + T&C makes most other "secure" mechanisms unnecessary - only when you come across discs that A) don't exist in the AR database, and/or B) have major problems ripping should you need to use the secure ripping engine.

Lastly, are you ripping to image files with CUE, or single tracks?  If you're ripping to single tracks, you can speed things up further by checking "Don't detect pregap, ISRC and MCN".
"Not sure what the question is, but the answer is probably no."

XLD settings for secure ripping: are mine okay?

Reply #2
Hey, you definitely need to check "Use C2 error pointers", and change Test before copy to the other option.

XLD settings for secure ripping: are mine okay?

Reply #3
Thanks for the good information guys. I really appreciate it. On a side note, what's the benefit/purpose of C2 error pointers?

More importantly, how do I know if my drive supports it?

Kind Regards

XLD settings for secure ripping: are mine okay?

Reply #4
how do I know if my drive supports [C2]?
You could search for it in the DAE Drive Features Database.

Hey, you definitely need to check "Use C2 error pointers", and change Test before copy to the other option.
I wouldn’t be so sure. Our guide to EAC’s drive options, written by users more knowledgeable than me, says:
Quote
This setting was designed to speed up the ripping process by relying on the drive to report all uncorrectable errors instead of reading everything twice and comparing the result. Unfortunately not all drives adhere to the same standard as to how this should be done. As a result, errors can go undetected. EAC actually has two tests for this feature.…Neither test can be used to determine whether the setting can be used reliably.…Unless you know that you can use this setting reliably, disable it. If you choose to enable it, make sure you also rely on either Test & Copy or AccurateRip.

XLD settings for secure ripping: are mine okay?

Reply #5
how do I know if my drive supports [C2]?
You could search for it in the DAE Drive Features Database.

There's no need to refer to a database.  Simply testing the option with the drive will suffice.  However, I can say for certain that the Plextor Premium 2 is capable of providing C2 error information.

Our guide to EAC’s drive options, written by users more knowledgeable than me, says:

That was written specifically for EAC.  XLD may make use of C2 pointers differently.

XLD settings for secure ripping: are mine okay?

Reply #6
Oops! Good points. Carry on, then.

XLD settings for secure ripping: are mine okay?

Reply #7
how do I know if my drive supports [C2]?
You could search for it in the DAE Drive Features Database.

There's no need to refer to a database.  Simply testing the option with the drive will suffice.


Using that option with my Macbook internal drive leads to a working set of (securely?) ripped files (and the whole process speeds up considerably, as I assume XLD operates in burst mode), while with another external drive in an USB enclosure XLD starts ripping and then simply hangs, with no error message of any sort: in the end I have to kill the process manually. With this latter drive and the C2 option unchecked, everything works again, only slower of course, especially if the CD I'm ripping is not found in AccurateRip DB (I always set the "verify suspicious sectors" and "test and copy if not..." options).

Should I take this as a certain proof of the external drive not supporting C2 pointers?
... I live by long distance.


XLD settings for secure ripping: are mine okay?

Reply #9
That sounds reasonable.


Ok, but there is not a way to programmatically test this functionality and warn the user before he starts the ripping process?

By the way: this is how XLD sees my external drive (and, if I'm not wrong, the database from the bd1989 post reports it as C2 capable):

Code: [Select]
X Lossless Decoder version 20110703 (135.1)

XLD extraction logfile from 2011-08-09 22:02:49 +0200

Roberto Loreggian / Frescobaldi: Opera Omnia CD15

Used drive : HL-DT-ST DVDRAM GE20LU10 (revision FE06)

Ripper mode             : XLD Secure Ripper
Disable audio cache     : OK for the drive with a cache less than 1375KiB
Make use of C2 pointers : NO
Read offset correction  : 667
Max retry count         : 100
Gap status              : Analyzed, Appended
... I live by long distance.

XLD settings for secure ripping: are mine okay?

Reply #10
EAC and dBpa both have built-in tests to be performed during initial setup.  I suppose one might want to lobby the developer of XLD to do the same.

Also, it is not out of the ordinary to have C2 pointers stop working once an otherwise capable drive is put in an external enclosure.  When this becomes the case, it may be possible for the developer to fix within the software by reducing the amount of data requested by each read command.

XLD settings for secure ripping: are mine okay?

Reply #11
Lastly, are you ripping to image files with CUE, or single tracks?  If you're ripping to single tracks, you can speed things up further by checking "Don't detect pregap, ISRC and MCN".


why not checking "don't detect pregap"??! I think it's useful to know the pregap lenght also if i rip my cd to a single tracks no?! 

XLD settings for secure ripping: are mine okay?

Reply #12
I think it's useful to know the pregap lenght also if i rip my cd to a single tracks

Useful in what way?

XLD settings for secure ripping: are mine okay?

Reply #13
because detecting pregap, silence or noise before or after every song will be saved and respected no?

 

XLD settings for secure ripping: are mine okay?

Reply #14
If you’re ripping to single tracks, the audio from the pregap of track n is appended to track n-1; this is done regardless of whether you’ve instructed XLD to detect the length of that pregap, so that process just consumes time unnecessarily in this case.

XLD settings for secure ripping: are mine okay?

Reply #15
Is there someone that can tell us if the MATSHITA DVD-R UJ-898 (revision HC09) drive support or not the C2 pointers?
XLD don't tell me nothing about it and i have not checked the option during my rips. I will now try a rip with and one without this option selected but still don't understand how to know if it's a good choice to let this option enable or not

Here is the result of my test:

Code: [Select]
X Lossless Decoder version 20111113 (137.1)

XLD extraction logfile from 2011-11-20 17:33:26 +0000

Silverchair / The Best of Volume 1

Used drive : MATSHITA DVD-R  UJ-898 (revision HC09)

Ripper mode : XLD Secure Ripper
Disable audio cache : OK for the drive with a cache less than 1375KiB
[b]Make use of C2 pointers : NO[/b]
Read offset correction  : 102
Max retry count : 20
Gap status   : Not analyzed

TOC of the extracted CD
Track |  Start  |  Length  | Start sector | End sector
---------------------------------------------------------
1  | 00:00:00 | 04:22:50 | 0 | 19699 
2  | 04:22:50 | 03:46:72 | 19700 | 36721 
3  | 08:09:47 | 03:42:63 | 36722 | 53434 
4  | 11:52:35 | 06:01:35 | 53435 | 80544 
5  | 17:53:70 | 05:19:67 | 80545 |  104536 
6  | 23:13:62 | 04:27:33 | 104537 |  124594 
7  | 27:41:20 | 04:02:62 | 124595 |  142806 
8  | 31:44:07 | 03:35:40 | 142807 |  158971 
9  | 35:19:47 | 04:01:10 | 158972 |  177056 
  10  | 39:20:57 | 04:01:55 | 177057 |  195186 
  11  | 43:22:37 | 04:33:08 | 195187 |  215669 

List of alternate offset correction values
#  | Absolute | Relative | Confidence
------------------------------------------
1  | 30  | -72  | 31
2  |  -536  |  -638  |   4

AccurateRip Summary
Track 01 : OK (confidence 7)
Track 02 : OK (confidence 7)
Track 03 : OK (confidence 7)
Track 04 : OK (confidence 7)
Track 05 : OK (confidence 7)
Track 06 : OK (confidence 7)
Track 07 : OK (confidence 7)
Track 08 : OK (confidence 7)
Track 09 : OK (confidence 6)
Track 10 : OK (confidence 7)
Track 11 : OK (confidence 7)
->All tracks accurately ripped.
Code: [Select]
X Lossless Decoder version 20111113 (137.1)

XLD extraction logfile from 2011-11-20 17:49:43 +0000

Silverchair / The Best of Volume 1

Used drive : MATSHITA DVD-R  UJ-898 (revision HC09)

Ripper mode : XLD Secure Ripper
Disable audio cache : OK for the drive with a cache less than 1375KiB
[b]Make use of C2 pointers : YES[/b]
Read offset correction  : 102
Max retry count : 20
Gap status   : Not analyzed

TOC of the extracted CD
Track |  Start  |  Length  | Start sector | End sector
---------------------------------------------------------
1  | 00:00:00 | 04:22:50 | 0 | 19699 
2  | 04:22:50 | 03:46:72 | 19700 | 36721 
3  | 08:09:47 | 03:42:63 | 36722 | 53434 
4  | 11:52:35 | 06:01:35 | 53435 | 80544 
5  | 17:53:70 | 05:19:67 | 80545 |  104536 
6  | 23:13:62 | 04:27:33 | 104537 |  124594 
7  | 27:41:20 | 04:02:62 | 124595 |  142806 
8  | 31:44:07 | 03:35:40 | 142807 |  158971 
9  | 35:19:47 | 04:01:10 | 158972 |  177056 
  10  | 39:20:57 | 04:01:55 | 177057 |  195186 
  11  | 43:22:37 | 04:33:08 | 195187 |  215669 

List of alternate offset correction values
#  | Absolute | Relative | Confidence
------------------------------------------
1  | 30  | -72  | 31
2  |  -536  |  -638  |   4

AccurateRip Summary
Track 01 : NG
Track 02 : NG
Track 03 : OK (confidence 7)
Track 04 : NG
Track 05 : OK (confidence 7)
Track 06 : NG
Track 07 : NG
Track 08 : OK (confidence 7)
Track 09 : NG
Track 10 : NG
Track 11 : NG
->3 track(s) accurately ripped, 8 track(s) not, 0 track(s) not found
so what can i assume with this? The entire operation w/no C2 pointer was the same (14 minutes for the entire rip)

XLD settings for secure ripping: are mine okay?

Reply #16
and this another result for another cd (with C2 enable)

Code: [Select]
AccurateRip Summary
    Track 01 : NG
    Track 02 : OK (confidence 6)
    Track 03 : OK (confidence 6)
    Track 04 : OK (confidence 6)
    Track 05 : NG
    Track 06 : OK (confidence 6)
    Track 07 : OK (confidence 6)
    Track 08 : OK (confidence 6)
    Track 09 : OK (confidence 6)
    Track 10 : NG
    Track 11 : NG
        ->7 track(s) accurately ripped, 4 track(s) not, 0 track(s) not found

XLD settings for secure ripping: are mine okay?

Reply #17
Just to add a data point -- I have exactly the same drive and have observed the same behavior.  If I rip without "Use C2 error pointers" enabled, AR reports all tracks ripped successfully.  If I enable it, most if not all tracks will fail ("NG") -- at least for the 2 discs I tried this with.  Either the drive doesn't support it, or the implementation is buggy.  In any case, it seems to me if the AR checksums match the rip is good, so whether or not C2 error pointers are supported or not is merely a curiosity (right?).

Is there someone that can tell us if the MATSHITA DVD-R UJ-898 (revision HC09) drive support or not the C2 pointers?


XLD settings for secure ripping: are mine okay?

Reply #18
If you’re ripping to single tracks, the audio from the pregap of track n is appended to track n-1; this is done regardless of whether you’ve instructed XLD to detect the length of that pregap, so that process just consumes time unnecessarily in this case.

i also tried some test with and without checking the "detect pre-gap, ISRC and MCN" and i found something maybe strange and i would like to know from you what do you think about:

With the option disabled, this is the result:
Code: [Select]
[b]Gap status              : Not analyzed
[/b]

Track 01
    Filename : /Users/Jedi82/Downloads/RIP/Calvin Harris/Ready for the Weekend/01 The Rain.flac
    [b]Pre-gap length : 00:02:00[/b]

    Track gain            : -10.34 dB
    Peak                  : 0.988556
    CRC32 hash            : A4362D54
    CRC32 hash (skip zero) : E1375777
    AccurateRip signature  : 7665CB1D
        ->Accurately ripped! (confidence 3)

Track 02
    Filename : /Users/Jedi82/Downloads/RIP/Calvin Harris/Ready for the Weekend/02 Ready for the Weekend.flac
[b]NONE HERE[/b]
    Track gain            : -9.73 dB
    Peak                  : 0.988556
    CRC32 hash            : F5DFF4D5
    CRC32 hash (skip zero) : 29E444A8
    AccurateRip signature  : 98F1DFE9
        ->Accurately ripped! (confidence 3)

Track 03
    Filename : /Users/Jedi82/Downloads/RIP/Calvin Harris/Ready for the Weekend/03 Stars Come Out.flac
[b]NONE HERE[/b]
    Track gain            : -8.94 dB
    Peak                  : 0.988556
    CRC32 hash            : D5D4BF1B
    CRC32 hash (skip zero) : 78150325
    AccurateRip signature  : 0887F9B0
        ->Accurately ripped! (confidence 3)
With the option enabled, this is the result:
Code: [Select]
[b]Gap status			  : Not analyzed[/b]

Track 01
Filename : /Users/Jedi82/Downloads/RIP/Calvin Harris/I Created Disco/01 Merrymaking at My Place.flac
  [b] Pre-gap length : 00:02:00[/b]

Track gain : -8.95 dB
Peak   : 0.944122
CRC32 hash : B9C79FE7
CRC32 hash (skip zero) : 6C2C2E85
AccurateRip signature  : 48AC3768
->Accurately ripped! (AR2, confidence 2)
Statistics
Read error   : 0
Jitter error (maybe fixed)   : 0
Retry sector count   : 0
Damaged sector count : 0

Track 02
Filename : /Users/Jedi82/Downloads/RIP/Calvin Harris/I Created Disco/02 Colours.flac
[b] Pre-gap length : 00:01:07
[/b]
Track gain : -8.86 dB
Peak   : 0.944122
CRC32 hash : 05B68A7D
CRC32 hash (skip zero) : 4EA6B5B5
AccurateRip signature  : D33D8810
->Accurately ripped! (AR2, confidence 2)
Statistics
Read error   : 0
Jitter error (maybe fixed)   : 0
Retry sector count   : 0
Damaged sector count : 0

Track 03
Filename : /Users/Jedi82/Downloads/RIP/Calvin Harris/I Created Disco/03 This Is the Industry.flac
[b] Pre-gap length : 00:00:62
[/b]
Track gain : -8.95 dB
Peak   : 0.944122
CRC32 hash : B9C04732
CRC32 hash (skip zero) : E43E29A5
AccurateRip signature  : 61AAA7C9
->Accurately ripped! (AR2, confidence 2)
Statistics
Read error   : 0
Jitter error (maybe fixed)   : 0
Retry sector count   : 0
Damaged sector count : 0
so what's the point? I always rip my cd in single flac files but if i don't check the option, XLD will however append the gap or not?

XLD settings for secure ripping: are mine okay?

Reply #19
Yes, the gap is ripped either way when you are ripping using the default method. As I said! All you are seeing there is a cosmetic difference: the software either reports the existence of the pregap, because it has checked for it; or doesn’t, because it hasn’t.

The exception is track 1, which always has a pregap that is either 2 s of silence—as you can see—or, rarely, actual audio of some other length. Either way, this is not ripped by default. In your case, it doesn’t matter, just like the above.

XLD settings for secure ripping: are mine okay?

Reply #20
ok db1989, always nice to read your posts that are so so clear and useful. So ok, i can maintain my first attempt of rip without the exact lenght of the gap write in the log file. The important thing is that i know that XLD will always, also if he don't read or detect nothing, save the gap on the various tracks!

XLD settings for secure ripping: are mine okay?

Reply #21
Glad to help! Yeah, it won’t affect your audio; so it’s just a matter of whether you want to save / see any need for the info on gap length, ISRC, MCN, etc.

XLD settings for secure ripping: are mine okay?

Reply #22
I just made another test about the "drive support or not the C2 pointers" features with the last version of XLD (07042012) but nothing changed! If i set this parameter to YES, most if not all tracks failed ("NG"). So, it's clear now that i must unchecked this parameter! Hope it not affect the quality of the rip so much!