Help - Search - Members - Calendar
Full Version: EAC: bad result with secure mode on a SD-M1612
Hydrogenaudio Forums > CD-R and Audio Hardware > CD Hardware/Software
Fandango
I have three optical drives available for ripping, an old Cyberdrive 400D (CD-ROM), a Toshiba SD-M1612 (DVD-ROM) and a NEC ND-3500AG (DVD±RW). The NEC is connected via IDE, the Cyberdrive and the Toshiba are connected via a Hi-Speed USB2.0 to IDE adapter.

On one track the Toshiba drive gives me a different result (A4989A65) than the other two (CA5A5612). 12 samples mismatch. The track quality was 100% in all three cases, so I'm a bit puzzled.

I tried to rip the same track in burst mode and the CRC was OK (CA5A5612), i.e. the same result as the very old Cyberdrive and the newer NEC. But then I did a test and copy in burst mode, and the test CRC was the old incorrect value (A4989A65) and the copy CRC the correct value (CA5A5612). Also the "incorrect" value turns out to be always the same, it's not random.

Fast mode and Paranoid mode always gave me the CRC the other two drives also retrieved.

I took a look at both the differing samples of both rips in an audio editor and it seems that audio interpolation was applied by the SD-M1612 since the samples only vary sligthly from another. sad.gif

And I thought my NEC would do these kind of things...

After some unsecure rips, I did a secure mode test & copy rip of this track again with the Toshiba and this time EAC's error correction finally kicked in and the the suspicious sectors were re-read (which was not the case with the Cyberdrive/NEC rips, remember). The resulting CRC turned out to be the one that was also retrieved by the Cyberdrive and the NEC (CA5A5612). The thing that makes me uncomfortable is that the track was ripped error free in the test run without EAC's re-reads but the copy run had re-reads, and both gave me the right CRC. One of those discs were the errors go invisible and re-appear again. blink.gif I'll do more rips... this is so erratic.

EDIT: added the actual CRCs so the post makes more sense... tongue.gif
Fandango
<delete>
JeanLuc
Did you turn on cache flushing in EAC?

If my memory serves me right, Feurio! reported the SD-M1612 to be caching ...
Fandango
Hm, yeah. I generally activate that for all my drives.

Now EAC always reports re-reads with the SD-M1612, and the CRC matches those of the NEC (haven't retested with the old Cyberdrive yet). But the NEC can read the problematic sectors without problems in secure mode, no re-reads needed. So the puzzling thing for me is that the SD-M1612 read out those samples wrong at the very first rip several times in a row, always retrieving the same values and so EAC's re-reads didn't kick in, but now the readouts are sometimes wrong and sometimes right...

EDIT: Just noticed that the NEC also read the "other" CRC in the TEST rip and the "first" CRC in the COPY rip... ohmy.gif

The funny thing it's either one of the two and that the difference between the problematic samples is minimal. Well, the Toshiba and the NEC seem to use the same interpolation method, hence only one additional CRC. I feel really uncomfortable about this, because EAC's secure mode isn't really secure with all drives, I guess.
de Mon
1. I can't be sure but I am remembering there was some fuss about Toshiba (or Hitachi) drives in CD related forums several years ago. People were talking about an error in the firmware either hardware. The bug made CD ripping unreliable.
2. What are C2 and CACHE settings for Toshiba drive?
Fandango
C2 error reports are turned off, cache gets flushed.

But read what I've written in the EDIT of my previous post. The NEC has the exact same "problem", same silent error correction with the exact same two edged results. I'll test this track containing these interesting sectors with the Cyberdrive oldtimer now. This drive turned out to be a more error robust reader on Data CDs.

EDIT: Ripped that track with the old Cyberdrive 400D several times in secure mode now... slow 1.7x ...ugh! Track quality is always 100%, so no re-reads and the CRC is CA5A5612. Hm...
greynol
QUOTE(Fandango @ Jan 28 2007, 14:26) *
I feel really uncomfortable about this, because EAC's secure mode isn't really secure with all drives, I guess.
Can you define secure? Depending on your definition, you can make the case that EAC is secure with all drives or it isn't secure with any drives.

You're getting a consistent error for whatever reason and we already know that it's far from impossible to get matching checksums for a bad rip.

How did you determine that CA5A5612 is the correct CRC?
Fandango
QUOTE(greynol @ Jan 29 2007, 01:14) *
You're getting a consistent error for whatever reason and we already know that it's far from impossible to get matching checksums for a bad rip.
But apparently not with a SD-M1612 or a ND-3500A...

QUOTE(greynol @ Jan 29 2007, 01:14) *
How did you determine that CA5A5612 is the correct CRC?
That's the CRC the Cyberdrive gives me, always, without read errors. And as I said this drive performed much better in reading bad data CDs than the other two.
greynol
QUOTE(Fandango @ Jan 29 2007, 07:59) *
QUOTE(greynol @ Jan 29 2007, 01:14) *
You're getting a consistent error for whatever reason and we already know that it's far from impossible to get matching checksums for a bad rip.
But apparently not with a SD-M1612 or a ND-3500A...

I've seen consistent errors with an ND-3500A before and on more than one occasion.
Fandango
From this recent experience the SD-M1612 might be much worse. And I fear those two drives are not an exception.
greynol
QUOTE(Fandango @ Jan 29 2007, 07:59) *
QUOTE(greynol @ Jan 29 2007, 01:14) *
How did you determine that CA5A5612 is the correct CRC?
That's the CRC the Cyberdrive gives me, always, without read errors. And as I said this drive performed much better in reading bad data CDs than the other two.
I forgot to respond to this earlier, sorry about that. smile.gif

When dealing with consistent errors, a lack of re-reads in EAC doesn't mean anything especially when C2 pointers are turned off.
This is a "lo-fi" version of our main content. To view the full version with more information, formatting and images, please click here.
Invision Power Board © 2001-2008 Invision Power Services, Inc.