On Mon, Feb 6, 2012 at 10:42 AM, Thomas Schmitt <scdbac...@gmx.net> wrote:
> Hi, > > > xor 0xffff is exactly the same things a mod 2**16. You must be talking > > about something else. > > I understand it like this: > xor 0xffff inverts the lowest 16 bits. > Ooops -- yes, you are correct! But again that's the point. Rather than say xor 0xffff I think it clearer to say invert the lower 16 bits (i.e. xor 0xffff). If nothing else it would prevent someone like me from turning this into an "and 0xffff. > mod 2**16 zeroes the bits above the lowest 16 bits. Like: and 0xffff. > > The CD-TEXT CRC algorithm is ITU-T V.41 with the additional prescription > of inverting the 16 result bits. > > MMC-3 Annex J states: > "CRC Field consists of 2 bytes. Initiator system may use these bytes to > check errors in the Pack. The polynomial is X16 + X12 + X5 + 1. All > bits shall be inverted." > > My understanding of this prescription is backed by Leon's example data, > and by the fact that my burner refused to accept the CD-TEXT data when > i altered the 0x8f packs after computing their CRCs. (Educational mistake.) > The drive took the data as soon as i corrected those 3 CRCs. > > > > I'm just suggesting that rather than describe things bottom > > up, one might keep a human focus. > > I am watching with high interest how you shape the libcdio documentation > and will probably make use of it when it does not move any more. > > > Have a nice day :) > > Thomas > > >
