[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)
Regards
Leon
- Re: [Libcdio-devel] CD-Text patches, Thomas Schmitt, 2011/12/01
- Re: [Libcdio-devel] CD-Text patches, Leon Merten Lohse, 2011/12/01
- Re: [Libcdio-devel] CD-Text patches, Thomas Schmitt, 2011/12/02
- Re: [Libcdio-devel] CD-Text patches, Leon Merten Lohse, 2011/12/02
- Re: [Libcdio-devel] CD-Text patches, Thomas Schmitt, 2011/12/02
- Re: [Libcdio-devel] CD-Text patches, Thomas Schmitt, 2011/12/06
- Re: [Libcdio-devel] CD-Text patches, Leon Merten Lohse, 2011/12/06
- Re: [Libcdio-devel] CD-Text patches, Thomas Schmitt, 2011/12/06
- Re: [Libcdio-devel] CD-Text patches, Leon Merten Lohse, 2011/12/06
- Re: [Libcdio-devel] CD-Text patches, Thomas Schmitt, 2011/12/07
- Re: [Libcdio-devel] CD-Text patches,
Leon Merten Lohse <=
- Re: [Libcdio-devel] CD-Text patches, Thomas Schmitt, 2011/12/07
- Re: [Libcdio-devel] CD-Text patches, Rocky Bernstein, 2011/12/06