Re: [Libcdio-devel] Miscellaneous questions, primarily on design

[Samuel May]

On Sun Mar 22, 2020 at 10:16 AM, Leon Merten Lohse wrote:
> On 21.03.20 21:41, Samuel May wrote:
> > Thomas Schmitt wrote:
> >> Indeed ? Does it burn audio CDs ?
> > 
> > I was maybe a bit over-generous in that description -- I mainly 
> > meant that if someone wanted to use libcdio as an over-qualified 
> > CDTEXT binary editor, they for the most part could.  (Though see my 
> > next response to Rocky below.)
> 
> I believe there is a slight misunderstanding here.
> 
> libcdio parses the raw CDTEXT and stores it in an internal data 
> structure. The raw CDTEXT can either be read from an audio CD or from 
> a "raw CDTEXT dump".
> 
> The inverse (packing the internal data structure into raw CDTEXT) is 
> not implemented, as far as I remember. So I would say libcdio is very 
> far from being a CDTEXT binary editor.
> 
> cdio_get_cdtext_raw dumps the raw CDTEXT from the current audio CD and 
> has nothing to do with the CDTEXT parser.

Ah, so that's why it doesn't work with image files, thanks!  I've not 
really gone digging into the internals as much as I maybe should, and 
when I do, it's usually with a goal along the lines of "under what cases 
might this function return NULL/an error?" and I don't necessarily gain 
great understanding of the periphery when doing that.

> cdtext_set is merely the "setter" for the internal data structure and 
> should not be called from outside the library. I believe it is mainly 
> exposed because at some point there was the idea to move the CDTEXT 
> parser into an external library (which was later given up due to 
> mutual dependencies).

Little tidbits of history like that are why I love going trawling 
through list archives.  It's always fascinating to see how software grew 
into what it is now, or at the end of its life for that matter.  Thanks!

> Multi-language support was added at a much later stage so there was 
> not so much freedom in the API, it needed to be backwards compatible, 
> and not so many people were interested in it at the time. (To my 
> knowledge) only very expensive mastering software even supported it 
> then and I could not find any examples in the wild.

Well, even if nobody uses it, I hope to at least provide people with the 
option for their own CD burning.  It might be a dying medium, but it's 
not going quickly!  If nothing else, "be liberal in what you accept, and 
strict in what you produce" seems to be a good model to follow in my own 
work.


> IMHO Thomas' libburnia is a much better option here.

Definitely.  This is all theoretical and based on the same reasoning as 
"well, since I can issue SCSI commands through libcdio, can I misuse it 
to burn things as well?" (i.e. idle curiosity and exploring what 
bounderies give a little).  I'm not actually planning on using libcdio 
for the editing -- or libburnia for that matter; writing my own 
library+frontend in Haskell was what started this whole project.

> (Arguably the API could still have been designed better.)

I think what I'm doing digging into all these edge cases ultimately 
boils down to just that; since I'm reworking the interface into fitting 
a different language, I may as well fix what I can at the same time.

Thanks for putting up with my weird questions in service of that, 
everyone!

Sam