View Issue Details
| ID | Project | Category | View Status | Date Submitted | Last Update |
|---|---|---|---|---|---|
| 0009673 | MMW v4 | Burning / Disc Handling | public | 2012-09-09 01:53 | 2012-10-08 07:11 |
| Reporter | peke | Assigned To | |||
| Priority | urgent | Severity | major | Reproducibility | always |
| Status | resolved | Resolution | fixed | ||
| Product Version | 4.1 | ||||
| Target Version | 4.1 | ||||
| Summary | 0009673: AccurateRip: Verification results incorrect? | ||||
| Description | Secure Rip Show inaccurate RIP even CD is correctly Ripped. If No Info can't be found on Verify it should show that instead Not ripped correctly. | ||||
| Tags | No tags attached. | ||||
| Fixed in build | |||||
| related to | 0008648 | closed | Ludek | Accurate rip error condition workflow needs improvement |
| related to | 0009421 | resolved | Ludek | Ripping fails for some users when 'Secure read' mode is selected (regression on x64) |
| related to | 0009710 | closed | Ludek | Failure to rip the last track of a CD (Secure Read mode) |
| related to | 0009787 | closed | Ludek | Ripping freezes or AV occurs for some users (regression in 4.0.7) |
|
|
I've made a fix here 0009421 on 2012-06-13, but I guess that build 1600 was created earlier. I will ask Petr to create 1601. I guess you are testing on x64 system? Does latest 4.0.6 build also fails for you? |
|
|
It still happen for me on 1601 |
|
|
OK, so please answer these questions: 1. Does this happen with build 4.0.6.1501 ? 2. Does this happen only with secure mode? 3. Does this happen only with this particular CD? 4. Does this happen only with this particular CD drive? 5. Do you use x64 system? 6. What exactly is the problem, the CD is not ripped or the verification fails? 7. Debug log from 1601 would be useful. |
|
|
Here they are: 1. Yes, including 1503 2. No, in all modes 3. No, tested Several OLD CDs I bought over the '90s also http://www.vso-software.fr/products/inspector/inspector.php confirms CD have no errors and thus I used that CD in creating Sample image. 4. No, on all drives 5. Yes 6. It seams that the verify process is the problem like pointed in 3. and in description CD is completely OK. More it looks like iteration of 0008648 which still confuses. Screensshot uploaded to ftp 7. uploaded to FTP a log from 1601 8. I also get EAccessViolation on both 1503 and 1601 as of today both ELFs are uploaded to FTP Strangely at one time I tried to RIP CD I got invalid point operation but could not replicate anyway after. |
|
|
I burnt that image CD that you uploaded (DJ Hits 63) and I can repro that tracks: 1,2,3,4,5,8,9,11 were verified with confidence number 1 (number of people matched your rip) and the others tracks failed to verify. Are your results same? I cannot see it from your debug log as it seems to be somehow incomplete (missing debug messages), probably you start it after MM start. I will try to verify the CD with EAC to see if I will get same results to ensure that it isn't something in MM. I was unable to reproduce the crash you reported. |
|
|
Yes Ludek I get same results. I tested with EAC and from EAC result it reported ARv2 Inaccurate Verify confidence 1, Possible different CD pressing than only one sent in AR database. I think that this should be also represented in MM. EG. It at least few tracks are verifies with only Confidence 1 and others are not validated with same -1 Confidence Different pressing/CD should be assumed. RE ERROR LOGS: Have you checked what they mean as they can be replicated on my PC each time? |
|
|
I also tested with EAC and same results like you, e.g. track 1 in EAC: Couldn't be verified as accurate (confidence 1) [2B915A5A], AccurateRip [166ABECF] (AR v2) in MM: AccurateRip - Track 1. - rip offset: 686 (confidence 1) CRC [166abecf] ARv1 e.g. track 6 in EAC: Couldn't be verified as accurate (confidence 1) [685F7903], AccurateRip [7DCA75ED] (AR v2) in MM: AccurateRip - Track 6. - Rip not accurate (confidence 1) arCRC [7dca75ed] CRC [3ad881b5] ARv1 AccurateRip - Track 6. - Rip not accurate (confidence 1) arCRC [7dca75ed] CRC [ed7b7c2b] ARv2 It means that the only difference is that EAC prefers ARv2 while MM uses ARv1 and in case of failure checks ARv2 like in case of track 6, but the CRC are same. |
|
|
Are you sure that the crash can be replicated with the DJ Hits 63 CD? As you previously didn't report the crash, maybe it is CD related? |
|
|
Yes, in all ELFs DJHits 63 was in Drive. Will do more tests tomorrow, I'll make DBGView to accompany ELFs. Any DLLs with more debug msgs to make things easier? |
|
|
Yes, the AV is in hpCDBurn.dll so the ELF is useless in this case. Use this DLL: http://www.happymonkeying.com/beta/hpCDBurn.dll with 1601 and generate debug log using DBGView and once the crash appears, save the log and attach. |
|
|
The AV should be fixed as 0009787, so verify in 1506 please. |
