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
