XLD settings for secure ripping: are mine okay?, Was: XLD Settings (too vague/TOS #6) Options

[Jason Newton]

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



Kind Regards

[mixminus1]

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

[vvneagleone]

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

[Jason Newton]

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

This post has been edited by Jason Newton: Aug 11 2011, 19:24

[db1989]

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:

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.

[greynol]

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.

This post has been edited by greynol: Aug 11 2011, 20:00

[db1989]

Oops! Good points. Carry on, then.

[Nessuno]

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?

This post has been edited by Nessuno: Aug 12 2011, 11:38

[greynol]

That sounds reasonable.

[Nessuno]

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

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

[greynol]

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.

This post has been edited by greynol: Aug 13 2011, 17:59

[Jedi82]

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?!

[greynol]

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

Useful in what way?

[Jedi82]

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

[db1989]

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.

[Jedi82]

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

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
Make use of C2 pointers : NO
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

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
Make use of C2 pointers : YES
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)

This post has been edited by db1989: Dec 2 2011, 14:09

Reason for edit: [code] to [codebox]

[Jedi82]

and this another result for another cd (with C2 enable)

CODE

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

[FromageTheDog]

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?

[Jedi82]

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

Gap status : Not analyzed


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

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
NONE HERE
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
NONE HERE
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

Gap status : Not analyzed

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

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
Pre-gap length : 00:01:07

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
Pre-gap length : 00:00:62

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?

This post has been edited by db1989: Dec 2 2011, 14:03

Reason for edit: [codebox]ing; replacing GIANT BOLD SHOUTING headings with normal text

[db1989]

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.

This post has been edited by db1989: Dec 2 2011, 14:01

[Jedi82]

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!

[db1989]

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.

[Jedi82]

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!