[Top][All Lists]

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

Re: [Libcdio-devel] CD-Text patches

From: Leon Merten Lohse
Subject: Re: [Libcdio-devel] CD-Text patches
Date: Wed, 07 Dec 2011 10:42:29 +0100
User-agent: Roundcube Webmail/0.5.3

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)


reply via email to

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