Re: [Libcdio-devel] CD-TEXT documentation

[Thomas Schmitt]

Hi,

> http://www.gnu.org/software/libcdio/cd-text-format.html

It looks so shiny as html. :))

-----

1.2:

One should introduce the "Sony document" before quoting it.

-----

1.2:

Maybe one should state with type 0x8d "Closed Information", that the
promise to keep it invisible is not respected by computer attached CD
drives. (The 0x8d packs are returned by MMC command READ TOC/PMA/ATIP.)

-----

1.4:

I would start this with the statement that the user-side purpose of
pack types 0x88, 0x89 is unclear. It seems to mirror information
which is stored on the disc at places which can be read by MMC
commands.

-----

1.4:
> Using the .TOC example from Sony documents as an example:

Ain't that one "example" too many for a well sounding sentence ?

-----

1.4:
> If so, then this seems not to apply to write type SAO, because the
> CUE SHEET format offers no way to express Mode-5 Q.

This statement goes beyond the scope of describing CD-TEXT the format.
I would omit it. (One stumblestone less for the reader.)

-----

1.6:
> The attributes are represented on CD

The term "attribute" was not introduced before.
My sentence from the start of cdtext.txt provided this introduction:
  "CD-TEXT records attributes of disc and tracks on audio CD."
The start of cd-text-format.html does not:
  "CD Text provides a way to give disk and track information in an audio CD."

-----

1.6:

There have been examples of text packs before the format is explained.
(I solved this dilemma by forward references from "Content specification"
 to "Format of a CD-TEXT packs array" where the examples are given.)

-----

1.6:

Here is the introduction of Sony and MMC Annex J, which i would place very
early in the document.

-----

1.6:
> Is Double Byte Character? Is 0 if single byte characters, 1 if double-byte 
> characters.

I would omit the question here. The second sentence is clear on its own.

-----

1.6:
> The 12 payload bytes contain pieces of ASCII NUL-terminated texts

It might be confusing to mention "ASCII NUL" with texts that may be
ISO-8859-1 encoded or even double-byte encoded.
Maybe one should better talk of "0-bytes" (and mention again that double-byte
texts are terminated by double 0-bytes).

-----

1.6:
> (READ TOC/PMS/ATIP could retrieve 3640 packs, as it is limited to 64 KB - 2.)

Seems out of scope of the format definition.
I'd omit this sentence.

-----

2.1:

Beginning at "Purposes specifiers Text Code, Language Code," the text
describes the properties of the v07t reader in libburn.
I would omit that text up to the cdrskin example.

The cdrskin example is quite educational and may help users to produce
their own CD-TEXT discs from separate track files.
Further it corresponds to the CDRWIN .cue example in 2.2.
So it should stay.

-----

2.2:
> FILE "cdtext.bin" BINARY

To avoid misunderstandings, "cdtext.bin" should be renamed. E.g. to
"audiodata.bin". Or a sentence should explain, that this is the file
with the concatenated audio tracks.

(I have now changed my text to FILE "audiodata.bin" BINARY.)

-----

2.2:

Should be coordinated with libcdio.texi @node  CDRWIN BIN/CUE Format.
At least by mutual references.
(My .cue example is tested with wodim and cdrskin.)

-----

References:

libburnia-project.org should be listed here. You mention it and its
cookbook in paragraph 1.6.
Maybe with an additional link to its internal docs despite it is a
living SVN directory:
  http://libburnia-project.org/browser/libburn/trunk/doc

-----

Have a nice day :)

Thomas