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: Is Secure Mode Ripping needed with AccurateRip? (Read 14695 times) previous topic - next topic
0 Members and 1 Guest are viewing this topic.

Is Secure Mode Ripping needed with AccurateRip?

I'm about to re-rip my collection into FLAC format so I'd like it if the rips went as fast as possible.  I was thinking about ripping all the disks in burst mode with AccurateRip and only using secure mode on disks that fail the AccurateRip check the first time out.  This seems to be at least 4x faster most of the time.

Can errors still slip through this way?  I ask because some "enthusiast" sites don't seem to trust a rip that hasn't used BOTH secure ripping and AccurateRip.  I have a Plextor 24/10/40A and use the latest EAC for ripping. 

Sorry if I'm re-hashing an old topic, I searched the boards before posting this and got mix of old, new and sometimes confusing results, so I'm looking for a little confirmation.

Is Secure Mode Ripping needed with AccurateRip?

Reply #1 –
Quote from: Milo on
I was thinking about ripping all the disks in burst mode with AccurateRip and only using secure mode on disks that fail the AccurateRip check the first time out. [...]

Can errors still slip through this way?  I ask because some "enthusiast" sites don't seem to trust a rip that hasn't used BOTH secure ripping and AccurateRip.


Your plan sounds fine to me. Errors can slip through regardless of whether you use a 'secure' mode. Getting a secure rip means the data was just consistent (maybe consistently bad) across re-reads, and usually involves trusting the drive to detect an error before a re-read even occurs. Getting an AccurateRip match also just means the data was consistent across multiple rips, but by different people, so it's a better but not infallible indicator of whether it was truly error-free.

In my limited experience, rip-sharing 'enthusiast' sites seem to be populated by hoarders more concerned with creating as many hoops for each other to jump through than with actually, y'know, listening to music. It's like "how can I enjoy this music when I don't even know if whoever ripped it used offset correction?!" I believe this photo sums it up nicely:

Just my humble opinion.

Is Secure Mode Ripping needed with AccurateRip?

Reply #2 –
I know dbPoweramp does what you're asking. I think it rips in burst mode and if it's ok it won't rerip. Only if the AR values are different will it attempt a secure rip.

I'm sure someone else can confirm  I've not used EAC for a while now.

Is Secure Mode Ripping needed with AccurateRip?

Reply #3 –
With the exception of the first five frames of the first track and the last five frames of the last track (and every 65536th sample), a rip verified by AR is secure, even if done in burst mode.

Is Secure Mode Ripping needed with AccurateRip?

Reply #4 –
Quote from: greynol on
With the exception of . . . every 65536th sample . . .
Out of interest, (I remember a previous discussion on it), what is the reason for this? If I had to guess, I'd implicate CRCs. 1 sample in 65536 is hardly a huge cause for concern, but this seems like a strange little issue to leave unaddressed.

Is Secure Mode Ripping needed with AccurateRip?

Reply #6 –
AccurateRip2 is active in dBpoweramp R14 beta (is submitting / using the new CRCs). EAC will also use the new CRC.

Is Secure Mode Ripping needed with AccurateRip?

Reply #7 –
While it may look like I'm making an issue out of it (I am most certainly not!), I am trying to cover as many bases I can so that people don't come along and nitpick.

Is it correct to assume that the first and last five frames of a disc will still not be secure if solely relying upon AR2 verification?

Is Secure Mode Ripping needed with AccurateRip?

Reply #8 –
greynol:
I am not sure if I fully understand AR2 right now (It already took me a while to understand AR1!) so I don't know if it fully answers your question but from Here #5

From Spoon:
Quote
It also has the benifit with track 1 (which currently is only calculated from 5 frames in) for any drive with a + offset it would have the correct CRC1, so all of track 1 could be verified in its entireity (not possible for the last track as majority of drives cannot overread).


For me, as small as those can be, these 10 frames are interesting due to their particular location but ... I must be nitpicking

See Ya.

Is Secure Mode Ripping needed with AccurateRip?

Reply #9 –
Quote from: greynol on
http://www.hydrogenaudio.org/forums/index....showtopic=61468


That thread seems to suggest that it's a bit more than just "every 65,536th sample" missing from the AccurateRip checksum. If I'm reading correctly (and I'm not sure I am), it's every 65,536th right-channel sample in which all 16 bits of the sample are overlooked. But based on the info provided in the 2nd post of the thread, half(!) the right-channel samples have at least 1 bit missing — every 2 samples, 1 bit is missing; every 4, 2 bits are missing, every 8, 16 are missing; and so on — all together resulting in about 3% (not .0015%) of the bits in the file being overlooked. I don't fully understand it, but I think I 'got it' enough to add the following to the AccurateRip article in the wiki:

An optimization oversight in the AccurateRip checksum algorithm results in an unintended loss of accuracy: about 3% of the audio data is not counted in the checksum at all. The left channel's samples are fully included, but half of the right-channel samples are treated as if they're missing anywhere from 1 bit to all 16 bits, 65,536-sample cycle. [http://www.hydrogenaudio.org/forums/index.php?showtopic=61468]Proposals for improving the algorithm, the database, and the database's API are under consideration[/url], but for now, all implementations must continue to use this incorrect algorithm in order to maintain compatibility with existing data in the AccurateRip database.

Hopefully someone with more binary math chops than me can verify that my understanding of the situation is correct.

Is Secure Mode Ripping needed with AccurateRip?

Reply #10 –
Quote from: Milo on
...Can errors still slip through this way?  I ask because some "enthusiast" sites don't seem to trust a rip that hasn't used BOTH secure ripping and AccurateRip...


You should trust AccurateRip way more than secure mode. The chances of you and other people (with different copies of the same CD and different drives) having exactly the same error are extremely small. Avoid looking for this kind of information on "enthusiast" sites. Look for information here, in this site.

Is Secure Mode Ripping needed with AccurateRip?

Reply #11 –
Quote from: Light-Fire on
Quote from: Milo on
...Can errors still slip through this way?  I ask because some "enthusiast" sites don't seem to trust a rip that hasn't used BOTH secure ripping and AccurateRip...


You should trust AccurateRip way more than secure mode. The chances of you and other people (with different copies of the same CD and different drives) having exactly the same error are extremely small. Avoid looking for this kind of information on "enthusiast" sites. Look for information here, in this site.


The key thing for the "enthusiast" sites seems to be the ability to check an EAC log file (though these can be edited, I believe).

I agree with the above entirely.  However, I must point out that when I check a cd out of New York Public Library, which has many rare and out of print cds, and I rip it and get AR (1), I bet sometimes that "other" copy is the same one I just ripped.  Still, different drive, same data, that's a good match.

Plus, how often is there a misread just in one channel?

Is Secure Mode Ripping needed with AccurateRip?

Reply #12 –
Quote from: usernaim on
The key thing for the "enthusiast" sites seems to be the ability to check an EAC log file (though these can be edited, I believe).


Do they think that using AR somehow prevents the ability to check a log?

Quote from: usernaim on
Plus, how often is there a misread just in one channel?


Not just one channel but specific samples and bits in the specific channel.

Is Secure Mode Ripping needed with AccurateRip?

Reply #13 –
Quote from: alondon on
Not just one channel but specific samples and bits in the specific channel.
Well, no, depending on the address, all the bits in the sample can go unaccounted (now I'm the one nitpicking).  Based on what I remember of the algorithm, BOTH left and right channels are discarded when the address is divisible by 64k.*  I just tested it, the left channel is still used in the 64kth sample, though all the bits in the right sample are discarded.  I guess I don't remember the algorithm all that well after all.  Either way it doesn't matter, I was just trying to point out that AR is secure except for some very minor things dealing with the algorithm.  This is assuming the typical definition of secure (without relying on C2 pointers) being that everything is ripped twice and found to be identical.

(*) every 64k is only 16 zeros, not 32; duh!

Is Secure Mode Ripping needed with AccurateRip?

Reply #14 –
reworded for greynol

Not just one channel but all errors must occur in specific samples and bits anywhere from 0 to all 16 in the specific (right) channel .

Is Secure Mode Ripping needed with AccurateRip?

Reply #15 –
Your rewording still doesn't make room for the fact that there is no "specific bit" requirement for the right channel at certain specific samples; in some instances all of the bits in the right channel are nulled in the calculation.

Is Secure Mode Ripping needed with AccurateRip?

Reply #16 –
Quote
Is it correct to assume that the first and last five frames of a disc will still not be secure if solely relying upon AR2 verification?


Correct.

Is Secure Mode Ripping needed with AccurateRip?

Reply #17 –
Quote from: spoon on
Quote
Is it correct to assume that the first and last five frames of a disc will still not be secure if solely relying upon AR2 verification?


Correct.


And what about the last 5 frames of first track in case of drive with negative read offset unable to overread into lead-in? They can't be verified with AR2, can they? And vice versa with the first 5 frames of last track... Or am I missing something? Are you using the AR1 database in this cases?

Is Secure Mode Ripping needed with AccurateRip?

Reply #18 –
>"last 5 frames of first track "

If there is a track after the first track, then the 5 frames does not come into play (as it is in the inner portion of the disc).

Is Secure Mode Ripping needed with AccurateRip?

Reply #19 –
Quote from: spoon on
Quote
Is it correct to assume that the first and last five frames of a disc will still not be secure if solely relying upon AR2 verification?

Correct.

I'm just thinking out loud here, but wouldn't it be possible to design a ripping mode that would always use the most vigorous secure mode for the first 5 and last 5 frames of the disc and otherwise a fast mode? (Unless a track is found to be inaccurate and the ripper tries rereading in a secure mode like dBpoweramp already can do.)

Is Secure Mode Ripping needed with AccurateRip?

Reply #20 –
Quote from: Alex B on
Quote from: spoon on
Quote
Is it correct to assume that the first and last five frames of a disc will still not be secure if solely relying upon AR2 verification?

Correct.

I'm just thinking out loud here, but wouldn't it be possible to design a ripping mode that would always use the most vigorous secure mode for the first 5 and last 5 frames of the disc and otherwise a fast mode? (Unless a track is found to be inaccurate and the ripper tries rereading in a secure mode like dBpoweramp already can do.)

Assuming this is possible (and I see no reason why it wouldn't) is it really worth it? How important are the firat and last 5 frames? Couldn't we just omit those frames from the rip instead?

Is Secure Mode Ripping needed with AccurateRip?

Reply #21 –
Quote
Couldn't we just omit those frames from the rip instead?
I already found 3 or 4 times an error in those 5X2 frames & I haven't specially searched for those ...
It happens more often than you think. So far the 3 or 4 times it was a track 1 difference if I recall well. I dunno if this is meaningfull.

Another exemple: (This is not the pantera exemple that I already posted)

Code: [Select]
01    [56B843BC]    [A95EF29B]
Vs.
Code: [Select]
01    [0AB6F370]    [E74FB64F]

in   
Code: [Select]
[Verification date: 12/08/2009 16:51:09]
[Disc ID: 00148f4f-00a5ea11-780dcf0a]
Track	[ CRC	] Status
 01	[e94d309a] (10/10) Accurately ripped
 02	[181ba98a] (10/10) Accurately ripped
 03	[fc3e4f2c] (10/10) Accurately ripped
 04	[ae04361e] (10/10) Accurately ripped
 05	[a1a9a01c] (10/10) Accurately ripped
 06	[85aec5de] (10/10) Accurately ripped
 07	[42afda65] (10/10) Accurately ripped
 08	[d83ae094] (10/10) Accurately ripped
 09	[7f824213] (10/10) Accurately ripped
 10	[35181ab6] (10/10) Accurately ripped

Track	[ CRC32  ]	[W/O NULL]	
 --	[7B28CBE2]	[5D4F0BC2]	
 01	[56B843BC]	[A95EF29B]	
 02	[1F0E8F7D]	[A4DF6C61]	
 03	[F033967B]	[978E9D94]	
 04	[45807D0E]	[A15C1CEB]	
 05	[9F3BFCA3]	[0F9FA1BE]	
 06	[63C47C96]	[61A312AD]	
 07	[56FCC981]	[A14DD8BC]	
 08	[1616238C]	[9011207F]	
 09	[07CCC9E8]	[B5B15958]	
 10	[FC15F82B]	[5B26D09B]

[Verification date: 12/08/2009 16:56:18]
[Disc ID: 00148f4f-00a5ea11-780dcf0a]
Track	[ CRC	] Status
 01	[e94d309a] (10/10) Accurately ripped
 02	[181ba98a] (10/10) Accurately ripped
 03	[fc3e4f2c] (10/10) Accurately ripped
 04	[ae04361e] (10/10) Accurately ripped
 05	[a1a9a01c] (10/10) Accurately ripped
 06	[85aec5de] (10/10) Accurately ripped
 07	[42afda65] (10/10) Accurately ripped
 08	[d83ae094] (10/10) Accurately ripped
 09	[7f824213] (10/10) Accurately ripped
 10	[35181ab6] (10/10) Accurately ripped

Track	[ CRC32  ]	[W/O NULL]	
 --	[A04F2BD2]	[39EDF124]	
 01	[0AB6F370]	[E74FB64F]	
 02	[1F0E8F7D]	[A4DF6C61]	
 03	[F033967B]	[978E9D94]	
 04	[45807D0E]	[A15C1CEB]	
 05	[9F3BFCA3]	[0F9FA1BE]	
 06	[63C47C96]	[61A312AD]	
 07	[56FCC981]	[A14DD8BC]	
 08	[1616238C]	[9011207F]	
 09	[07CCC9E8]	[B5B15958]	
 10	[FC15F82B]	[5B26D09B]

It doesn't matter how small those frames are, if there is a probability that bad thing will happen in those frames. This probability multiplicated by the number of CD ripped each days means that errors in these samples will happens.

The question IMHO is not if whether or not these samples are important, they are. But if whether or not the error is audible in those location. I dunno I didn't try to ABX my exemples yet.

Edit: I just listened to the exemple that I just posted, no glitch is audible. I dunno for the others, I think the Pantera exemple was not audible too, which comforted the idea of truncated data.

Is Secure Mode Ripping needed with AccurateRip?

Reply #22 –
My point about the first and last five frames is that not all drives can read them anyway, so truncation is not uncommon.

If there are any cases where removal of the first or last 1/15 second is audible (and I am not sure there are any such cases), how does this compare to a read error in that data (one that is possibly not caught by "secure" ripping) that causes a loud pop for example?

Is Secure Mode Ripping needed with AccurateRip?

Reply #23 –
Quote from: sauvage78 on
I already found 3 or 4 times an error in those 5X2 frames & I haven't specially searched for those ...

When you brought one of these up, I'm pretty sure we established it wasn't an error.

Is Secure Mode Ripping needed with AccurateRip?

Reply #24 –
Quote from: pdq on
My point about the first and last five frames is that not all drives can read them anyway, so truncation is not uncommon.

Of course the drive can read the first and last five frames of a disc, at least what it thinks are the first and last five frames of a disc.