Re: [Libcdio-devel] [RFC] Fixing code flaws around CD-TEXT

[Thomas Schmitt]

Hi,

Leon Merten Lohse wrote:
> I would first like to apologize for the amount of bugs.

The code has not been challenged enough. A few encounters with real
use cases would give it more stability.


> 1) I do not remember where I got that maximum size from but I did not make
> it up. [...]
> Are you certain that there is no upper limit on the payload size imposed by
> some other restriction than the 8 text blocks with a maximum number of 256
> bytes?

My version of our description has:

  The limitation of block number and sequence numbers imply that there are at
  most 2048 text packs possible. (READ TOC/PMA/ATIP could retrieve 3640 packs,
  as it is limited to 64 kB - 2.)

My mailbox says that we discussed CDTEXT_LEN_BINARY_MAX on may 31 2016:
  http://lists.gnu.org/archive/html/libcdio-devel/2016-05/msg00016.html



> 3) This is indeed a quick and dirty heuristic to detect MMC headers.

So the occurence in lib/driver/image/bincue.c should be changed too,
i guess.


> Some
> other implementation (it might have even been the "official" Win95 CD-TEXT
> generator from Sony?? which I used as reference) produced CD-TEXT blobs that
> included the header so the check is required for compatibility.  It assumes
> that the first block is of type 0x80 which was the case for all examples I
> had.

But why "> 0x80" and not "!= 0x80" ?

And did it work at all ? As stated in my previous mail, "> 0x80" implies
a size of 0x8000 + 2 or more.


> Your test is of course much more elegant since it does not depend on
> assumptions that are not guaranteed to be met.

A test "< 0x80" would probably have been convincing enough.
(But there still remains the flaw of not submitting "cdt_data + 4" to
 cdtext_data_init().)


> The biggest problem has been that I did not encounter a single CDDA in the
> wild that had more than one language block to do proper testing with

Yeah. Examples are in short supply.


Have a nice day :)

Thomas