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
