[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
- [Libcdio-devel] Miscellaneous questions, primarily on design, Samuel May, 2020/03/20
- Re: [Libcdio-devel] Miscellaneous questions, primarily on design,
Thomas Schmitt <=
- Re: [Libcdio-devel] Miscellaneous questions, primarily on design, Rocky Bernstein, 2020/03/21
- Re: [Libcdio-devel] Miscellaneous questions, primarily on design, Samuel May, 2020/03/21
- Re: [Libcdio-devel] Miscellaneous questions, primarily on design, Thomas Schmitt, 2020/03/22
- Re: [Libcdio-devel] Miscellaneous questions, primarily on design, Leon Merten Lohse, 2020/03/22
- Re: [Libcdio-devel] Miscellaneous questions, primarily on design, Rocky Bernstein, 2020/03/22
- Re: [Libcdio-devel] Miscellaneous questions, primarily on design, Samuel May, 2020/03/25
- Re: [Libcdio-devel] Miscellaneous questions, primarily on design, Thomas Schmitt, 2020/03/25