On Mon, Mar 28, 2011 at 12:47 AM, Leon Merten Lohse <[email protected]>wrote:
> 3rd attempt > Thanks for your persistence. It does pay off. By the way, after reading over the email, I realize that this really should be going to the libcdio-devel mailing list which I've cc'd that on the reply. > > Hello hello, > > working on my current project, an audio cd analyzer, I noticed, that > libcdio's cd-text extraction does not give me the expected results. > After reading through the source code an the equivalent part in cdda2wav, > I wrote a small patch for libcdio's cdtext.c: > http://nopaste.yamagi.org/?509 > > adding isrc and mcn extraction from cd-text. > should also work more reliable now, when binary fields are present. > work on double-byte characters. > Thanks, this has been applied. But before we release it would be really good to be able to test this code. Could you create a small CD image with multi-byte CD-TEXT that we can use in testing? > > Currently only block 0 out of 0-7 is read. Is that intended? Are there any > audio CDs using more than block 0? If so, we should add a way to read > them. > It's been hard to find CD's with *any* CD-TEXT on it let along things text in things other than track 0. > > I could not find any information on the data format for binary cd-text > fields. Does anybody know more? Would be neat to also extract those > information. > > Concerning double-byte characters: Should we leave it to the user to work > with that or should the library convert it to a standard like encoding > utf8? Either way, it lacks a field in cdtext_t indicating double-byte > characters or the encoding. > > I was also wondering why the cdtext functions do not have a cdio_ prefix. > Just a mistake. I'll correct that later. > > Oh. And I found a little bug in the cdtext example code in the line: > const cdtext_t *cdtext = cdio_get_cdtext(p_cdio, 0); > I think the 0 should be substituted with i_track. > Yes, I think you are correct. I've chthat too. > > Regards > Leon Lohse > > 03-27-2011: > I just found some other issues. > cdio_get_cdtext even returns a cdtext_t object, if there is no cdtext > information available. The documentation says, it would return NULL in > that case. Would be kind of nice to get that fixed. > The code appears to be (for GNU/Linux) in lib/driver/_cdio_generic.c funciton get_cdtext_generic(). The intent was that we couldn't find cd-text information whereas I think you want a test that all fields are the empty string. Right? If so, the code could be changed. But this is slightly different. > I started to work on proper GENRE and DISC_ID field extraction today. > Might take a while though, because the documentation on the internet is > very thin and even inconsistent in the case if DISC_ID is binary or char. > I am also not at home right now, so I do not have access to very many test > CDs. > > I also intend to implement extraction of the other 7 blocks and relate > them to their languages. Dunno how to do that, without breaking the API at > this point. Have to think about it a little more. > It looks like the next release may have to break the API for some changes to allow writing. > > If anybody has information about CD-Text specifications and use other from > MMC3 draft, I would really appreciate to see them. > > Thanks! > Leon > > > _______________________________________________ > Libcdio-help mailing list > [email protected] > http://lists.gnu.org/mailman/listinfo/libcdio-help >
