Burning dual layer Bluray discs

[Richard Shaw]

Well I just received the new LG burner because my ASUS was acting up (not
ejecting properly and other issues).

Also, I was NEVER able to burn dual layer Bluray discs with the ASUS even
though it was supposed to. I tried everything, including REAL cdrecord
(compiled myself), but the burn would always fail when switching layers.

Since the drive had an issue and I had to spend some $$$, it was time to
try again with the new LG WH14NS40.

I first tried backing up my pictures (~40GB), with xfburn because I wanted
to use libburn as the fork of the cdrecord apps are known to have issues.
Not sure what the problem was but after spinning up a bunch of times it
just crapped out with an unhelpful error.

Next I tried Brasero, which also failed miserably.

Finally I tried k3b which used mkisofs and it actually worked! Switched
layers fine, finished, and verified. For posterity I specified a UDF based
filesystem.

Googling I see so little useful information about burning dual layer Bluray
discs on Linux I figured I'd mention it here for anyone else interested.

Thanks,
Richard

[Thomas Schmitt]

Hi,

Richard Shaw wrote:
> I wanted to use libburn as the fork of the cdrecord apps are known toi
> have issues. Not sure what the problem was but after spinning up a bunch
> of times it just crapped out with an unhelpful error.

I'm the developer of libburn, which works underneath Xfburn, cdrskin,
and xorriso.
I know from xorriso users that they burnt multi-layer BD-R successfully.

But reports are sparse and the price for multi-layer BDs is still too
high in comparison to single-layer. So i don't have any.
(I am using single-layer BD-RE with my old application scdbackup, which
 writes large directory trees to multiple media.)

In general, multi-layer BD media offer few opportunities for doing it wrong
while doing it right with single-layer. Other than with DVD+/-R DL,
SCSI/MMC offers no special layer-jump modes and no command to set an
address for the layer jump to happen.
In principle multi-layer BD appears to the burn software like large
single-layer BD.

If you want to give libburn another try with hopefully more informative
messages, you could run xorriso.
For example put two directory trees into the resulting ISO 9660
filesystem and burn it to the blank medium in /dev/sr0

dir_with_pics1=...path...
  dir_with_pics2=...other.path...
  xorriso -outdev /dev/sr0 \
          -for_backup \
          -map "$dir_with_pics1" /pics1 \
          -map "$dir_with_pics2" /pics2
> Finally I tried k3b which used mkisofs and it actually worked!

Afaik, K3B uses growisofs as burn backend. It formats BD-R media by default,
which cdrecord and libburn do not.

growisofs surely has no knowledge about multi-layer BDs. Its development
ended shortly after single-layer BD became widely available. I studied its
source code when i prepared libburn for BD.
So if it does something different than the others, then i bet on the
formatting.

To let xorriso format the BD-R, insert command -format with mode "as_needed"
after -outdev :

xorriso -outdev /dev/sr0 \
          -format as_needed \
          -for_backup \
          -map "$dir_with_pics1" /pics1 \
          -map "$dir_with_pics2" /pics2

Formatted BD media show low write speed due to frequent checkreading after
write. This checkreading can be suppressed by libburn.
For full speed with formatted BD, insert command -stream_recording with
parameter "full":

xorriso -outdev /dev/sr0 \
          -format as_needed \
          -stream_recording full \
          -for_backup \
          -map "$dir_with_pics1" /pics1 \
          -map "$dir_with_pics2" /pics2

Normally one would not format a BD-R and then disable checkreading.
But just in case that the drive only can write to formatted ones, this
combination could make sense.

If formatting turns out to be the decisive trick, you may format the
BD-R in a xorriso run and then use it with a GUI program that offers
no option formatting. Like:

xorriso -outdev /dev/sr0 -format as_needed
> For posterity I specified a UDF based filesystem.

The filesystem should have no influence on burn success.

As long it is for mounting on Linux or MS-Windows, ISO 9660 is ok even
for large files. The BSDs and Solaris have problems with data files
larger than 4 GiB - 1. (Whether their UDF drivers are any better, i can't
tell.)
The overall size of a 100 GB filesystem should be no problem to any
operating system's ISO 9660 driver.

Have a nice day :)

Thomas

[Richard Shaw]

On Fri, Apr 3, 2020 at 2:44 AM Thomas Schmitt  wrote:
> Hi,
>
> Richard Shaw wrote:
> > I wanted to use libburn as the fork of the cdrecord apps are known toi
> > have issues. Not sure what the problem was but after spinning up a bunch
> > of times it just crapped out with an unhelpful error.
>
> I'm the developer of libburn, which works underneath Xfburn, cdrskin,
> and xorriso.
> I know from xorriso users that they burnt multi-layer BD-R successfully.

Hey Thomas, yeah been a while, we worked on getting the libburnia suite of
stuff up to date in Fedora a few years ago.

But reports are sparse and the price for multi-layer BDs is still too
> high in comparison to single-layer. So i don't have any.
> (I am using single-layer BD-RE with my old application scdbackup, which
>  writes large directory trees to multiple media.)

Yeah, I mostly wanted it so I can backup with having to have "Disc 1 of X"
type backups or create spanning images where I have to read all the disks
to find one file.
> If you want to give libburn another try with hopefully more informative
> messages, you could run xorriso.

I'm willing to try but that was my last disc from the first spindle I
ordered. Have to wait for payday to buy another (which is sad).
> For example put two directory trees into the resulting ISO 9660
> filesystem and burn it to the blank medium in /dev/sr0
>
> dir_with_pics1=...path...
>   dir_with_pics2=...other.path...
>   xorriso -outdev /dev/sr0 \
>           -for_backup \
>           -map "$dir_with_pics1" /pics1 \
>           -map "$dir_with_pics2" /pics2
> Afaik, K3B uses growisofs as burn backend. It formats BD-R media by
> default,
> which cdrecord and libburn do not.

Ok, yeah I saw both mkisofs and growisofs in the log window.
> growisofs surely has no knowledge about multi-layer BDs. Its development
> ended shortly after single-layer BD became widely available. I studied its
> source code when i prepared libburn for BD.
> So if it does something different than the others, then i bet on the
> formatting.

I'm assuming it can format on the fly? There was no "formatting" stage.

Thanks,
Richard

[Thomas Schmitt]

Hi,

i wrote:
> > Afaik, K3B uses growisofs as burn backend. It formats BD-R media
> > by default,

Richard Shaw wrote:
> I'm assuming it can format on the fly? There was no "formatting" stage.

It does this automatically before writing begins. BD-R formatting does
not last long. Other than with BD-RE the drive cannot write and checkread
all blocks just for a test.

growisofs_mmc.cpp emits a message in function bd_r_format()
    fprintf (stderr,"%s: pre-formatting blank BD-R for %.1fGB...\n",
                    ioctl_device,(f[0]<<24|f[1]<<16|f[2]<<8|f[3])*2048.0/1e9);

This undocumented growisofs option can suppress BD-R formatting:
  -use-the-force-luke=spare=none
> Have to wait for payday to buy another (which is sad).

And i am too thrifty. Shame on me. My only excuse is the usual reason
that i am an unpaid volunteer. (This saves me from implementing UDF, too.)

I just had a look at the market in germany:
My usual hardware provider wants 37.85 EUR for 5 pieces Verbatim 100 GB,
or 25.63 EUR for 5 x 50 GB. But there is some hope: 25 x 50 GB no-name
for 44.80. 50 x 25 GB single-layer Verbatim are at sale for 26.94.
So double-layer is now just twice as expensive per GB.

Ridiculous: 5 x 100 GB Verbatim M-Disc for 71.70.

Have a nice day :)

Thomas

[Richard Shaw]

On Fri, Apr 3, 2020 at 2:52 PM Thomas Schmitt  wrote:
> Hi,
> > Have to wait for payday to buy another (which is sad).
>
> And i am too thrifty. Shame on me. My only excuse is the usual reason
> that i am an unpaid volunteer. (This saves me from implementing UDF, too.)
>
> I just had a look at the market in germany:
> My usual hardware provider wants 37.85 EUR for 5 pieces Verbatim 100 GB,
> or 25.63 EUR for 5 x 50 GB. But there is some hope: 25 x 50 GB no-name
> for 44.80. 50 x 25 GB single-layer Verbatim are at sale for 26.94.
> So double-layer is now just twice as expensive per GB.
>
> Ridiculous: 5 x 100 GB Verbatim M-Disc for 71.70.

I was initially avoiding no-name discs but found some RiData discs with
good ratings for $44USD for 25 50GB discs.

EUR and USD are pretty close right now so looks like about the same price.

Thanks,
Richard

[Richard Shaw]

Thomas,

Since I have your attention... I'm having trouble finding a good HOWTO for
xorriso. Most of the examples use the "-as-cdrecord" option. Is that
necessary to burn an ISO?

Thanks,
Richard
>

[Thomas Schmitt]

Hi,
> I'm having trouble finding a good HOWTO for xorriso.

There are examples at the end of the man pages. Online:

https://www.gnu.org/software/xorriso/man_1_xorriso.html#EXAMPLES
  https://www.gnu.org/software/xorriso/man_1_xorrisofs.html#EXAMPLES
  https://www.gnu.org/software/xorriso/man_1_xorrecord.html#EXAMPLES
> Most of the examples use the "-as-cdrecord" option.
> Is that necessary to burn an ISO?

The second and third link above describe the emulation modes which are
intended for existing scripts which use the older programs mkisofs and
cdrecord.

xorriso -as cdrecord is not only for legacy scripts but also covers the
use case of burning a readily prepared ISO 9660 image onto optical media.

Your goal of archiving / backing up a collection of data files from your
hard disk can be achieved by a pipe made of xorriso -as mkisofs and
xorriso -as cdrecord. But xorriso's native command set serves the same
purpose by a single program run.

My proposed example runs for multi-layer BD-R will create an ISO 9660
filesystem directly on the -outdev drive.

The BD-R medium will stay appendable. Further write runs to the same
medium will have to use -dev instead of -outdev, so that the existing ISO
directory tree gets loaded as base for the new session.
(You need to take care that -for_backup comes before -dev, so that the MD5s
 of the existing data files get loaded. It was didactically suboptimal
 to show it in my proposals after -outdev.)

If you want to close the medium to prevent further writing, add command
-close "on" to the xorriso run:

xorriso -for_backup \
          -outdev /dev/sr0 \
          -close on \
          -map "$dir_with_pics1" /pics1 \
          -map "$dir_with_pics2" /pics2

-----------------------------------------------------------------------

MD5 checksums will be recorded due to command -for_backup. The overall
session can be verified by a run of

xorriso -for_backup -indev /dev/sr0 -check_media --

This should report messages like:
  xorriso : UPDATE : Found matching MD5 superblock tag: start=32 size=18
  ...
  xorriso : UPDATE : Found matching MD5 tree tag: start=32 size=10640
  ...
  xorriso : UPDATE : Found matching MD5 session tag: start=32 size=2112019

If a mismatch is reported like

xorriso : WARNING : Found NON-MATCHING MD5 session tag: start=32 size=2112019

but the directory tree is still ok, then you may look for damaged files by

xorriso -for_backup -indev /dev/sr0 -check_md5_r sorry / --

which then reports something like

MD5 MISMATCH: '...path.of.damaged.file.in.the.iso...'

hopefully not about too many or too important files.

Have a nice day :)

Thomas

[Thomas Schmitt]

Hi,
> I'm having trouble finding a good HOWTO for xorriso.

There are examples at the end of the man pages. Online:

https://www.gnu.org/software/xorriso/man_1_xorriso.html#EXAMPLES
  https://www.gnu.org/software/xorriso/man_1_xorrisofs.html#EXAMPLES
  https://www.gnu.org/software/xorriso/man_1_xorrecord.html#EXAMPLES
> Most of the examples use the "-as-cdrecord" option.
> Is that necessary to burn an ISO?

The second and third link above describe the emulation modes which are
intended for existing scripts which use the older programs mkisofs and
cdrecord.

xorriso -as cdrecord is not only for legacy scripts but also covers the
use case of burning a readily prepared ISO 9660 image onto optical media.

Your goal of archiving / backing up a collection of data files from your
hard disk can be achieved by a pipe made of xorriso -as mkisofs and
xorriso -as cdrecord. But xorriso's native command set serves the same
purpose by a single program run.

My proposed example runs for multi-layer BD-R will create an ISO 9660
filesystem directly on the -outdev drive.

The BD-R medium will stay appendable. Further write runs to the same
medium will have to use -dev instead of -outdev, so that the existing ISO
directory tree gets loaded as base for the new session.
(You need to take care that -for_backup comes before -dev, so that the MD5s
 of the existing data files get loaded. It was didactically suboptimal
 to show it in my proposals after -outdev.)

If you want to close the medium to prevent further writing, add command
-close "on" to the xorriso run:

xorriso -for_backup \
          -outdev /dev/sr0 \
          -close on \
          -map "$dir_with_pics1" /pics1 \
          -map "$dir_with_pics2" /pics2

-----------------------------------------------------------------------

MD5 checksums will be recorded due to command -for_backup. The overall
session can be verified by a run of

xorriso -for_backup -indev /dev/sr0 -check_media --

This should report messages like:
  xorriso : UPDATE : Found matching MD5 superblock tag: start=32 size=18
  ...
  xorriso : UPDATE : Found matching MD5 tree tag: start=32 size=10640
  ...
  xorriso : UPDATE : Found matching MD5 session tag: start=32 size=2112019

If a mismatch is reported like

xorriso : WARNING : Found NON-MATCHING MD5 session tag: start=32 size=2112019

but the directory tree is still ok, then you may look for damaged files by

xorriso -for_backup -indev /dev/sr0 -check_md5_r sorry / --

which then reports something like

MD5 MISMATCH: '...path.of.damaged.file.in.the.iso...'

hopefully not about too many or too important files.

Have a nice day :)

Thomas