Print

Please login or register.
1 Hour 1 Day 1 Week 1 Month Forever
Login with username, password and session length

[Von]

I have just ripped the same CD with MC16 five times in a row, using secure ripping mode. Out of five rips, only two are identical. All rips were reportedly error free. Three of them had re-reads required to get good data. The two matching rips were among these.

I did this as a test after the first rip required re-reads. I sometimes do this, and in most cases, the results are identical. Not always.

I listened to all the files, and could not hear any errors at the places that required re-tries. Hopefully I will not discover any audible glitches anywhere else either.

Now and then I do a test rip after a rip with no re-tries as well. Usually they match, but not always. I posted such a case a few weeks ago:
http://yabb.jriver.com/interact/index.php?topic=67194.0

I have compared the wav files' md5 checksums. From previous experience, with my workflow, I am confident that different checksums also means mismatch in a bit-by-bit comparison as in EAC, for example. Such a feature would be nice to have in JR MC as well.  I haven't done a bit-by-bit comparison now, as I don't have such software installed.

So, I wonder: How secure is secure ripping statistically? If one out of X albums gets a different result one out of Y times... When is secure no longer secure?

[Matt]

What's the exact drive you're using to rip?  Do you know anything about the specifics of its caching?

This isn't a common problem.  Perhaps there's something specific in the way your drive caches compared to how Media Center handles defeating the cache.

Thanks.

[Von]

This is what the ripping log says about the drive:

Drive D: ATAPI   iHAS124   Y

The Device manager says: ATAPI iHAS 124 Y ATA Device

I believe it is a Lite-On drive, but I don't recall the exact model number. I think it's hard to tell without pulling it out of the pc, which I'd rather not do. I don't know anything about its caching.

[Alex B]

A couple of links:

http://club.myce.com/f44/ihas124-y-problem-305511/
http://forum.digital-digest.com/f167/atapi-ihas124-y-firmware-lite-92232.html

It is a Lite-On model number, but one poster in the club.myce thread says that the "y" model is a rebadget Sony/NEC Optiarc drive, AD-7240S. (...or is it the other way round?)

[dtc]

You can do a bit by bit comparison using the Windows command line command fc. On W7, go to start, type cmd and get to the command line screen. Command line is also in Start All Programs Accessories. Type help fc to see all the options.  What you want is

fc/b file1 file 2

/b does a binary compare.

If I have any problem with a rip, I also use dBpoweramp to rip the file or the problem track. You can get a free trial. Its AccuraterRip feature will compare your rip to that of others.

[Von]

It is a Lite-On model number, but one poster in the club.myce thread says that the "y" model is a rebadget Sony/NEC Optiarc drive, AD-7240S. (...or is it the other way round?)

Thanks. I think I bought it last year, and if I recall correctly, it was branded as a Lite-On.

[Von]

You can do a bit by bit comparison using the Windows command line command fc.

I know, but I believe the feature in EAC is designed to only compare the audio content of a given file. That way, one can be sure metadata does not affect the result.

If I have any problem with a rip, I also use dBpoweramp to rip the file or the problem track. You can get a free trial. Its AccuraterRip feature will compare your rip to that of others.

The thing is, errors seem to occur also when I have no reason to suspect anything. I just do double checks for the hell of it, and sometimes I discover two rips that should both be error free, yet they are different.

[Matt]

Are you ripping individual tracks or as a CUE?  I'm wondering if it could be an offset only difference?

Would you be willing to sell us the drive and CD you're testing with?  Name your price, shipping to Minneapolis included.

Thanks.

[Von]

Are you ripping individual tracks or as a CUE?  I'm wondering if it could be an offset only difference?

I am ripping the entire album to individual tracks. Is there a way I can check if it's just the offset?

Would you be willing to sell us the drive and CD you're testing with?  Name your price, shipping to Minneapolis included.

I guess that could be arranged. I'll PM you about this.

[JohnT]

Does this look like the same drive?
http://www.newegg.com/Product/Product.aspx?Item=N82E16827106289

[Von]

Does this look like the same drive?
http://www.newegg.com/Product/Product.aspx?Item=N82E16827106289

It could be. The front looks identical.

[JohnT]

Could you paste the contents of this registry key here:
HKEY_CURRENT_USER\Software\JRiver\Media Center 17\CD Reader\LastCDROMType-X:
(replace X with the CD drive letter)

Another question, do you ever get re-reads when secure ripping using that drive?  If the log never shows re-reads, there could be a problem with the way we're detecting the drive cache. 

Also, there's a little utility here:
http://download.cdfreaks.com/download/155/cachex.zip
If you just copy this somewhere and then run it from the command line, it will dump out some information about the drive's cache. 
From the command line you would type:
cachex -i -c -n 10 X:
(replace X with the CD drive letter)

[Von]

Could you paste the contents of this registry key here:
HKEY_CURRENT_USER\Software\JRiver\Media Center 17\CD Reader\LastCDROMType-X:
(replace X with the CD drive letter)

This is what it says:
2,1,ATAPI   iHAS124   Y     ,0,0,0

(Note: I am running MC16, not 17 as in your example.)

Another question, do you ever get re-reads when secure ripping using that drive?  If the log never shows re-reads, there could be a problem with the way we're detecting the drive cache. 

Yes, see the first post in this thread.

Also, there's a little utility here:
http://download.cdfreaks.com/download/155/cachex.zip
If you just copy this somewhere and then run it from the command line, it will dump out some information about the drive's cache. 

I've sent you a PM about this.

[Listener]

Secure ripping should produce the same audio content from ripping a CD more than once in almost all cases.  However, there is no such expectation about the entire file.  In particular, any tags stored in the audio files may differ.

If more than one CD/DVD drive was used in ripping the CD, the read offset may well be different.

Ways to compare audio content:

1. Flac files contain a checksum of the uncompressed audio content.

2. Foobar2000 has a command to compare the audio content of WAV files.  I don't remember whether EAC has a similar command.

3. Open the files in an audio editor like audacity and line them up.  Then get the difference.  (This method will work even if read offsets of the drives are different.)

There are other ways as well.

Bill

[Von]

Secure ripping should produce the same audio content from ripping a CD more than once in almost all cases.  However, there is no such expectation about the entire file.  In particular, any tags stored in the audio files may differ.

In this case, I ripped the same album (individual tracks) to wav files, every file with the same file name respectively each time, even the same folder names (even though file name and file location should not affect the checksums). I calculated the md5 checksums immediately after each rip. In what cases would MC produce wav files that should have different md5 checksums?

I have tested this procedure several times before, using EAC's wav comparison tool. Not once have I discovered different md5 checkums for two files that did not also fail the EAC wav comparison test.

Today I installed EAC again, and I have now verified the results I posted in the first post in this thread. Now six rips of this album, all reportedly error free, yielded these results:

Track 1: Four different versions
Track 2: No different versions
Track 3: No different versions
Track 4: Two different versions
Track 5: No different versions

[Von]

A small update: It has happened again with another disc. This was a ten track CD, ripped the first time with re-reads required on tracks 5 and 6, the second time with re-reads on tracks 1, 2 and 6. No unreliable data according to the logs.

The two rips of tracks 4 and 8 are not identical.

I have tested several albums doing multiple rips, also when no re-reads were reported. Usually, they match. However, I am losing confidence.

[JohnT]

I've ordered that burner to see if I can detect any problems we're having with it.

[Von]

Great. I'm looking forward to hear what you find. Please let me know if you need more info, or perhaps one of my troublesome discs.

[Von]

Hi,
Any news on this subject? Have you tried the drive yet?

[JohnT]

Yes, I've posted a link to the results of the testing I did after the drive arrived.  The results on the spreadsheet show the formal testing I performed, in which MC performed correctly.  However, the very first rip I did when the drive arrived showed the same thing you saw - it claimed a secure rip twice on a particular track, but the ripped data didn't compare cleanly afterwards.  I wasn't able to repeat this error, but my theory is that this drive is a caching drive but it's intermittent in it's use of cache so that ripping programs don't detect it correctly.  I don't recommend using a caching drive for ripping (the author of EAC agrees).  If MC doesn't detect that the drive is caching, you may occasionally get the kind of bad rip compares that you were seeing.  As I show in the spreadsheet, MC and EAC didn't detect caching on this drive, another program called Cachex correctly detected the cache on only one of the 10 tests it ran.

http://files.jriver.com/other/rip_testing.xls

[Von]

Thanks, I really appreciate the fact that you're investigating this issue so thoroughly.

So the conclusion would be that this drive is not very well suited for ripping. If I wish to buy a new drive, how can I know for certain that it does not cache?

Provided the theory is correct, do you have any idea why a drive would cache intermittently?

[Listener]

If I wish to buy a new drive, how can I know for certain that it does not cache?

This site used to do detailed reviews with detailed tests of DAE operation (Digital Audio Extraction.)

http://www.cdrlabs.com/Reviews/DVD-Writers/

DAE is less and less a focus of reviews of CD/DVD/Blu-Ray drives
Samsung 222 and 223 series CD/DVD drives don't use cache for reading CD audio disks.  Look just below "CD DAE and CD Speed v4.7.7.16 (DAE) - Pressed CD:"

http://www.cdrlabs.com/Reviews/samsung-sh-s223q-22x-dvdrwram/Performance-CD-Read.html

The "CD read - scan disc" screenshot (with green and yellow areas) and the table just below below are useful for seeing how well the drive does with hard to read CDs.

I have several Samsung drives and find them to be good for ripping CDs.

Note that the designs of Samsung slim drives for laptops, external drives and Blu-Ray drives are different.

Bill

[Von]

I have several Samsung drives and find them to be good for ripping CDs.

Thanks for the tips. I'm curious, what makes you consider the Samsung drives good for ripping? I thought my drive was good as well, it was only when I did re-rips and compared them that I found out something was not right. I suppose most people don't rip twice or more if the first secure rip is reported error free.

[Listener]

I'm curious, what makes you consider the Samsung drives good for ripping?

I provided a link to a review of a Samsung drive and pointed out a few things that are relevant.  Read reviews of other drives on that site and you will see differences.

Your drive is an exception.

I had other drives available while I was ripping and found that the Samsung drives produced the same results in most cases.  When a CD had a problem area, the Samsung drives were more likely to read that area successfully.

Bill

[JohnT]

I don't know enough about drivers for optical drives to understand why the cache would be intermittent.  I gather that for purposes of burning, there is always cache available and of course in that case it's useful for preventing buffer under-runs.  However for audio extraction, most drives don't use it and it just leads to problems for secure ripping programs.