Hi, > SRM+POW recordings are *not*. SRM+POW recordings are > multi-track, but not multi-session. Meaning that even multi-session aware OS > will look for volume descriptor at LBA#16 for SRM+POW recording. > [...] > I leave session open in SRM+POW > [...] > appropriate to refer to recording as "increment", not "session", in SRM+POW
So it is very similar to our layouts on overwriteable media. Except that the NWA is prescribed by the new track and not at the discretion of the burn program. (MMC advises to use the track provided NWA in 4.5.3.6.9 "The Expanding Orphanage".) I have to split the meaning of "Session" for clarity. There are no MMC-sessions on overwriteables and on BD-R+POW (as written by growisofs). But there are ISO-sessions or Volumes which get generated as if they were to be appended to MMC-multi-session media. (This stems from ISO 9660 on CD-R, after all.) > We simply seem to assign different meanings to "mountable" in the context. > To me mountable is mere validity/sanity of volume descriptor and to you is > access to first recording. Let's call it "muted" instead, in which case > answer is "yes, 1st recording will become muted." Sanity is restored. I would rather say "beheaded" than "muted". :) "Pity is treason", Robespierre. I plead for keeping the ISO-sessions distinguishable in order to allow to mount the older states of the (pseudo-)multi-session media. There is only one thing missing in the current doings of growisofs: the persistent copy of the Volume Descriptors of the initial ISO-session. All other ISO-sessions stay reachable because their descriptors do not get overwritten later. One only has to find them. This allows to present the user with a uniform view on multi-session ISO burning quite regardless of the media type. growisofs already provides much of that uniformity. But with session history the media classes differ visibly and sometimes painfully. (Imagine you know there is the old unspoiled file content on media but you cannot access it because a new ISO-session was added and overwrote it by the spoiled content.) So on BD-R +POW and the first session i would propose to write 32 dummy sectors, then the ISO image which was prepared by -C 0,32, and then to overwrite the dummies by a patch copy from LBA 32++. (Or write the patched 32 sectors already before the image gets written. You'd spare one cluster of orphans that way. The dummy method should be more like the current procedure, though.) --------------------------------------------------- > For reference, according to READ TRACK INFORMATION > end of any given track coincides with start of next > one. Now this is a riddle. From where did POW take the clusters which replaced the old LBA 0 clusters ? The specs say "the Logical Overwrite of a Cluster is redirected to the NWA of some open Logical Track." "A SRM disc with POW shall be initialized by the formatting process as a single session disc with a single Logical Track." The latter statement seems to forbid your track structure. Duh ? Anyway. If there is only one open track then the cluster had to be taken from its NWA. If you start the next track and inquire its NWA then i'd expect it skips the orphaned cluster address. If it would use the orphan LBA for the start of a sequential write, then an avalanche of orphans would hit the Defect List. Maybe the firmware programmers have decided to forget about the MMC prescription and to feed POW by spares and not by orphans ?i It seem so much more natural. Just not as usable for bulk overwrites. --------------------------------------------------- > > export MKISOFS="xorrisofs" > > to lift the ban on options like "-outdev", > Cool. I have to consider it... Another help for xorriso would be if you added option -o "-" to the mkisofs run. Other than mkisofs there are legal states without output drive in xorriso. So whenever the user escapes the mkisofs emulation in a growisofs run, the first duty is to set -outdev "-". If you gave -o "-" in the mkisofs part then this would not be needed. The possibility to leave the mkisofs emulation depends on growisofs current habit to write its own mkisofs options only at the start of the argument list. If you ever change this, then this trick will fail. I would have to ask you for a xorriso mode in growisofs then: mkisofs -M $indev -C $msc1,$msc2 -o $outdev is equivalent to xorriso -indev "stdio:$indev" \ -load sbsector $msc1 -grow_blindly $msc2 \ -outdev "stdio:$outdev" Currently your use of the mkisofs CLI seems to be suitable enough. As always: Thanks for your guidance ! Have a nice day :) Thomas -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]