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
