On Sun, Feb 5, 2012 at 12:23 PM, Thomas Schmitt <[email protected]> wrote:
> Hi, > > > http://jbum.com/cdg_revealed.html > > Very interesting. (Very very pre-MMC, too.) > > The graphics protocol reminds me of my first self-implemented pixel > graphics > on a VIC-20. > It has nothing to do with CD-TEXT, except that it has to fit into the > same kind of 24 x 6 bit packets. It would be suitable to fill a few MB. > So its use in the program area makes sense. > > Consider to fork a node "CD+G" from "CD Text". Both are only related > by the fact that they use the subchannels R to W for storing data. > Also, they are both extensions to the Red Book that I don't have much to say about other than to draw attention to the fact that there are these extensions. That is why they are lumped together. > > > -------------------------------------------------------------------- > Looking at the commit diff of cd-text.texi: > > Here you altered the technical statement: > > Pack type @kbd{0x87} (Genre Identification) contains 2 binary bytes, > -followed by 0-terminated text. The two bytes constitute a 16-bit > -Big-endian number are decoded as follows: > +followed by an ASCII NUL. For category associated with Big-endian 16-bit > +value is given see @ref{table:categories}. > The NUL comes after the text which describes a sub-genre. You removed the > mentioning of this text. > (The sentence "For category ..." looks somehwat ill, too.) > Ok. Changed. > > ----- > > -Pack type @kbd{0x89} is yet quite unclear. It might be a representation > +Pack type @kbd{0x89} (Second Table of Contents) not yet clear. > > The verb "is" seems to be missing. > Ok. Changed. > > ----- > > -Pack type @kbd{0x89} is yet quite unclear. Especially what the > +It is not unclear what Pack type @kbd{0x89} is used for, and what the > > "not" is surplus and deceiving. > "not" removed. "not's can tie one in knots". > > ----- > > > Have a nice day :) > > Thomas > > >
