Track ripped 'accurately' but contains insecure audio?

[Tig]

Hello all,

I'm fairly new to dbpowerAmp, but I have done extensive reading of the website and forum as well as a lot of tinkering with the program itself.

I have a question about an AccurateRip result I got. Here is the log -

 
dBpoweramp Release 13.3 Digital Audio Extraction Log from January 17, 2010 4:55 AM
Drive & Settings
----------------
Ripping with drive 'E:   [Optiarc  - BD ROM BC-5500S ]',  Drive offset: 48,  Overread Lead-in/out: Yes
AccurateRip: Active,  Using C2: Yes,  Cache: 6 KB,  FUA Cache Invalidate: No
Pass 1 Drive Speed: Max,  Pass 2 Drive Speed: Max
Ultra::  Vary Drive Speed: No,  Min Passes: 6,  Max Passes: 12,  Finish After Clean Passes: 2
Bad Sector Re-rip::  Drive Speed: Max,  Maximum Re-reads: 60
Encoder: Wave -compression="PCM"
Extraction Log
--------------
Track 10:  Ripped LBA 153217 to 171947 (4:09) in 4:25. 
  AccurateRip: Accurate (confidence 58)     [Pass 1, Ultra 1 to 6, Re-Rip 64 Frames]
  CRC32: 2EEBC9B6     AccurateRip CRC: FD6F0017     [DiscID: 011-001236ad-009cf38e-860a340b-10]
    Insecure Audio from 00:02:44.760 to 00:02:44.773
--------------
1 Tracks Ripped Accurately

So the track "ripped accurately" according to AccurateRip and yet dbpowerAmp indicates "Insecure Audio" has been detected. Does this mean that dbpowerAmp corrected the insecure audio or that the insecure audio in the time indexes indicated still remains? If the latter, how can the track be considered "AccurateRipped"?

Another (different) question I have is about "CD Pressings". I borrowed a very scratched music CD from my local public library which is the same album I have at home with no scratches. The UPC's, dates and codes on the disc and back of the cases match and have the same tracks and track lengths. For all intents and purposes this is the same album, however the CRC's in dbpowerAmp shown don't match between the two CD's when ripped, even though the AccuraterRip confidence levels are still quite high for both (58-61) and when one ripped track in WAV format (with WAV tags disabled in dbpowerAmp) is compared to the same ripped track from the other CD using Windows File Compare (fc.exe in cmd prompt), it indicates many differences between the files. Long story short, could these discs be different pressings? Even though they look absolutely identical? How common are different pressings? Is it a matter of a different manufacturing plant pressing the CD's with very slightly different machines, etc.? Something like that?

Thanks for any help on these questions.

[Spoon]

Re: Track ripped 'accurately' but contains insecure audio?

It is where the c2 pointers said there was an error, but AccurateRip has identified the error as a false positive, c2 error pointers are not 100% effective (they can miss errors and miss label non-existent errors).

[Porcus]

Re: Track ripped 'accurately' but contains insecure audio?

Long story short, could these discs be different pressings? Even though they look absolutely identical? How common are different pressings? Is it a matter of a different manufacturing plant pressing the CD's with very slightly different machines, etc.?

Yes, most probably. Yes, even so. Fairly common, unfortunately.

And for the latter of your questions: No, not slightly different machines in the physical pressing, only a different number of 0's in the beginning. This is called "offset" in fora like these.
That leads to a slightly different number of milliseconds silence before music starts -- totally insignificant to the listener, but makes the files differ.
Different CD players (CD-ROMs, music CD players ...) will choose different offset numbers without you noticing. That is why dBpoweramp and EAC will check the offset when you start using them, in order to know the number in your particular drive; this is corrected once and for all, and then you can start asking AccurateRip.
Unfortunately, Spoon does not have the power to impose the same smartness upon CD manufactoring plants, and so the same file sent to two plants and pressed might differ: the music is the same, but one of them has a split second more silence at the start, and the other the same at the end.

[Tig]

Re: Track ripped 'accurately' but contains insecure audio?

It is where the c2 pointers said there was an error, but AccurateRip has identified the error as a false positive, c2 error pointers are not 100% effective (they can miss errors and miss label non-existent errors).

Thanks for your reply. To be sure I understand; does this mean that the line "Insecure Audio from 00:02:44.760 to 00:02:44.773" is not an error present in the ripped track because it says "AccurateRip: Accurate"?


Re: CD pressings

Yes, most probably. Yes, even so. Fairly common, unfortunately.

And for the latter of your questions: No, not slightly different machines in the physical pressing, only a different number of 0's in the beginning. This is called "offset" in fora like these.
That leads to a slightly different number of milliseconds silence before music starts -- totally insignificant to the listener, but makes the files differ.
Different CD players (CD-ROMs, music CD players ...) will choose different offset numbers without you noticing. That is why dBpoweramp and EAC will check the offset when you start using them, in order to know the number in your particular drive; this is corrected once and for all, and then you can start asking AccurateRip. ...

Thanks for your reply on this. dBpoweramp/AccurateRip detected my optical drive's offset when I first started using the program, using only one key disc and the process took about 5 seconds. I guess my drive's offset was known by AccurateRip already as I didn't need to use 3 key discs. So since my drive's offset is configured properly, then the different pressings of these discs must contain a different offset is what you're saying. This would result in the ripped files not being completely identical in a binary comparison. I think I understand that correctly

[Spoon]

Re: Track ripped 'accurately' but contains insecure audio?

Yes, you can turn on detailed error logs, it would show it was C2 which marked the frame as bad.