IPB

Welcome Guest ( Log In | Register )

 
Reply to this topicStart new topic
What are my CD rips missing?
ggking7
post Jul 15 2010, 01:33
Post #1





Group: Members
Posts: 86
Joined: 17-June 08
Member No.: 54498



I'm about to rip a hundred or so CDs and I'm wondering if I should change my ripping method before I start in.

I use cdrdao on Linux to rip each CD twice, compare the rips digitally, and split and encode to FLAC if the two rips match. I'm confident in this procedure's ability to prevent audible errors because I've never heard one in any of my rips that wasn't also on the CD. Could I be missing out on audible data in any other ways? Maybe due to cdrdao's or my CD drive's capabilities?

This post has been edited by ggking7: Jul 15 2010, 01:34
Go to the top of the page
+Quote Post
SCOTU
post Jul 15 2010, 03:48
Post #2





Group: Members
Posts: 118
Joined: 9-July 10
Member No.: 82156



If you've found no problems to your method why change it?

If you're worried about the time it takes to rip twice, try EAC or dBPowerAmp because they support AccurateRip (i think that's what it's called) that checks your rip against others online to guarantee a good chance of a good rip.

Edit: I guess I suck at remembering things. I've never looked into Linux software for ripping, and my linux heavy friends don't know the difference between good audio and not tongue.gif

This post has been edited by SCOTU: Jul 15 2010, 04:04
Go to the top of the page
+Quote Post
greynol
post Jul 15 2010, 03:50
Post #3





Group: Super Moderator
Posts: 10000
Joined: 1-April 04
From: San Francisco
Member No.: 13167



Nothing has changed in the linux world of ripping since the OP last came by looking for validation for his methods. In the Mac world there is now Rip and in the Windows world there have been improvements to CUETools and dBpoweramp.

The most obvious answer to the question of "What are my CD rips missing?" is AccurateRip verification, though again, the OP was told this last time around.

This post has been edited by greynol: Jul 15 2010, 04:03


--------------------
Your eyes cannot hear.
Go to the top of the page
+Quote Post
spoon
post Jul 15 2010, 09:10
Post #4


dBpowerAMP developer


Group: Developer (Donating)
Posts: 2723
Joined: 24-March 02
Member No.: 1615



>Could I be missing out on audible data in any other ways?

Yes, ripping twice is no guarantee that you have all the audio data, if the drive interpolates an error (and does it on each rip) you will have a block of silence instead of audio.


--------------------
Spoon http://www.dbpoweramp.com
Go to the top of the page
+Quote Post
ggking7
post Jul 15 2010, 22:35
Post #5





Group: Members
Posts: 86
Joined: 17-June 08
Member No.: 54498



I'm happy with the way my procedure handles errors. I'm wondering about issues like audio data in the lead-in or lead-out and audio data in pre-gaps. I thought I remembered reading that that could happen. If so, is the ability to read it dependent on the ripping software and the CD drive? Besides errors and offsets, are there any other possible sources of data loss when ripping?
Go to the top of the page
+Quote Post
mjb2006
post Jul 16 2010, 06:23
Post #6





Group: Members
Posts: 706
Joined: 12-May 06
From: Colorado, USA
Member No.: 30694



QUOTE (ggking7 @ Jul 15 2010, 15:35) *
I'm happy with the way my procedure handles errors. I'm wondering about issues like audio data in the lead-in or lead-out and audio data in pre-gaps. I thought I remembered reading that that could happen. If so, is the ability to read it dependent on the ripping software and the CD drive? Besides errors and offsets, are there any other possible sources of data loss when ripping?


Well you did say you're only concerned about audible data. It's unlikely that you've ever heard the audio that's in that fraction of a second either just before the lead-out or just after the lead-in, and it's unlikely there's ever anything there anyway but all zeroes or very, very quiet noise.

The pre-gap (track 1 index 00) is supposedly read by cdrdao now. I don't know when this feature was added, but all I can say is a bit of Googling reveals that a 2006 post in this very forum said it wasn't possible, but the latest readme says it is when using the read-cd or copy commands...
Go to the top of the page
+Quote Post
ggking7
post Jul 19 2010, 21:18
Post #7





Group: Members
Posts: 86
Joined: 17-June 08
Member No.: 54498



Thanks mjb2006. Ripping CDs is funny. I remember coming to this same realization the last time I tried to get as close to ripping perfection as I could. I think it's due to the lack of a real filesystem on the disc. It feels like a really early attempt at a digital information storage and retrieval system, and of course that's exactly what Redbook is. We can't just copy files, we have to do this digital audio extraction thing which is laughable in today's context.

I know of these forms of potentially lost of misinterpreted audio data when using a secure ripper, but please correct me if my descriptions are off:

read errors (audible)
A secure ripper along with AccurateRip do a near-perfect (perfect?) job of preventing a read error from affecting a reportedly secure rip. A read error affecting a CD rip can be audible.

lead-in/lead-out (inaudible)
The ability to rip the lead-in and lead-out (which can contain audio data) is dependent on the positive or negative orientation of the CD drive's offset, as well as the degree to which it is offset. The amount of data lost due to an inability to rip the lead-in and lead-out is inaudible.

offset (inaudible)
A secure ripper along with AccurateRip can compensate for a CD drive's offset if it is correctly defined, but determining the correct offset can be problematic. Additionally, CDs themselves can have different offsets which would also need to be compensated for in order to extract all of their data. The amount of data lost due to an undefined offset is inaudible.

accurate pre-gaps (audible?)
The method for determining a pre-gap is not standardized. For example, EAC uses 3 different methods which can give consistently different results and none of which can be said to be more accurate than the rest. Can the differences in pre-gap calculation be different enough to produce split files that are audibly different?

Are there other forms of potentially lost of misinterpreted audio data when using a secure ripper? Maybe due to the CD drive's abilities or lack thereof?
Go to the top of the page
+Quote Post
greynol
post Jul 19 2010, 21:56
Post #8





Group: Super Moderator
Posts: 10000
Joined: 1-April 04
From: San Francisco
Member No.: 13167



QUOTE (ggking7 @ Jul 19 2010, 13:18) *
A secure ripper along with AccurateRip do a near-perfect (perfect?) job of preventing a read error from affecting a reportedly secure rip.
Near perfect. Accurate results do not necessarily require re-reading. If re-reads aren't needed then a secure ripper isn't necessary. Not having a result that is verifiable by AR or some other means pretty much necessitates some type of secure technique if you hope to have any confidence that your rips are likely error-free, of course.

QUOTE (ggking7 @ Jul 19 2010, 13:18) *
The ability to rip the lead-in and lead-out (which can contain audio data) is dependent on the positive or negative orientation of the CD drive's offset, as well as the degree to which it is offset.
To my knowledge there is absolutely no evidence that a drive's ability to overread is dependent on the size of it's offset.

QUOTE (ggking7 @ Jul 19 2010, 13:18) *
The amount of data lost due to an inability to rip the lead-in and lead-out is inaudible.
Not necessarily true.

QUOTE (ggking7 @ Jul 19 2010, 13:18) *
A secure ripper along with AccurateRip can compensate for a CD drive's offset if it is correctly defined
Sure, though EAC has been able to compensate for offsets before AR ever existed.

QUOTE (ggking7 @ Jul 19 2010, 13:18) *
but determining the correct offset can be problematic
Only if the person trying to figure out the offset has severely limited resources*. So long as the drive can be plugged into my computer and has "Accurate Stream", I can determine its offset; and this is without relying on AccurateRip.

(*) At the time of this post, AccurateRip claims to have over 500,000 key discs.

QUOTE (ggking7 @ Jul 19 2010, 13:18) *
Additionally, CDs themselves can have different offsets
This is true.
QUOTE (ggking7 @ Jul 19 2010, 13:18) *
which would also need to be compensated for in order to extract all of their data.
This is not necessarily true.

QUOTE (ggking7 @ Jul 19 2010, 13:18) *
The amount of data lost due to an undefined offset is inaudible.
Again, not necessarily true.

QUOTE (ggking7 @ Jul 19 2010, 13:18) *
Can the differences in pre-gap calculation be different enough to produce split files that are audibly different?
Considering that tracks are generally not split on pregap boundaries except for the first track where the pregap boundary is explicitly specified rather than detected, this is largely a moot issue. If one wishes to split on pregap boundaries, then detection differences whether it be a result of the method, or the drive can be audible.

QUOTE (ggking7 @ Jul 19 2010, 13:18) *
Are there other forms of potentially lost of misinterpreted audio data when using a secure ripper? Maybe due to the CD drive's abilities or lack thereof?
Ability to grab HTOA, which is drive-dependent.

This post has been edited by greynol: Jul 20 2010, 06:31


--------------------
Your eyes cannot hear.
Go to the top of the page
+Quote Post
spoon
post Jul 20 2010, 09:43
Post #9


dBpowerAMP developer


Group: Developer (Donating)
Posts: 2723
Joined: 24-March 02
Member No.: 1615



QUOTE
accurate pre-gaps (audible?)
The method for determining a pre-gap is not standardized. For example, EAC uses 3 different methods which can give consistently different results and none of which can be said to be more accurate than the rest. Can the differences in pre-gap calculation be different enough to produce split files that are audibly different?


It disagree, every frame as an MSF time code, the Q & P subchannels can be used to detect the index and MSF, gaps are easy to detect (they have an index of 0 and the time code counts backwards). It should be 100% reliable. Occasionally even on relatively good discs the subchannel is corrupted for a particular frame, this is easily detected with a CRC check, that frame can be disgarded. If that fram happens to be at the exact point of Gap >> non-Gap, the previous frame would be used, so in this senario you would be 1 frame out. Other than that I am happy that gaps be be detected with 99.999% reliability.

I cannot speak for why EAC would have 3 different detection methods, perhaps it was geared for older drives, I happen to know that detection 'B' the default (AFAIK) did not work on a modern blu-ray writer I was testing on.

This post has been edited by spoon: Jul 20 2010, 09:44


--------------------
Spoon http://www.dbpoweramp.com
Go to the top of the page
+Quote Post
greynol
post Jul 20 2010, 17:17
Post #10





Group: Super Moderator
Posts: 10000
Joined: 1-April 04
From: San Francisco
Member No.: 13167



Unlike audio data, subcode information is not protected with redundancy. What's more, there is no requirement that every frame contain index information.

http://www.digital-inn.de/117689-post14.html

Spoon, on what basis can you be sure that only one in one hundred thousand detections will not be perfect?


--------------------
Your eyes cannot hear.
Go to the top of the page
+Quote Post
spoon
post Jul 20 2010, 20:00
Post #11


dBpowerAMP developer


Group: Developer (Donating)
Posts: 2723
Joined: 24-March 02
Member No.: 1615



My testing on clean discs - I was dumping the entire subcode for the whole disc (and many discs), your experience might be different, with different drives, etc.


--------------------
Spoon http://www.dbpoweramp.com
Go to the top of the page
+Quote Post
greynol
post Jul 20 2010, 20:08
Post #12





Group: Super Moderator
Posts: 10000
Joined: 1-April 04
From: San Francisco
Member No.: 13167



So your 99.999% figure is not rooted in mathematics but is merely an arbitrary off-the-cuff remark simply intended to indicate that you are extremely confident in your methods?


--------------------
Your eyes cannot hear.
Go to the top of the page
+Quote Post
spoon
post Jul 20 2010, 21:38
Post #13


dBpowerAMP developer


Group: Developer (Donating)
Posts: 2723
Joined: 24-March 02
Member No.: 1615



My remark was to try to demonstrate (yes off the cuff), that unless it was something like 100 frames in 101 with the error, it is not a problem, example:

1 frame in 100 which had a subcode error, would this really effect the ability to detect gaps? no, 1 track in 100 would have the gap detected 1 frame out.

This post has been edited by spoon: Jul 20 2010, 21:39


--------------------
Spoon http://www.dbpoweramp.com
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: 19th April 2014 - 06:46