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:
http://lists.gnu.org/archive/html/libcdio-devel/2016-05/msg00016.html
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
Leon
