libcdio-devel
[Top][All Lists]
Advanced

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

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


From: Thomas Schmitt
Subject: Re: [Libcdio-devel] Miscellaneous questions, primarily on design
Date: Sat, 21 Mar 2020 10:21:05 +0100

Hi,

Samuel May wrote:
> * Is there any deliberate reasoning behind 2.1.0 not adding a
>  cdtext_get_language_index(..) with cdtext_select_language_index(..)?

Do you mean cdtext_set_language_index() rather than
cdtext_select_language_index() ?

I guess it is expected that you list languages by cdtext_list_languages_v2(),
pick one by cdtext_set_language_index() and an index which you know,
and, if needed, memorize the index for later use.


> * What about changing the language of a block?  I know libcdio
>  isn't primarily a disc-authoring library, though with cdtext_set(..)
>  and cdio_get_cdtext_raw(..) it can definitely be used constructively

Indeed ? Does it burn audio CDs ?

Changing the language would normally imply the need for translating the
texts to that new language.
If this translation and burning a new CD is the goal, then i propose to
use libburn and maybe its CLI frontend cdrskin. Option cdtext_to_v07t=...
dumps the CD-TEXT packs in human editable form. input_sheet_v07t=... may
then be used to submit the changed CD-TEXT to a CD burn run.
If you are interested in the API, see
  https://dev.lovelyhq.com/libburnia/libburn/raw/master/libburn/libburn.h
and search for "CD-TEXT".


> * Likewise should cdtext_set(..) really leave cdtext_get_first_track(..)
>  and cdtext_get_last_track(..) with the original bounds?   I'm sure some
>  weirdness might crop up if those don't match with the start/end tracks
>  from the disc as a whole, but on the other hand I didn't expect the
>  current behaviour and I'm sure I'm not the only one -- at the very
>  least, it should be documented.

I would expect that the track numbers from cdtext_get_*_track() are
to be used with cdtext_get().
Am i wrong ?


> * More troublingly, has anyone ever run into issues with CdIo_t sessions
>  locking up your drives?  If I call some functions (I don't /think/ it
>  happens across the board, but I haven't gone looking for a pattern
>  yet) the physical button on the front of my drive stops working until
>  I call cdio_eject_media(..) or *_drive(..) from the software side.

In the end it is SCSI command START/STOP UNIT which locks the tray and
releases it. It might depend on driver and/or operating system whether
and at what occasion the lock command is sent to the drive.


Have a nice day :)

Thomas




reply via email to

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