Re: [Libcdio-devel] CD-Text patches

[Leon Merten Lohse]

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

Yes. 8 Blocks is max. Definitely. Although most implementations support 
only one.

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

I wrote those comments ;-). First I thought so, too but I am not sure 
anymore after I
read Sonys documentation.

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

As I said. Those two-character language codes have nothing to do with 
the CDTEXT spec.
Should be enough, if a writer supports the ones from the Sony example. 
A conversion
from two-character codes or the whole name to the integer code would be 
great.
As of character sets. Mandarin was never implemented. I just took all 
the fields from cdrecord.
Although Kanjin(MS-JIS/ Shift-JIS) was implemented, I gave up on
implementing it. MS-JIS is a Microsoft character set, by the way. I 
highly doubt there are
any readers that support it. I have not found a free burning tool that 
supports it, either. If you
happen to find a disc with Kanji CD-TEXT, please let me know.
This only leaves ASCII and ISO 8859-1 (ASCII plus some umlauts).
The spec is pretty specific about that. Some fields (DISC ID) only 
accept plain ASCII, some
(ISRC, GENRE INFORMATION) must accept ISO 8859-1. The most important 
ones can hold either one
but only one at the same time in one block (or disc, depending on if 
there are multiple BLOCKSIZE
Packs per disc). I will cover that in my doc.

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

Sounds like a good idea!

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

I tried to use every available field in that example so it is not 
actually that small ;-)
Be aware that the spec requires you to set a field for every track, if 
you specify it for one.
(except genre and discid of course)

Regards
Leon