libcdio-devel
[Top][All Lists]
Advanced

[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: Tue, 28 Feb 2012 00:09:39 -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.
>

Ok. Seems reasonable. There will be other great changes in the next release
too.


>
> > 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.


I don't recall it was that hard to do initially and things haven't changed
that much in vlc. Unfortunately I was unable to even start looking at this
today, but I'll try to do so soon.


> Would be nice to actually have a working example of
> multilanguage CD-text.
>
> >
> > Nicolas: your thoughts here with respect to Leon's changes?
>
>


reply via email to

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