Accurate Rip offset CRCs

[pjc2]

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?

[Spoon]

Re: Accurate Rip offset CRCs

If CRCs are zero then they are not valid.

[pjc2]

Re: Accurate Rip offset CRCs

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?

[Spoon]

Re: Accurate Rip offset CRCs

How long is the track?

[pjc2]

Re: Accurate Rip offset CRCs

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.

[pjc2]

Re: Accurate Rip offset CRCs

"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

[Spoon]

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.

[Reardon]

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

[Spoon]

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.

[Reardon]

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

[Spoon]

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.

[Reardon]

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

[Spoon]

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).

[Reardon]

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).

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.

[Spoon]

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...