Re: BD-R formatting help

["Thomas Schmitt" <scdbackup@gmx.net>]

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