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: Conflicting CRC's on the LAST track in dBpoweramp 12.1 (Read 18719 times) previous topic - next topic
0 Members and 1 Guest are viewing this topic.

Conflicting CRC's on the LAST track in dBpoweramp 12.1

Hello, I got a very important problem when I rip, for some reason I get conflicting crc's on the LAST track on most cds I rip, not all cds but most of them.  Cause of security reasons I decided to use 2 Cdrom's when ripping to guarantee matched crc's. So I have understood, there must be some kind of reasons why I only have this problem on the last track! So have anyone any idea of what the problem might be, do I have some of my settings wrong ? I must solve this somehow it would be much appreciated if someone could help me.

Some info of the cdroms and settings I use.

I use Ultra secure mode for both drives.

Plextor 708a, read into Lead-in or lead-out is enabled. Sample offset +30. I have disabled the cache with the FUA command, C2 pointers is enabled.

Plextor 230a (Rebaged 2006 version). This is the drive that has been said to be the best DAE ripper here on Hydrogenaudio, by Spoon (creator of dBpoweramp) and others. Read into Lead-in or lead-out is disabled. The sample offset is set to +738, and this new 203a version does not cache, and C2 pointers is enabled.


Conflicting CRC's on the LAST track in dBpoweramp 12.1

Reply #2
Ok, first of all, an little correction about, it is of course 230a not 203a, it is corrected now.

The CDs where you don't get matching CRCs for the last track do not end in silent samples.


Yes, I did suspect it was something like this, 708a does read lead-in/lead-out, while 230a from what I know don't.  The question is, is there any solution to get around this problem ?
I am quite sure spoon himself told me that this would not matter, cause the overread information was just some meta-data and not really calculated into the final CRC (if I understood him correctely). I really hope there is a solution to this though, otherwise I have bought this 2nd cdrom drive unnecessarily.

Conflicting CRC's on the LAST track in dBpoweramp 12.1

Reply #3
Yes, I did suspect it was something like this, 708a does read lead-in/lead-out, while 230a from what I know don't.  The question is, is there any solution to get around this problem ?
Not with the drives that you have, no, though I suppose you can do a wave comparison to make sure that all but the last 738 samples of the last track are identical between the rips from each drive.

I am quite sure spoon himself told me that this would not matter, cause the overread information was just some meta-data and not really calculated into the final CRC (if I understood him correctely).
You did not understand him correctly.  Overread samples have absolutely nothing to do with metadata.  The last 5 frames of the last track (and the first five frames of the first track) do not figure into the AccurateRip CRC calculation in order to address this very problem.  This is not at all the case for the CRCs displayed within dBpowerAMP.

Why be so paranoid?  Although less likely, it's still possible to get consistent errors between drives.  So long as you aren't just comparing to your own submission, AccurateRip is your best guarantee when it can verify your rips.

Conflicting CRC's on the LAST track in dBpoweramp 12.1

Reply #4
Yes, I did suspect it was something like this, 708a does read lead-in/lead-out, while 230a from what I know don't.  The question is, is there any solution to get around this problem ?
Not with the drives that you have, no.
I am quite sure spoon himself told me that this would not matter, cause the overread information was just some meta-data and not really calculated into the final CRC (if I understood him correctely).
You did not understand him correctly.  The last 5 frames of the last track (and the first five frames of the first track) do not figure into the AccurateRip CRC calculation in order to address this very problem.  This is not at all the case for the CRCs displayed within dBpowerAMP.


This is really bad news, what would be your advice ?
Maybe I have to compromise ?
I guess I could disable the lead-in/lead-out, assuming that this 5 last/first samples is mostly just silence anyway.

Conflicting CRC's on the LAST track in dBpoweramp 12.1

Reply #5
This is really bad news, what would be your advice ?
Maybe I have to compromise ?
Read for my edits above.

I guess I could disable the lead-in/lead-out, assuming that this 5 last/first samples is mostly just silence anyway.
This won't help.

Conflicting CRC's on the LAST track in dBpoweramp 12.1

Reply #6
This is really bad news, what would be your advice ?
Maybe I have to compromise ?
Read for my edits above.

I guess I could disable the lead-in/lead-out, assuming that this 5 last/first samples is mostly just silence anyway.
This won't help.


Yes sure I am paranoid, but with a good reason,  I must be able to trust my rips are authentic, if you only rip with one drive you never exclude the possibility of temporary problems in a certain time etc..remember many parts in the process is included in the process, not only the drive itself, if you have two rips from two different drives/times you have a lot higher probability that your rip is "ok". And yes Accuraterip is very good when the cd is indexed in database, but that is not often the case for me, I rip quite rare music but also new music, in general it takes quite long time before a new cd release has many rips in the database.

Now I have not heard yet what spoon has said about this, but I must say I am little disappointed  I really though that this would not matter.  However, this would be an desirable feature in future versions, to have an options like "exclude lead-in/lead-out data in CRC checksum"

Conflicting CRC's on the LAST track in dBpoweramp 12.1

Reply #7
if you only rip with one drive you never exclude the possibility of temporary problems in a certain time etc..remember many parts in the process is included in the process, not only the drive itself, if you have two rips from two different drives/times you have a lot higher probability that your rip is "ok".
Temporary problems? 

However, this would be an desirable feature in future versions, to have an options like "exclude lead-in/lead-out data in CRC checksum"
The amount of overread data changes as the offset changes.

I'd let this go if I were you.

Conflicting CRC's on the LAST track in dBpoweramp 12.1

Reply #8
if you only rip with one drive you never exclude the possibility of temporary problems in a certain time etc..remember many parts in the process is included in the process, not only the drive itself, if you have two rips from two different drives/times you have a lot higher probability that your rip is "ok".
Temporary problems? 

However, this would be an desirable feature in future versions, to have an options like "exclude lead-in/lead-out data in CRC checksum"
The amount of overread data changes as the offset changes.

I'd let this go if I were you.


Yes this does not look good this, really tragic...I still hope Spoon will come here with some miraculous solution though! 

Luckily this 230a was relatively cheap, the 708a was imported from  USA for like $230 (this drive is very rare now days), so despite all good things I have heard about px 230a I think I will still use 708a as my primary drive. I have also bought an Lite-On SHM-165H6S for this purpose before I heard about px 230, it is also supposed to be a very good/fast DAE ripper. But it seams to be hard to find info about this drive, I am not sure if this drive read lead-in/lead-out (hopefully it do!), neither sure of the offset value it use.

Conflicting CRC's on the LAST track in dBpoweramp 12.1

Reply #9
I will not repeat (for sanity) what I have said about overreading:

http://forum.dbpoweramp.com/showthread.php...ost&t=14999

If you ditch the 230a and use the 708a, you might find the quality of your rips goes down for damaged cds (230a outperforms the 708a on my tests).

For the last 2352 bytes of an audio cd, there should be no audio, maybe static.

You can view accuraterips crcs (which do not contain the first / last 5 sectors) if you switch on the detailed logs (secure settings).

Conflicting CRC's on the LAST track in dBpoweramp 12.1

Reply #10
I will not repeat (for sanity) what I have said about overreading:

http://forum.dbpoweramp.com/showthread.php...ost&t=14999

If you ditch the 230a and use the 708a, you might find the quality of your rips goes down for damaged cds (230a outperforms the 708a on my tests).

For the last 2352 bytes of an audio cd, there should be no audio, maybe static.

You can view accuraterips crcs (which do not contain the first / last 5 sectors) if you switch on the detailed logs (secure settings).


Thank you spoon, this was somewhat helpful, this give a reference point to hold onto indeed.  And yes I did inded try, the LBA value does indeed match each other. But I still wonder, do you Spoon have any plans to make it possible to change the way the program calculate the CRCs ? theoretically this should not be hard to do, to just ignore the last 2352 bytes when calculating the crcs, atleast you should had the option to do this, if you want to compare crc's with different drives as me. Sure the LBA's is a proof, but does not look very convincing when the crc's are not matching in the logfile, especially on 1 track albums like often is the case for me.

Conflicting CRC's on the LAST track in dBpoweramp 12.1

Reply #11
We do give a CRC that is not offset effected, it is in the accuraterip results, you ca write these to the same folder as your audio files, or display them as information after ripping.

Conflicting CRC's on the LAST track in dBpoweramp 12.1

Reply #12
So can anyone explain to me what is the difference exactly between CRC and LBA, why do they use two checksums instead of one "xxxx to xxxx" , I want to know the difference. And how reliable is LBA compared to CRC ?

If in my case, the LBA is identical on both my rips on both drives, does this mean I have a identical rip (besides the overread data in the last track) ?

Conflicting CRC's on the LAST track in dBpoweramp 12.1

Reply #13
LBA = Logical Block Address. It is not a checksum.
daefeatures.co.uk

Conflicting CRC's on the LAST track in dBpoweramp 12.1

Reply #14
If in my case, the LBA is identical on both my rips on both drives, does this mean I have a identical rip (besides the overread data in the last track) ?

No.  Use the AccurateRip CRCs found in the log as Spoon suggested.

Conflicting CRC's on the LAST track in dBpoweramp 12.1

Reply #15
If in my case, the LBA is identical on both my rips on both drives, does this mean I have a identical rip (besides the overread data in the last track) ?

No.  Use the AccurateRip CRCs found in the log as Spoon suggested.


I am still intrested to understand the meaning of "LBA". And greynol, I have enabled "complete log" in secure settings, yet in my rip log I see no "accurate rip CRC", only the usual CRC and LBA. Or did I misunderstood you, did mean LBA ? or how do I get the accurate rip CRC ?

This is what my log shows..

Track 1:  Ripped LBA 0 to 62398 (13:51) in 1:48. Filename: L:\artist\tribute - artist- 01 - Track 1.wav
  Secure  [Pass 1, Ultra 1 to 2]
  CRC32: 6C30C911

 

Conflicting CRC's on the LAST track in dBpoweramp 12.1

Reply #16
As was already said, LBA means logical block address.  From the perspective of the CD drive, this is the point in time where the track starts and ends in frames (1 frame = 1/75 second = 588 samples).  This number is not a checksum.  Furthermore, LBA really only applies to computer optical drives, the disc itself is indexed in an entirely different way as described in the Red Book standard.

I was under the impression that dBpA R12 puts the AR checksum in the log file, but this does not appear to be the case.  There may be a setting somewhere that I've overlooked.

Conflicting CRC's on the LAST track in dBpoweramp 12.1

Reply #17
As was already said, LBA means logical block address.  This is the point in time where the track starts and ends in frames (1 frame = 1/75 second = 588 samples).  This number is not a checksum.

I was under the impression that dBpA R12 puts the AR checksum in the log file, but this does not appear to be the case.  There may be a setting somewhere that I've overlooked.


Alright , this is something Spoon will have to confirm, cause I do not find any such option. I really hope so though.

Conflicting CRC's on the LAST track in dBpoweramp 12.1

Reply #18
My mistake, AR crcs are not shown in R12, I will add to R13.

Conflicting CRC's on the LAST track in dBpoweramp 12.1

Reply #19
My mistake, AR crcs are not shown in R12, I will add to R13.


ah
This will most likely delay my project even further, when do we expect R13 to be released ?
To use two different drives and then have conflicting CRCs in the logs is not acceptable, then the whole idea
of using two drives and two reference points is becoming meaningless.
However with AR CRCs matching in the log file it would be ok.

Conflicting CRC's on the LAST track in dBpoweramp 12.1

Reply #20
R13 is an on, going project, this addition might be made within 2 weeks, it is easy.

Conflicting CRC's on the LAST track in dBpoweramp 12.1

Reply #21
R13 is an on, going project, this addition might be made within 2 weeks, it is easy.


Thank you spoon, I really really hope two weeks. I interpret that as it will be included in  R12.4 ?



Conflicting CRC's on the LAST track in dBpoweramp 12.1

Reply #24
EAC presents AR CRCs, so if you really must do it this way and don't want to wait...


Thanks for the info, I was unaware of this, but no, I will give Spoon a chance, since I really like his program!
But if it takes too long, EAC might be my only alternative.