Re: [Libcdio-devel] CD-Text patches

[Leon Merten Lohse]

On Fri, Dec 02, 2011 at 08:20:41AM +0100, Thomas Schmitt wrote:
> This is stated in MMC for command READ CD.
> MMC-5 6.20.3.2.4 "CD-Text":
>  "CD-Text may appear in CD audio tracks and the lead-in of a CD audio disc.
>   [...]
>   When the Starting Logical Block Address is set to F000 0000h and P-W raw
>   data is selected, the Drive returns P-W raw data from the Lead-in area.
>   [...]
>   If the Starting Logical Block Address is set to FFFF FFFFh after the
>   above command, the Sub-channel data shall be returned from the current
>   location within the Lead-in area.
>  "

Interesting. libcdio uses read toc/pma/atip for this purpose though.
I can't guarantee there is no cd-text in audio tracks on some discs because 
nobody 
ever checked but I also don't know of any implementation. So I think it
is pointless to try.

> 
> I understand it competes with READ TOC/PMA/ATIP, Response Format 0101b:
> MMC-5 6.26.3.7.1:
>  "CD-TEXT Information Descriptor(s) provides Pack Data available in the
>   lead-in area of the disc. Each Pack Data consists of 18 bytes of
>   CD-TEXT information. If a Pack Data is recorded repeatedly on the disc,
>   the device should return it only once."

Yep. But the MMC command libcdio uses (READTOC_FMT_CDTEXT) returns the CD-Text 
area as one
block with all interleaving already done. The Pack Data is one level
below and is processed in cdtext.c. You should not have to worry about
it when you are dealing with binary cdtext data unless you would like to
implement more sanity checks.

> 
> 
> The example Cue Sheet is shown by tables with command SEND CUE SHEET
> in several MMC versions. E.g. Table 55 of MMC-5:
> 
>       : CTL/| TNO |INDEX| DATA| SCMS|   ABSOLUTE TIME
>   Byte: ADR |     |     | FORM|     | MIN | SEC | FRAME
>   -----------------------------------------------------
>     0 :   01    00    00    01    00    00    00    00
>     8 :   01    01    00    01    00    00    00    00
>    16 :   01    01    01    00    00    00    02    00
>    24 :   01    02    00    C0    00    07    29    71
>    32 :   01    02    01    C0    00    07    31    71
>    40 :   01    03    00    C0    00    14    18    03
>    48 :   41    04    00    10    00    19    06    62
>    ...
>    96 :   01    AA    01    01    00    56    37    46
> 
> This one announces Sub-channel Data Form 11b for track 2.
> It is defined in table 567 as:
>  "PACK DATA, Host sends packed data. The Drive writes R-W. The Drive 
>   calculates and overwrites ECC, and performs Interleaving for each PACK."
> 
> In contrast the one of wodim's CD-TEXT recording run:
> 
>       : 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
> 
> Here Sub-channel Data Form of the Lead-in is 01b, about which table 567
> says:
>  "96 [bytes] RAW Data"

I don't know what this means. As I said, I don't think there should be
any CD-Text outside of Lead-In. Maybe Robert William Fuller can tell you
more about subchannels.

> Well, the lack of such a disc kept me from exploring CD-TEXT earlier.

If you have any Sony records, there is a fair chance, they have CD-TEXT
on them.

> I understand it is not the responsibility of the burn program to
> provide correct CD-TEXT, but only to store the given text at the
> right place on the CD.

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


> In man wodim i find this statement:
>  "textfile=filename
>     Write  CD-Text  based  on  information  found in the binary file
>     filename.  This file must contain information in a  data  format
>     defined  in  the  SCSI-3 MMC-2 standard and in the Red Book. The
>     four byte size header that is defined in the  SCSI  standard  is
>     optional and allows to make the recognition of correct data less
>     ambiguous.
>  "

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. Byte 2 and 3 are (always?) 0x00.
0 and 1 form a uint16 holding the length of CD-TEXT data _plus_ 2 bytes
(namely byte 2 and 3). Took me some time to learn this.
Most .cdt files have this header. Some do not. cdtext.cdt does not
either. I don't know if it should be present when you try to burn the
cdtext.

> Hard to tell whether Joerg Schilling was just annoyed by the MMC specs or
> whether he did read something in the Red Book that backs his claim that
> the first four bytes of each pack are optional.
> The question remains what values they should bear if not those defined
> in MMC-3 Annex J.

The values in MMC-3 Annex J are correct. Most CDs respect that
spec.

> 
> Any verification about the meaning of the fourth byte in each text pack
> would be welcome. Just in case that i have to compose CD-TEXT packs from
> a human readable file format.
> man wodim talks of:
>  "[...] CD-Text information from  *.inf  or  *.cue files [...]"
> 
> Our .cue file only mentioned the file cdtext.cdt with already prepared
> packs.
> What is known about these two file formats ?
> Can they bear CD-TEXT as clear text which wodim would have to convert
> to packs of 18 bytes ?

.inf file definitely can. .cdt files only hold raw CDTEXT data as on the
disc. You should be able to send it to the writer as it is.
See my other email for .cue specs.

Regards
Leon