Hi, > Frank: I hope we haven't lost you here. I think we still are interested in > the feature you suggest.
Didn't you announce that you accepted mmc_get_disc_erasable() already ? Did i miss a new proposal of Frank ? > > is there > > really no profile retriever function yet ? > No there isn't one. In libcdio's src/util.c you'll see for example a MMC > call to GET CONFIGURATION. > I am undecided on whether to add one. Profile is the most general first hint about what media you have and what you might expect from it. In my eyes it is very important. After all we have a list of profiles in the libcdio glossary now. This wakes wishes. :)) > Consider this code from libburn's mmc.c > if (d->current_profile == 0x1a || d->current_profile == 0x13 || > d->current_profile == 0x12 || d->current_profile == 0x43) > d->status = BURN_DISC_BLANK; This forces the overwriteable media into the CD inspired model of Blank, Appendable, Closed. "Blank" means writeable from scratch. "Appendable" means writeable from a non-zero address, which one has to inquire from drive. "Closed" means not writeable. The test looks for DVD+RW, formatted DVD-R, DVD-RAM or BD-RE. libburn sees them as always blank. Quite an internal gesture, indeed. It does not use the API but digs in burn_drive entrails. Nevertheless, the application may inquire the profile in order to decide what to do next. Those media may well contain readiable data although in the coarse write-oriented classification they are regarded as blank. There is one more candidate 0x42 "BD-R random recording" but that is not supported by libburn (neither by my BD burner). At least one can tell the user what it is and why it is not supported. (It would be an overwriteable media that shrinks with every block you overwrite. Weird.) > This is exactly the knowledge I think would be helpful to have encapsulated > in a library. That is, in order to determine if a disc is blank: MMC is a multidimensional potato (more nicely called a manifold). There are so many partial views and classification scales. There are other dimensions like whether a media allows to burn a track without knowing its size in adavance (TAO-like versus SAO-like). Or random-access read-write, or formattability, or blankability. These classifications do help with handling media, but they also obscure the actual info about the currently loaded media. > That said, I think it useful to make it easy to issue some of the > lower-level or more MMC-specific commands that often have to be run in order > to answer the higher-level questions. The interface will be a demanding task. How much detail shall be exposed to the caller ? The architecture of libburn cannot be a good example as it heavily copies MMC info into its burn_drive object for later inquiry by the API calls. My team mate Mario Danic told me that he is working on a MMC library. We sketched roughly that it could replace one half of our current MMC/SPC/SBC code and would swallow our system adapters. The other half of the current MMC code would become part of the burn_drive methods. Maybe you can share thoughts with him about the protoypes of a comprehensive MMC interface. It should be more convenient than raw mmc_run_cmd() and keep the caller from doing obviously inappropriate things. On the other hand its doings should still be recognizable in MMC specs. No abstractions. If you start a common effort then i would be your first user. :)) Have a nice day :) Thomas
