libcdio-devel
[Top][All Lists]
Advanced

[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: Tue, 6 Dec 2011 21:49:33 +0100
User-agent: Mutt/1.5.21 (2010-09-15)

Hi Thomas,
On Tue, Dec 06, 2011 at 01:47:34PM +0100, Thomas Schmitt wrote:
> Hi,
> 
> i am pleased to report a first success of libburn with writing of CD-TEXT:
> 
>   cdrskin dev=/dev/sr3 -v -sao textfile=cdtext.dat \
>           -audio cdtext.bin cdtext.bin cdtext.bin

That's great. Congratulations!

> The documentation still lacks of explanations for the payload format
> of the pack types which are mentioned in MMC-3 appendix J by
>  "Packs with ID1=86h, 87h, 88h, 89h and 8Fh contains binary information
>   in the Text Data Field."
> 
> Is there anything known about them ?

There is. I know nothing about toc and toc2 though.
I work on a documentation about CDTEXT for libcdio. It will include the
use of those fields and some more stuff I learned.

> 
> Totally obscure:
>   0x86 = Disc Identification
>   0x88 = Table of Content information
>   0x89 = Second Table of Content information
> 
> I found some info in libcdio, but am still puzzled:
>   0x87 = Genre Identification
> 
> This seems to be quite well explored in libcdio:
>   0x8f = Size Information of the Block
> 
> How mandatory are they at all ?

Size Information is _NOT_ mandatory, as far as I know.
Disc ID is not really interesting for the end user but should be
implemented. Give me a week to finish the doc. I try to include
everything from MMC3 and the Sony docs. Or just ask me something
specific in the meanwhile.

> I will next strive for creating a complete set of text packs from
> user cleartext input.
> Are there proposals for tests which i should do with the result ?

Download Golden Hawk's CDRWIN. It has a CDTEXT creator that generates
binary .cdts. Alternatively setup a Windows 95 machine and use Sony's
example program. It is the #1 reference. Try different values for the
fields. Then use your tool with the same values and compare the
binaries.
CDTEXT expects ISO 8859-1 encoding and/or ASCII. Some fields require ISO
8859-1 some require ASCII... 

> 
> Currently i am digging in libcdio sources for information about CD-TEXT
> entrails.
> 
> Some questions and remarks:
> ------------------------------------------------------------------------
> In lib/driver/cdtext.c i see
>   static const char cdtext_genre[][30] =
> which is used in function
>   cdtext_genre2str
> 
> But i cannot spot any usage of this function.
> Is the index number in cdtext_genre[] related to the binary data in
> text pack type 0x87 ?
>   34 : 87 00 22 00 00 1b  A  n  i  m  a  l     S  o  u ed 40
>   35 : 87 00 23 0a 00 1b  n  d  z 00 00 00 00 00 00 00 b6 f1
> would be index 27 "Spoken Word".

Exactly. 
See include/cdio/cdtext.h
Those are values from cdrecord and match the ones from Sony example program.

> 
> ------------------------------------------------------------------------
> lib/driver/cdtext_private.h has this very promising info about type 0x8f.
> 
>   extern const enum cdtext_charcode_enum_s
> 
>   extern const enum cdtext_lang_enum_s
> 
>   struct CDText_blocksize
>   {
>     uint8_t charcode;     /* character code */
>     uint8_t i_first_track; /* first track number */
>     uint8_t i_last_track;  /* last track number */
>     uint8_t copyright;    /* cd-text information copyright byte */
>     uint8_t i_packs[16];/* number of packs of each type 
>                            * 0 TITLE; 1 PERFORMER; 2 SONGWRITER; 3 COMPOSER;
>                            * 4 ARRANGER; 5 MESSAGE; 6 DISCID; 7 GENRE; 
>                            * 8 TOC; 9 TOC2; 10-12 RESERVED; 13 CLOSED;
>                            * 14 UPC_ISRC; 15 BLOCKSIZE */
>     uint8_t lastseq[8];   /* last sequence for block 0..7 */
>     uint8_t langcode[8];  /* language code for block 0..7 */
>   } GNUC_PACKED;
> 
> But i still riddle over the copyright byte.
> In cdtext.cdt it is 0.

I am not exactly sure about the copyright byte. cdrecord might know
more. Will do some more research.
Also the lastseq and langcode seem to be redundant since they are
present in every block but also contain information about the other
blocks.
i_packs also just counts the packs of the block, the blocksize pack is
from.

> 
> ------------------------------------------------------------------------
> 
> Can it be that this comment is wrong ?
> lib/driver/cdtext.c:cdtext_data_init() has:
> 
>   if (p_blocksize.i_packs[15] >= 3) {
>     /* if there were more than 3 BLOCKSIZE packs */
> 
> But actually the C code tests for at least 3 packs, not for more than 3.
> Further i cannot see any handling of packs after the third one.

Yes you are right. I just did not want the parser to fail if there are
more than the 3 required packs... probably useless. == 3 is better.
> 
> ------------------------------------------------------------------------
> 
> lib/driver/cdtext_private.h has:
> 
>   /*!
>    * The language code is encoded as specified in ANNEX 1 to part 5 of EBU
>    * Tech 32 58 -E (1991).
>    */
> 
> I failed to find a free copy of EBU Tech 3258.
> But i found the language codes in http://tech.ebu.ch/docs/tech/tech3264.pdf
> Appendix 3.
> It states:
>   "The codes are identical to those used in the systems of the MAC/packet
>    family, and are reproduced from the EBU specification for these systems
>   [3].
>   [...]
>   [3] Specification of the systems of the MAC/packet family
>       EBU document Tech. 3258, 1986.
>   "
Sorry, those codes don't have anything to do with the way CDTEXT expects
the language. I just chose two-character codes to convert the integer
values to. Do you know a better way? 
See cdtext_private.h . Those are the values you are looking for. Again
they come from cdrecord and match the ones from the sony example
program.

Regards
Leon



reply via email to

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