title
Products            Buy            Support Forum            Professional            About            Codec Central
 
Results 1 to 15 of 15

Thread: Accurate Rip offset CRCs

  1. #1
    dBpoweramp Enthusiast
    Join Date
    Nov 2009
    Posts
    62

    Accurate Rip offset CRCs

    What does it mean when OffsetFindCRC is 0?

    On disc 011-00114e23-009a6038-930b110b, there's a second entry that's entirely zeroes except for a single confidence 2 and its TrackCRC. Even its OffsetFindCRC is zero.

    My disc happens to have the TrackCRC from that second entry, and my disc's calculated OffsetFindCRC matches the OffsetFindCRC from the first entry. So does "0" mean "the same OffsetFindCRC as the previous entry" (or in other words, "this TrackCRC is an alternate CRC, but not a true alternate pressing")?

    If so, does that mean that a true alternate pressing would then follow with non-zero OffsetFindCRCs?

  2. #2
    Administrator
    Join Date
    Apr 2002
    Posts
    39,488

    Re: Accurate Rip offset CRCs

    If CRCs are zero then they are not valid.

  3. #3
    dBpoweramp Enthusiast
    Join Date
    Nov 2009
    Posts
    62

    Re: Accurate Rip offset CRCs

    Quote Originally Posted by Spoon View Post
    If CRCs are zero then they are not valid.
    So what does it mean if a track has a confidence, a valid TrackCRC, but an invalid OffsetFindCRC?

  4. #4
    Administrator
    Join Date
    Apr 2002
    Posts
    39,488

    Re: Accurate Rip offset CRCs

    How long is the track?

  5. #5
    dBpoweramp Enthusiast
    Join Date
    Nov 2009
    Posts
    62

    Re: Accurate Rip offset CRCs

    Quote Originally Posted by Spoon View Post
    How long is the track?
    "LBA 182062 to 212487 (6:45)"

    My disc matches that lone TrackCRC in the second entry, and my discs's OffsetFindCRC matches the (non-zero) one in the first entry.

  6. #6
    dBpoweramp Enthusiast
    Join Date
    Nov 2009
    Posts
    62

    Re: Accurate Rip offset CRCs

    Quote Originally Posted by pjc2 View Post
    "LBA 182062 to 212487 (6:45)"

    My disc matches that lone TrackCRC in the second entry, and my discs's OffsetFindCRC matches the (non-zero) one in the first entry.
    To illustrate:

    Entry 1 of 2, last track:
    Confidence = 3
    TrackCRC = 0xBE10F029
    OffsetFindCRC = 0xE5B3D6B0

    Entry 2 of 2, last track:
    Confidence = 2
    TrackCRC = 0x3457FB3D
    OffsetFindCRC = 0

    Analyzing my disc, I compute:

    TrackCRC = 0x3457FB3D
    OffsetFindCRC = 0xE5B3D6B0

  7. #7
    Administrator
    Join Date
    Apr 2002
    Posts
    39,488

    Re: Accurate Rip offset CRCs

    This is actually correct, looking at the raw submissions:

    There is a CRC 0xBE10F029 and 0x3457FB3D

    but interestingly the offset CRC is the same for both, which suggests that certain drives read the last track one way and other drives read it another way.

  8. #8

    Join Date
    Mar 2006
    Posts
    13

    Re: Accurate Rip offset CRCs

    What I have seen in my own code is that CRCv2 values are always maintained with offsetCRC=0.

    Check out the following discID:

    011-002014f5-01150ab6-9e11960b
    010-000fa622-007d2f6e-8209ba0a
    010-00124472-0090c5d2-810b530a
    031-004bc14d-06808da2-c80fbe1f

    Across 500 rips that I rechecked (using an updated accuraterip-crcgen that is floating around), I found only these 4 CRCv2, so they are still quite rare. But in every case the offsetCRC's were blanked.

    Spoon: Is this your intended behavior for both dbPA and EAC? Does dbPA upload v1 and v2 CRC, but only fills in offsetCRC with v1 submission?

    Is this the mechanism you intended for effectively versioning the CRC results? If so, I recommend updating that sticky post you made describing the algorithm.

    +Reardon

  9. #9
    Administrator
    Join Date
    Apr 2002
    Posts
    39,488

    Re: Accurate Rip offset CRCs

    The offset CRCs just have to appear once, as all AR2 CRCs already have AR CRC1 it will appear with AR CRC1 data first.

  10. #10

    Join Date
    Mar 2006
    Posts
    13

    Re: Accurate Rip offset CRCs

    Why would "all AR2 CRCs already have AR1 CRC"? Would it be true for new discs?

    My original confusion remains: can we _rely_ on blanked offsetCRC's to tell whether the adjoining CRC is v1 or v2? By this I mean when the set of offsetCRC's for a single result, across all tracks, are blank, can we assume then that this is a AR2 CRC?

    As above, I have found records like the following which have results where some of the entries for a single result have both blank and non-blank offsetCRCs. Not just the final or first track. That is, across the 13 tracks of the single result, some tracks have blank offsetCRCs and others have non-blank. Why would this ever happen? Should I not trust results of this kind?

    DiscID: 013-00216d8e-014d5a71-a411ce0d

    In result 34 from this record, track 3 (7:01.72) has:
    Confidence=02
    CRC=4F09F561
    OffsetCRC=00000000

    and track 6 (2:37.55)
    Confidence=02
    CRC=354597EA
    OffsetCRC=E53D0C2C

    This looks bogus. How do I know when I can use a CRC that has an adjoining offsetCRC which is blanked?

    +Reardon
    Last edited by Reardon; 11-29-2010 at 11:05 AM. Reason: add track length, changed to little-endian crc

  11. #11
    Administrator
    Join Date
    Apr 2002
    Posts
    39,488

    Re: Accurate Rip offset CRCs

    An offset CRC appears just once, this CRC has not changed for AR2 it did not have to, so this CRC can appear with AR1 results, or AR2 (if there were no AR 1 results). It is the same disc for AR1 and AR2.

    The OffsetCRC is not tied to a track CRC. It is blanked on purpose.

  12. #12

    Join Date
    Mar 2006
    Posts
    13

    Re: Accurate Rip offset CRCs

    Ok, so the list of offsetCRC's is completely independent of the track CRC's? They just happen to be returned adjacent to one another in the results data. but are really separate lists. This also means that confidence refers only to the number of times you have seen the CRC, not the number of times you have seen the offsetCRC.

    Can I thus presume that once I see a blanked offsetCRC for a track in the results list, that I will not see a non-zero offsetCRC in a following entry for the same track? In other words, a blanked offsetCRC means "there are no more offsetCRCs for this track"?

    +Reardon

  13. #13
    Administrator
    Join Date
    Apr 2002
    Posts
    39,488

    Re: Accurate Rip offset CRCs

    If compiling the list of possible offsetcrcs I would not stop on the first 0, rather keep going (if writing a program to read the AR db).

  14. #14

    Join Date
    Mar 2006
    Posts
    13

    Re: Accurate Rip offset CRCs

    Quote Originally Posted by Spoon View Post
    If compiling the list of possible offsetcrcs I would not stop on the first 0, rather keep going (if writing a program to read the AR db).
    Will do, thanks. And sorry to beat this into the ground, but can you confirm that the confidence byte only refers to the following CRC, not the offsetCRC which follows that. For instance, foobar's verifier displays confidence level for "partial match" (ie offsetCRC match), which doesn't make sense.

  15. #15
    Administrator
    Join Date
    Apr 2002
    Posts
    39,488

    Re: Accurate Rip offset CRCs

    Confidence has no meaning for the offsetcrc

    The partial match is silly as it only matching 0.001% of a track...

Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts
  •