[Top][All Lists]

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

Re: [Libcdio-devel] CD-Text API changes

From: Rocky Bernstein
Subject: Re: [Libcdio-devel] CD-Text API changes
Date: Wed, 29 Feb 2012 05:02:07 -0500

On Mon, Feb 27, 2012 at 3:26 PM, Leon Merten Lohse <address@hidden>wrote:

> On Sun, Feb 26, 2012 at 06:23:32PM -0500, Rocky Bernstein wrote:
> > Thank you very much for this write up. I really appreciate it.
> >
> > Some thoughts with regards to the questions I asked and the concerns
> > Nicolas raised. Your current corrected code reads all blocks whereas the
> > old code read only the first block. I imagine there are a number of cases
> > where the first block was good enough (or at least better than nothing).
> So
> I would say in most cases the first block is all there is. But we cannot
> really claim to fully support CD-Text if our implementation is missing
> that feature.
> > here, from a programming standpoint there is no change. And there are
> > features such as multiple language support that the old code just
> couldn't
> > handle. The main place that is incompatibility is in cdtext_get().
> Although
> This is partly correct. One the one hand we have the
> libcdio_get_cdtext() method that reads the text from the disc and
> returns a cdtext_t struct. The point is this struct is completely
> different from the old one. On the other hand there are the cdtext_*
> functions,
> cdtext_get[_const] expect the track parameter now. Essentially this
> parameter moved
> from cdio_get_cdtext to cdtext_*, allowing cdtext_t to store the data of
> all tracks.
> > I totally understand the reason for this change, if another name were
> used,
> > that might reduce incompatibility and confusion. Right? And the old
> > (incomplete) function could be simulated by the new one by supplying a
> > track parameter. Correct?
> It is not that simple. We also would have to give cdtext_t a new name
> and the cdtext_* functions, too.
> If this was a widely used feature, I would totally agree and note them
> as deprecated with the option to remove them in later releases but in
> this case I would like to avoid it.
> > As far as places where the that used the old libcdio cdtext code is used
> > (outside of libcdio such as cd-info), I wrote some plugins for xine, and
> > vlc. The xine plugin I don't think was ever mainstream. Googling around
> for
> > CD-Text on vlc seems to show this was broken, so perhaps I will
> investigate
> > and update the code. There is also a libcdio-based plugin for gstreamer.
> > These are largely the uses I know of. If there are others, of course I'd
> > like to know about.
> If one of them is still in use, I offer to adapt it. Most of it is
> search & replace. How broken is the VLC one? Can it be fixed in
> reasonable time. Would be nice to actually have a working example of
> multilanguage CD-text.

The simplest media player with libcdio-enabled CD-Text is the gtstreamer
cdio plugin in the gstreamer-ugly. Do a
     git clone git://

And look in directory ext/cdio.

To build I downloaded the 0.10.36 source tarballs for gst-plugins-base and
gstreamer, built and installed them. I was able to build the gstreamer cdio
plugin both on libcdio version 0.83 from source and 0.81 from Nicolas
Boullis' Debian package.

In order to test I used the CD-Text CD image in libcdio's
test/data/cdtext.{cue,bin,cdt} which I burned to a real CD and used the
rhythmbox front-end to gstreamer.

So it'd be great if you could modify that to handle the new CD-Text API
and let the author Tim-Philipp Müller know. Probably there'd be code like

 /* old code */
 /* new code */

If you want to still persue the vlc plugin, I can dust that off my old vlc
plugin and try it. Personally though suggest this after trying gstreamer.

> >
> > Nicolas: your thoughts here with respect to Leon's changes?

reply via email to

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