Re: [Libcdio-devel] CD-Text patches

[Thomas Schmitt]

Hi,

i logged parts of the data traffic between wodim and the drive,
while it performed the CD-TEXT test:
  wodim dev=... -dao -text cuefile=cdtext.cue

The result is that i seem to understand what's going on, but that
it does not resemble much the "Sample CUE SHEET" tables in MMC-3
to MMC-6.
All CD-TEXT goes to Lead-In, whereas in the MMC example, the CD-TEXT
is written to a track.


Does anybody know an occasion or a way how CD-TEXT is written into
tracks ? (I.e is this in any way important ?)


Do we have CD-TEXT input files from other sources which one could
compare with cdtext.cdt ?

I found this stumblestone:
The fourth bytes of each pack in cdtext.cdt seem not to comply to
MMC-3 Appendix J:
"Bit 0 to Bit 3, indicate the Character Position. It is the number
 of character in the strings that belongs to the Text Data Field in
 the previous Pack."
But in cdtext.cdt this nibble seems rather to count the characters
which have been written to the current text by the previous pack.

(It would be interesting to see what happens if bytes 1, 2, 3 are
 plain 0. They seem to be quite redundant. MMC-3 Appendix J defines
 that the texts end by a 0-byte and that they get attribyted to
 whole disc, track 1, track 2, ... in the sequence of their appearance.)


------------------------------------------------------------------
Technical details of wodim's operation:
------------------------------------------------------------------

The last Mode Page 05, that is sent before the Cue Sheet, looks
conventional:

  Executing 'mode select g1' command on Bus 0 Target 2, Lun 0 timeout 200s
  CDB:  55 10 00 00 00 00 00 00 3C 00
  dxfer_len = 60 
    0 : 00 00 20 00 00 00 00 00
    8 : 05 32 52 00 00 00 00 00
   16 : 00 00 00 00 00 00 00 96
   24 : 00 00 00 00 00 00 00 00
   32 : 00 00 00 00 00 00 00 00
   40 : 00 00 00 00 00 00 00 00 
   48 : 00 00 00 00 00 00 00 00
   56 : 00 00 00 00 

According to MMC-5, 7.2 and 7.5 "Write Parameters mode page" this means:
 Byte: Setting
 ----:-------------------------------------------------
 0-7 : Mode Parameter Header (quite meaningless here)
   8 : Page Code is 5
   9 : Page Size is 0x32 = 50 (+2)
  10 : Write Type is 2 = SAO,
       Test Write is on (because i used wodim option -dummy),
       burn-free is enabled
  11 : close the medium after writing (if not dummy mode was active),
       Track Mode is 0,
       Data Block Type is 0 = 2352 bytes of Raw data
  16 : Session Format is 0 = CD-DA or CD-ROM
  23 : Audio Pause Length is 0x96 = 150 (which is default)


The SEND CUE SHEET data look like this:

  Executing 'send_cue_sheet' command on Bus 0 Target 2, Lun 0 timeout 200s
  CDB:  5D 00 00 00 00 00 00 00 40 00
  dxfer_len = 64

      : CTL/| TNO |INDEX| DATA| SCMS|   ABSOLUTE TIME
  Byte: ADR |     |     | FORM|     | MIN | SEC | FRAME
  -----------------------------------------------------
    0 :   01    00    00    41    00    00    00    00
    8 :   01    01    00    00    00    00    00    00
   16 :   01    01    01    00    00    00    02    00
   24 :   01    02    00    00    00    00    04    00
   32 :   01    02    01    00    00    00    06    00
   40 :   01    03    00    00    00    00    08    00
   48 :   01    03    01    00    00    00    0A    00
   56 :   01    AA    01    01    00    00    0E    06

According to MMC-5, 6.33 "SEND CUE SHEET Command" and Table 555 ff.
the tracks are pure audio.

Pack Data are announced only for Lead-In by Data Form 41h.
MMC-5, table 560 decodes this to:
Data Form of Main Data is 1. According to table 562: 0 bytes of payload.
Data Form of Sub-channel is 1. Table 567 says: 96 bytes of subchannel data.

The 18 byte records of CD-Text Packs get chopped and spread over 24 bytes
with upper two bits always zero. (One can read this from MMC-3 Appendix J
and SEND CUE SHEET description ... after some guessing.)

The Lead-in data begin by

  Executing 'write_g1' command on Bus 0 Target 2, Lun 0 timeout 200s
  CDB:  2A 00 FF FF D2 8D 00 02 76 00
  dxfer_len = 60480
   0 : 20 00 00 00 00 05 11 28 19 12 01 16 1B 36 25 23 19 12 01 2F 19 29 11 3D
   1 : 20 00 00 01 03 02 01 34 1A 06 14 20 11 36 39 35 00 04 24 20 15 37 26 3A
   2 : 20 00 04 02 00 36 25 2C 1B 02 01 13 1D 17 09 36 1A 17 19 25 00 00 24 01
   3 : 20 00 08 03 00 04 04 20 11 26 3D 32 19 17 0D 34 08 04 19 35 1B 00 29 01
   4 : 20 00 08 04 03 06 30 20 1B 36 18 20 11 36 39 35 1C 30 01 07 1B 26 1F 18

which can be condensed back to 8 bit bytes:

   0 : 80 00 00 00  T  h  e     V  o  i  c  e     o  f 94 7D
   1 : 80 00 01 0C     t  h  e     G  n  u 00  I     W 79 BA
   2 : 80 01 02 03  i  l  l     S  u  r  v  i  v  e 00 09 01
   3 : 80 02 03 00  A     F  o  r  e  s  t     F  u  l 0A 41
   4 : 80 02 04 0C  l     o  f     G  n  u  s 00  G  n 67 D8

These are identical to the original bytes from file cdtext.cdt.

The start of the Lead-in was read from ATIP
  ATIP start of lead in:  -11635 (97:26/65)
This address may vary on different CD media. It distinguishes
medium manufacturers and products. Here: 12x CD-RW by "CMC Magnetics".
Decimal -11635 is 0xFFFFD28D which is used as start address for
CD-TEXT writing:
  CDB:  2A 00 FF FF D2 8D 00 02 76 00

There are 45 records of 18 bytes in cdtext.cdt. They get repeated until
LBA -150 is reached by the write commands. The end of writing is not
aligned to the end of a CD-TEXT cycle.

This is the last WRITE(10) that goes to Lead-in:

  Executing 'write_g1' command on Bus 0 Target 2, Lun 0 timeout 200s
  CDB:  2A 00 FF FF FE D9 00 00 91 00
  dxfer_len = 13920
  ...
 575 : 87 00 23 0A 00 1B  n  d  z 00 00 00 00 00 00 00 B6 F1
 576 : 8E 00 24 00  0  1  2  3  4  5  6  7  8  9  8  7 0A 29
 577 : 8E 00 25 0C  6 00  D  E  -  G  N  U  -  1  1  - 9C FC
 578 : 8E 01 26 0A  0  0  0  0  1 00  D  E  -  G  N  U 8D B1
 579 : 8E 02 27 06  -  1  1  -  0  0  0  0  2 00  D  E 4A A6

Each WRITE block has 96 bytes and contains 4 records.
Thus 0x91 = 145 blocks transport 13920 bytes.

Then comes a conventional SAO start at LBA -150 (yes, that's normal):

  Executing 'write_g1' command on Bus 0 Target 2, Lun 0 timeout 200s
  CDB:  2A 00 FF FF FF 6A 00 00 1B 00
  dxfer_len = 63504

This transmits 27 blocks of 2352 bytes. Audio. (Silence, i guess.)

After 150 of these blocks begins writing of the first audio track
at LBA 0:

  Executing 'write_g1' command on Bus 0 Target 2, Lun 0 timeout 200s
  CDB:  2A 00 00 00 00 00 00 00 1B 00
  dxfer_len = 63504


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

Have a nice day :)

Thomas