libcdio-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Libcdio-devel] CD-TEXT documentation


From: Rocky Bernstein
Subject: Re: [Libcdio-devel] CD-TEXT documentation
Date: Wed, 8 Feb 2012 07:19:29 -0500

On Wed, Feb 8, 2012 at 5:10 AM, Thomas Schmitt <address@hidden> wrote:

> Hi,
>
> > http://www.gnu.org/software/libcdio/cd-text-format.html
>
> It looks so shiny as html. :))
>

Personally, I think the PDF formatting is nicer. But HTML is what the
Internet uses.


>
> -----
>
> 1.2:
>
> One should introduce the "Sony document" before quoting it.
>

Funny you should bring that up. After registering with Sony at I can't find
cdtext.zip on http://www.sonydadc.com

Is this still available online? If not, that should be mentioned.  Also, it
is better to use documents that are still around when possible over those
that have disappeared if that is possible.


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

Changed to:

One can however read this information with an MMC READ TOC/PMA/ATP
command.  (See Section 5.23 of @ref{mmc3r10g.pdf}).



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

Changed to:

This information duplicates information stored elsewhere and that can be
obtained by an MMC READ TOC/PMA/ATP command.




>
> -----
>
> 1.4:
> > Using the .TOC example from Sony documents as an example:
>
> Ain't that one "example" too many for a well sounding sentence ?
>

Yes. Removed first "example".


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

Good. Removed.


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

First sentence changed to :

Text Packs are stored in CD in the sub-channel of the Lead-in of the
disc.

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

I have moved  section Pack Contents after the Top-Level CD Text Categories.
This also contains a reference to the mysterious Sony documents that are
cited later.




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

See above.


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

Good. Removed.


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

 The 12 payload bytes contain pieces of zero terminated data. When
double-byte text is used the zero is a double byte, otherwise it is a
single ASCII NUL.



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

Good. Removed.


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

Ok. Removed part before cdrskin.

>
> -----
>
> 2.2:
> > FILE "cdtext.bin" BINARY
>
> To avoid misunderstandings, "cdtext.bin" should be renamed. E.g. to
> "audiodata.bin".


Renamed.


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

Not sure what you mean. If there are still problems let me know.


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

Added a link to the libburnia project.

>
> -----
>
> Have a nice day :)
>
> Thomas
>
>
>


reply via email to

[Prev in Thread] Current Thread [Next in Thread]