[Top][All Lists]

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

Re: [Libcdio-devel] RFC on two CD-TEXT patches by Serge Pouliquen

From: Thomas Schmitt
Subject: Re: [Libcdio-devel] RFC on two CD-TEXT patches by Serge Pouliquen
Date: Fri, 18 May 2018 14:22:37 +0200


i cannot fully judge the impact of the proposed patch
on libcdio.

But as one of those who collected the CD-TEXT knowledge for libcdio and
libburn, i can at least clarify CDTEXT_LANGUAGE_UNKNOWN.

Its definition in include/cdio/cdtext.h is the first of a long list of
language code definitions which we took from European Broadcasting Union
document TECH. 3264-E:
I cannot completely remember why we came to that document but i remember
that we were confident that this is the list of language codes that are
used by CD-TEXT.

So language code CDTEXT_LANGUAGE_UNKNOWN = 0x00 is an official and valid

But in
it seems more to be used as libcdio-internal "Language Invalid" flag.
If so, then i deem this use wrong.
There should be a distinct indication of invalid language in a CD-TEXT
block, if this such an invalid situation can arise at all.

So, to my narrow-scope assessment, the four occurences of
CDTEXT_LANGUAGE_UNKNOWN in lib/driver/cdtext.c should be replaced by
the new member of enum cdtext_lang_t (let's call it
for now).
This new member should also be applied if a read-in language code is
too large in function cdtext_data_init():

        /* set Language */
        if(blocksize.langcode[i_block] <= 0x7f)
          p_cdtext->block[i_block].language_code = blocksize.langcode[i_block];
+       else
+         p_cdtext->block[i_block].language_code = CDTEXT_LANGUAGE_INVALID;


Said this, the consideration of Serge Pouliquen seems still valid, that
the user of libcdio might want to see a block and/or its text bytes although
that block has an invalid language code.

So probably libcdio needs another enum member to distiguish unused
p_cdtext->block[i] from read-in block[i] with invalid language code. E.g.

The block[i] with CDTEXT_LANGUAGE_INVALID would be candidates for being
shown despite their flaw.
The block[i] with CDTEXT_LANGUAGE_BLOCK_UNUSED would never be processed
further than checking their language_code.


About the new enum values 0x100 and 0x101:

These values can surely not be read from the CD, because there the language
codes are single bytes. Insofar they are safe against being confused with
real language codes.

There is an array  cdtext_language[i]  where language codes are used as
index. The new codes would either have to be appended after 128 dummy
language names, or functions
would have to learn to handle the new codes without accessing

Maybe there are other occasions where it is assumed that a language code
is always <= 0x7F. They would need adaption, of course.


Have a nice day :)


reply via email to

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