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
