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: What are my CD rips missing? (Read 5750 times) previous topic - next topic
0 Members and 1 Guest are viewing this topic.

What are my CD rips missing?

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?

What are my CD rips missing?

Reply #1
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

What are my CD rips missing?

Reply #2
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.

What are my CD rips missing?

Reply #3
>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.

What are my CD rips missing?

Reply #4
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?

What are my CD rips missing?

Reply #5
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...

What are my CD rips missing?

Reply #6
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?

What are my CD rips missing?

Reply #7
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.

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.

The amount of data lost due to an inability to rip the lead-in and lead-out is inaudible.
Not necessarily true.
 
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.

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.

Additionally, CDs themselves can have different offsets
This is true.
which would also need to be compensated for in order to extract all of their data.
This is not necessarily true.

The amount of data lost due to an undefined offset is inaudible.
Again, not necessarily true.

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.

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.

What are my CD rips missing?

Reply #8
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.

 

What are my CD rips missing?

Reply #9
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?

What are my CD rips missing?

Reply #10
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.

What are my CD rips missing?

Reply #11
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?

What are my CD rips missing?

Reply #12
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.