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.
The CDs where you don't get matching CRCs for the last track do not end in silent samples.
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.
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.
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.
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.
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"
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.
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.
I will not repeat (for sanity) what I have said about overreading:
http://forum.dbpoweramp.com/showthread.php...ost&t=14999 (http://forum.dbpoweramp.com/showthread.php?goto=newpost&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).
I will not repeat (for sanity) what I have said about overreading:
http://forum.dbpoweramp.com/showthread.php...ost&t=14999 (http://forum.dbpoweramp.com/showthread.php?goto=newpost&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.
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.
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) ?
LBA = Logical Block Address. It is not a checksum.
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.
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
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.
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.
My mistake, AR crcs are not shown in R12, I will add to R13.
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.
R13 is an on, going project, this addition might be made within 2 weeks, it is easy.
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 ?
I cant speak for spoon, but I interpreted that as it would be added to the R13 beta.
EAC presents AR CRCs, so if you really must do it this way and don't want to wait...
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.
Ok, so I did now try to rip with Plextor 230A and Lite-ON SHM-165H6S, none of them read lead-in/lead-out, yet I got conflicting crcs on the last track when I compare the crcs. Something is wrong here ???
No, nothing is wrong here. This is consistent with what Spoon and I have been telling you.
No, nothing is wrong here. This is consistent with what Spoon and I have been telling you.
Then I did misunderstood you completely. From what I did understand the conflicting crc was due that 708a did read lead-in/lead-out while 230a didn't. So it has nothing to do with the lead-in/lead-out ? , why do I get different crcs, is this because of the "offset" ? in that case my whole idea as using two different drives/reference points when ripping cds falls apart.
From what I did understand the conflicting crc was due that 708a did read lead-in/lead-out while 230a didn't.
That's correct.
So it has nothing to do with the lead-in/lead-out ?
Yes, it does have to do with overreading the lead-in/lead-out.
why do I get different crcs, is this because of the "offset" ?
Yes!
A recap...
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.
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.
From the dbpowerAMP Forum...
http://forum.dbpoweramp.com/showpost.php?p...amp;postcount=6 (http://forum.dbpoweramp.com/showpost.php?p=70815&postcount=6)
Even ignoring the overread data, the main audio data would be different for rives with different offsets.
For more reading...
http://users.fulladsl.be/spb2267/offsets/offsets.htm (http://users.fulladsl.be/spb2267/offsets/offsets.htm)
Ah ok, I finally understand now, thank you. So I guess, the only solution is the acuraterip CRC, which is not affected by CRC. According to Spoon, this will be implanted in dBpoweramp soon. Until then, I will not be able to rip any cds.
Until then, I will not be able to rip any cds.
That's not necessarily true...
...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.
EAC presents AR CRCs, so if you really must do it this way and don't want to wait...
Until then, I will not be able to rip any cds.
That's not necessarily true...
...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.
EAC presents AR CRCs, so if you really must do it this way and don't want to wait...
Yes, I will consider EAC, but as I said earlier, I rather stick with dBpoweramp, he said two weeks to fix this.
And to do it manually and check the waveforms in wavelab etc is not an option either, sounds very time consuming, but you are right, the possibilities is there, again thank you for taking the time to solve this out!
EAC has a wave compare feature that works quite quickly.
I wouldn't be at all surprised if foobar2000 had one as well.
EAC has a wave compare feature that works quite quickly.
I wouldn't be at all surprised if foobar2000 had one as well.
Hmm I might look into that, but I will give Spoon about 2 weeks more or something. I am little surprised that this was not already implanted, it seams like a quite fundamental function ?
it seams like a quite fundamental function ?
I don't think there are a lot of people out there comparing rips between two different drives on a regular basis.
AR CRCs are shown in the Log file as of 1 week ago, check out the latest R13 beta version.
AR CRCs are shown in the Log file as of 1 week ago, check out the latest R13 beta version.
That was only a couple days after you said it might take two weeks, talk about fast service!
AR CRCs are shown in the Log file as of 1 week ago, check out the latest R13 beta version.
This sounds really good, I was not aware of this!
I must say,I am little reserved to use a "beta" version, do I dare to use this version or maybe I am just paranoid ?. Maybe the fundamental functions I am using is already complete in the beta as it is ?
I only use wav,flac and perhaps mp3 for dBpoweramp. Currently I am using 12.1 is the r13 beta considered more complete ?
I know a lot have been fixed in since 12.1.
AR CRCs are shown in the Log file as of 1 week ago, check out the latest R13 beta version.
That was only a couple days after you said it might take two weeks, talk about fast service!
Indeed fast service!
Btw, I do not find any R13 beta, I only find 12.4 Beta.
I did also read that it will be out in December, will the 12.4 include AR offset in the log ?
http://forum.dbpoweramp.com/showthread.php?t=14158 (http://forum.dbpoweramp.com/showthread.php?t=14158)
Thanks greynol
I would still like to know, how "experimental" R13 is in comparison to R12.x
It might be wise to wait to the final 12.4 release which will be out in December, I have no idea...
What I mainly is interested of is the pure output data though, small bugs etc that have no impact on the rip itself is of small relevance in the context.
You're very welcome.
If it's any consolation, I'm still using EAC V0.95 prebeta 5. My next favorite version of EAC is V0.99 prebeta 3. I'm also a very content owner of dBpa 12.2 Reference, so I'm not trying to show any bias; just that version labels don't really bother me when they work.
You're very welcome.
If it's any consolation, I'm still using EAC V0.95 prebeta 5. My next favorite version of EAC is V0.99 prebeta 3. I'm also a very content owner of dBpa 12.2 Reference, so I'm not trying to show any bias; just that version labels don't really bother me when they work.
Yeah I know, Will eac ever be released as an non-beta version, I doubt so
But I must also add regarding dMC, R13 is an "Alpha" not beta... Well, maybe spoon himself can convince me
I do not know if I fee I feel safe using an "alpha" in this context. What I need to know is how much is new, is it just an improvement of R12, or is the whole core new etc ?
If it just an improvement with bugfixes etc , then the R13 Alpha should be way more safe/complete then the R12 I am using now.
R13 is a alpha because it is not feature complete (the definition of alpha), there will be many additions to R13 before it is released. R13 is also built on R12.4, so CD Ripping is stable.
R13 is a alpha because it is not feature complete (the definition of alpha), there will be many additions to R13 before it is released. R13 is also built on R12.4, so CD Ripping is stable.
This is what I wanted to hear, I will give it a try, thank you!
Spoon, will the AR CRC function be included in the 12.4 version that will be released this month ?
No, changing logs should not go in a '.' release (incase people are automating them).
No, changing logs should not go in a '.' release (incase people are automating them).
???
It is too big of a change to go in R12.4