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

[Thomas Schmitt]

Hi,

first lapse in my changeset:

I forgot to set the .language_code of a block to CDTEXT_LANGUAGE_INVALID
in the else-case of
  if(blocksize.langcode[i_block] <= 0x7f)

But meanwhile i doubt the wisdom of not registering language codes > 0x7f
at read time.
Is there somebody who defends above "<= 0x7f" as neccessary ?

-------------------------------------------------------------------------
Reasoning:

The gesture shown in src/cd-info.c and in the examples clearly assumes
that language codes occur only once per CD:

  languages = cdtext_list_languages(p_cdtext);
  for(i=0; i<8; i++)
    if ( CDTEXT_LANGUAGE_UNKNOWN != languages[i]
         && cdtext_select_language(p_cdtext, languages[i]))

The call cdtext_select_language() uses languages[i] as search key for
finding the matching block index. cdtext_list_languages() does not
necessarily return the code array with an 1:1 relation to blocks.
So this search is necessary.

But if a CD has more than unspecified language code, then mapping them
all to CDTEXT_LANGUAGE_INVALID the search would yield only the first
of the affected block indice. So this would make the situation worse
rather than better.

If libcdio would register unspecified language codes as they are, then
cdtext_field2str() would translate them to "INVALID", which is what it
would also do with the new CDTEXT_LANGUAGE_INVALID.

CDTEXT_LANGUAGE_INVALID would become obsolete.
But to be neat, we would need to define enum cdtext_lang_t members
  CDTEXT_LANGUAGE_80  to  CDTEXT_LANGUAGE_FF
so that the values can be stored.

The internet has the rumor that all values from 0 to the bitwise or-result
of all enum members can be stored. But that's not really compliant with
the concept of an enumeration.

(I don't like C enum. It's just an intentionally crippled integer. Bleh.)

-------------------------------------------------------------------------


Have a nice day :)

Thomas