Re: [Libcdio-devel] CD-Text patches

[Thomas Schmitt]

Hi,

Leon Merten Lohse wrote:
> http://digitalx.org/cue-sheet/syntax/

Looks like what i need. Thanks once again.


> CDTEXTFILE points to a binary file with or without size header (see
> other mail).

> > In man wodim i find this statement:
> > The four byte size header that is defined in the  SCSI  standard  is
> >  optional

> Well this is something completely different. 
> @see MMC3-r10 5.23.7 TOC/PMA/ATIP Response Data Format 0101b:
> The wodim manual refers to byte 0 to 3.

Ah. Now my light bulb begins to glow.

I just implemented -vv -toc in cdrskin and wondered why wodim and
cdrecord store the 4 byte header of READ PMA/TOC/ATIP together
with the text packs in the file 'cdtext.dat'.
I imitate them now except that i refuse to overwrite an existing file.

The libcdio test file cdtext.cdt has no such 4 byte header.
Both forms work with wodim textfile=... .
(Before sending the data to the drive, that header has to be cut off
 again.)


> Some burn programs (like cdrecord) implement CD-TEXT packing
> algorithms to convert literal strings into the binary format. I am
> pretty sure they had the red book when they originally wrote it.

Appendix J has about everything i'd need for text carrying packs.
In the past i even understood how a polynomial x^16 + x^12 + x^5 + 1
translates to a checksum algorithm. I happily forgot it meanwhile.
Polynomial division. Hooray algebra !
(Hoorray wikipedia. Its name is "CRC-16-CCITT".)

Well, pack types 0x86 to 0x8f are still quite obscure to me.

Meanwhile i think that cdtext.cdt shows correct Character Position nibbles.
I just had to read the statement in Annex J often enough.

Would you agree with the statements in this snippet out of libburn.h ?
It describes the output of a new API call to read CD-TEXT from Lead-in.
----------------------------------------------------------------------------

    Each pack consists of 18 bytes, of which 4 are header. 12 bytes are pieces
    of 0-terminated texts or binary data. 2 bytes hold a CRC.
    See also MMC-3 Annex J.
    The first byte of each pack tells the pack type (text meaning):
      0x80 = Title
      0x81 = Names of performers
      0x82 = Songwriters
      0x83 = Composers,
      0x84 = Arrangers
      0x85 = Messages
      0x86 = text-and-binary: Disc Identification
      0x87 = text-and-binary: Genre Identification
      0x88 = binary: Table of Content information
      0x89 = binary: Second Table of Content information
      0x8e = UPC/EAN code of the album and ISRC code of each track
      0x8f = binary: Size Information of the Block
    The second byte tells the track number to which the first text piece in
    a pack is associated. Number 0 means the whole album. Higher numbers are
    valid for types 0x80 to 0x85, and 0x8e. There should be one text for each
    track with these types.
    The third byte is a sequential counter. 
    The fourth byte is the Block Number and Character Position Indicator.
    It consists of three bit fields:
      bit7   = Double Bytes Character Code (0= single byte characters)
      bit4-6 = Block Number (groups text packs in language blocks) 
      bit0-3 = Character position. Either the number of characters which
               the current text inherited from the previous pack, or
               15 if the current text started before the previous pack. 
    The two CRC bytes are optional. Polynomial is x^16 + x^12 + x^5 + 1.

----------------------------------------------------------------------------


Currently i am digging in the early code layers of libburn to find the
right place where to let it write CD-TEXT data to Lead-in.
The next days will be interesting.


Have a nice day :)

Thomas