libcdio-devel
[Top][All Lists]
Advanced

[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: Rocky Bernstein
Subject: Re: [Libcdio-devel] RFC on two CD-TEXT patches by Serge Pouliquen
Date: Fri, 18 May 2018 09:40:21 -0400

Thanks for the information, Thomas. Since you clearly know the most about
this, would you work up revised code.

Add another enumeration with the names you propose is fine.

Many thanks.

On Fri, May 18, 2018 at 8:22 AM, Thomas Schmitt <address@hidden> wrote:

> Hi,
>
> i cannot fully judge the impact of the proposed patch
>   https://savannah.gnu.org/bugs/?53928
> 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:
>   http://tech.ebu.ch/docs/tech/tech3264.pdf
> 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
> code.
>
> But in
>   http://git.savannah.gnu.org/cgit/libcdio.git/tree/lib/driver/cdtext.c
> 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
>   CDTEXT_LANGUAGE_INVALID = 0x100
> 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.
>   CDTEXT_LANGUAGE_BLOCK_UNUSED = 0x101
>
> 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
>   cdtext_is_language()
>   cdtext_lang2str()
> would have to learn to handle the new codes without accessing
> cdtext_language[].
>
> 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 :)
>
> Thomas
>
>
>


reply via email to

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