libcdio-devel
[Top][All Lists]
Advanced

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

[Libcdio-devel] Re: [Libcdio-help] CD-Text handling


From: Rocky Bernstein
Subject: [Libcdio-devel] Re: [Libcdio-help] CD-Text handling
Date: Mon, 28 Mar 2011 13:03:29 -0400

On Mon, Mar 28, 2011 at 12:47 AM, Leon Merten Lohse <address@hidden>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
> address@hidden
> http://lists.gnu.org/mailman/listinfo/libcdio-help
>


reply via email to

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