Re: [Libcdio-devel] CD-Text patches

[Thomas Schmitt]

Hi,

me:
> > I wonder where Shona, Zuku, or Kannada are spoken.

Rocky Bernstein:
> Kannada or Canarese, is a language spoken in India predominantly in the
> state of Karnataka. Kannada ... number roughly 50 million,

Worth to be listed. At least if i list 0x0e "Faroese" (< 50,000 islanders). 

"Zuku" was a typo by me, when i wrote my list from tech3264.pdf annex 3.
Actually it's "Zulu" (South Africa).
"Shona" is spoken in southern africa, too.


me:
> > My own emerging documentation [...]

Leon Merten Lohse:
> We should combine them eventually.

I doubt that it contains much more info than yours. But we should identify
any difference in perception and try to find a common understanding of
the rumors.


> > Can it be that one group of three packs of type 0x8f describes
> > up to 8 blocks ?

> Could be. But as far as I know it does not.

Over night it came to me that there cannot be more than 8 blocks, because
the block number in table J.3 has only three bits.

This supports my interpretation of the comments in
lib/driver/cdtext_private.h:struct CDText_data,
that one group of three 0x8f packs describes the whole set of packs.


> Well. The fact that this standard allows 100 languages does not mean
> CDTEXT supports all of them. The ones from cdtext.h are the only ones
> that are in Sony's CDTEXT example tool.

I came to that list by googling "EBU Tech 32 58" which is mentioned
in struct CDText_data. The document i found promises to quote the
list from that soec.
Since it seems to be a superset of the languages known to the Sony tool,
a reader should probably be aware of the exots.
A problem might be if they depend on an own character set (character code
0xff ?).  Well, i would be helpless already with Kanji or Mandarin. 


> Cuesheets do not support multiple blocks. Cdrdao toc file format does.
> If you do not plan to support that you could just default it to English.
> Most burning tools do that.

Since the number of blocks is limited, i will probably model them
by an array[8] of the upcoming libburn CD-TEXT attributes of burn_session
and burn_track. (Currently its a linked list, but that causes cumbersome
code with searching, inserting and removing of list elements.)

That way it will be open to applications which interpret complex
definition files of CD-TEXT. (I wonder whether i should introduce
cdrskin options to set single CD-TEXT components from the command line.
Even the small cdtext.cdt example would need dozens of arguments to
be defined by the user.)


Have a nice day :)

Thomas