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

[Thomas Schmitt]

Hi,

i wrote:
> > Indeed ? Does it [libcdio] burn audio CDs ?

Samuel May wrote:
> you did have that successful experimental burn back in 2009,

libburn still can be configured to use libcdio as SCSI transport facility.
But it makes much sense only on operating systems where libcdio has SCSI
passthrough facilities and libburn has no own SCSI transport adapter.


> I'm guessing that cdtext_set(..) is in
> there primarily because it's needed for cdtext_data_init(..),

Yeah. It is strange that cdtext_set() is exposed in
lib/driver/libcdio.la.ver as public call.


> what if someone sets a field on a new track for
> some reason, before iterating:
>   cdtext_set(cdtext, CDTEXT_FIELD_TITLE, "some data", 64, NULL);
>   for (track_t i=cdtext_get_first_track(cdtext);
>        i<cdtext_get_last_track(cdtext); ++i) {

(I think it should be "i<=" rather than "i<".)

Well, if 64 is between first and last track inclusively, the change will
show up in the iteration. But i see no way in the API to store the CD-TEXT
data as file or on CD.


> The "weirdness" was mostly referring to lazy users

libcdio had OS drivers which lazily assumed that the first track on a CD
always bears track number 1. But the CD track number is kindof a data
field of the track, not its index in the CD's Table-Of-Content.

The CD-TEXT track numbers could theoretically be inconsistent with
Table-Of-Content track numbers. So it is better to let the burn program
enforce the same numbering in both.


> "incorrect usage doesn't need to be protected"

If i can catch user mistakes then i do and try to issue a message which
tells what's wrong. But not everything can be foreseen ...


> ... > the physical button on the front of my drive stops
> ... > working until I call cdio_eject_media(..) or *_drive(..) from the
> ... > software side.

> All right, sounds like I might need to go source diving for SCSI
> commands or access modes instead.

As told to Rocky, access modes are not the issue with the eject button.

cdio_eject_media() is about as near as the current high level API brings
you to sending the needed SCSI command.
A new call cdio_unlock_tray() would need implementation in all operating
system drivers. As told, Linux has a ioctl for tray lock control.
With the others one would have to research or - if working - use SCSI
commands.

On the level just above SCSI passthrough and self-composed commands, there
is include/cdio/mmc_ll_cmds.h with mmc_prevent_allow_medium_removal().
(Submit b_persistent and b_prevent as 0 in order to unlock.)

But i am not sure under what circumstances mmc_ll_cmds may be mixed with
higher level calls. And i am not sure whether mmc_ll_cmds work on all
operating systems.


Have a nice day :)

Thomas