Vigi, and whence we know, what received offset true? I discussed it with Dremora. Probably changes have been brought in an audiotrack at manufacturing the master-copy (For example: https://redump.info/disc/1431/https://redump.info/disc/2767/). In other words, it's necessary to search for a method of correct offset definition instead of to adjust an audiotrack to the standard.
I can calculate it if the received result will help us to find out true.
did some more reading (that i should have done long ago, would have saved me a lot of worries) and i think i finally understand now why offsets are sample limited. it all looks fairly obvious now.
ECMA-130: 16 F1-Frames
Each Scrambled Sector shall be mapped onto a series of consecutive frames. Each frame consists of 24 8-bit bytes,
numbered from 0 to 23. Byte 0 of the Sector shall be placed in byte 4n of a frame, where n is 0, 1, 2, 3, 4 or 5.
Consecutive bytes of the Sector are placed in consecutive bytes of the frames. Byte 2 351 of a Sector is immediately
followed by byte 0 of the next Sector.
18 Control Bytes - F3-Frames and Sections
A single byte called Control byte is added as first byte to each F2-Frame of 32 bytes. This yields a new F3-Frame of
33 bytes.
The Control byte shall be obtained from a table of 98 bytes as defined in clause 22. The information in the Control
bytes is mainly used for addressing purposes. The bytes in the table are added to 98 consecutive F2-Frames, coming
out of the CIRC encoder, byte 0 of the table first, byte 97 last. This operation yields groups of 98 F3-Frames of 33
bytes each, called Sections. These Sections are asynchronous with the Sectors, i.e. there is no prescribed relation
between the number of the F1-Frame in which the first byte of a Sector is placed and the number of the F3-Frame in
which the first Control byte of the table is placed. Each Section has its own table with Control bytes.
so as i see it, subcode byte may be displaced from data by 24 byte (6 samples) steps (F1 frame). but not only that - sector's starting position (sync) may be 0 to 5 samples off in the first frame. so for example offset +13 = 2 frames (sector/subcode difference) + 1 sample (sync/frame difference - since subcode byte is fixed to frame, this contributes to offset).
so, i think we have whole PMA stream as it was before it got written on a CD (except for a 1st track's pregap, and it may hold data actually (eg. Dreamweb UK PC release), but not that it changes anything, i guess, but interesting to know nevertheless). so if there are differences left it would be mastering then but we should not fix that on file level, imho.
so for intelligent checksums i would imagine a different level of abstraction for an audio stream that would also include those audio gaps that follow/precede data tracks and so checksums would be calculated on this data. LBA-pause would be targeted (+/- about 10 or so sectors maybe) and if ther's large amount of silence it's excluded (back until last meaningful sample and forth until first) and this point is a break in stream. if silence can not be found in position between two tracks - there is no break and thus less audio streams than audio tracks.
it's like Eidolon suggested, i guess, but we should not drop file CRCs it's a backbone of this db - file still is a core element, everything else is just interpretation or additional (less vital) info.
I discussed it with Dremora. Probably changes have been brought in an audiotrack at manufacturing the master-copy (For example: https://redump.info/disc/1431/ https://redump.info/disc/2767/). In other words, it's necessary to search for a method of correct offset definition instead of to adjust an audiotrack to the standard.