[Top][All Lists]

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

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

From: Leon Merten Lohse
Subject: Re: [Libcdio-devel] [RFC] Fixing code flaws around CD-TEXT
Date: Mon, 25 Jun 2018 23:53:52 +0200
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.8.0

On 25.06.2018 22:53, Thomas Schmitt wrote:

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:

It is very reassuring that I had already forgotten where I found that limit two years ago. There is a good chance I copied it from some older implementation. In any case: Choosing the higher number here is not wrong even if the spec, for some unknown reason, would allow only 9216.

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.

Certainly. This is the place you would normally encounter raw CD-TEXT files if you are not using the binary API. (Not that I think anybody ever implemented CD-TEXT ripping into a separate file although it is part of the standard.) The binary API was exposed mainly for unit tests (and in case anybody would be interested in playing around with raw CD-TEXT files).

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.

Yeah, "<" or "!" makes much more sense. I might have had it in an earlier version and cherry-picked the wrong change or never actually tested this part. ">" is indeed very unlikely to ever be triggered on its own. That is probably why I never noticed the missing "+ 4" in that branch.
Best regards

reply via email to

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