Re: BD-R DL burning from ISO
Hi,
> Yes. In a mean time I got several conformations that it's K3b's fault and
> that the code has not been maintained for a long time.
Obviously it is more appealing to start GUI projects
rather than to keep them up to date.
> I'll try xfburn. Can you comment on stability and feature completeness of
> libburn? I think I never used any app that's built upon it.
I am the current developer of the libraries.
Also developer of cdrskin and xorriso.
I do not use anything else for burning and every day
i risk my personal multi-session backups by expanding
them by the development version of xorriso.
(I have more than one backup per day. But it would hurt
my pride to lose a BD-RE with 530 days of recoverable
history.)
> Yes, my device path is /dev/sr0, though I'm trying to burn an ISO image, not
> udf one, but I suppose it's the same.
Whatever you want to burn.
> I've read about BD's defect management and it seems like a smart feature
Your mileage may vary ...
> but I wonder would my standalone (Panasonic) BD player be able to read defect
> managed disk and could I experience so hiccups during movie play because it?
The hickup might then be out of different reasons, if
the player does not read ahead by some dozen MB.
If a defect sector was replaced, then the substitute
is located at the inner rim of the disc. So depending
on the current read position, the head has to make a
long move. And maybe back and forth quite often.
I use Defect Management for the first 50 MB of single
session on BD-RE because that's usually enough to take
the ISO 9660 directory tree of a 23 GB backup.
And i use it for incremental backups which normally
write only 100+ MB per session.
On the wide range i prefer 2x speed and post-burn
checkreading over Defect Management.
With 6x BD-R it makes few difference because my local
filesystem cannot collect data fast enough from single
to feed more than 3x effective speed.
With an image file as input, this would be different.
(To my personal experience, BD-R with Defect Management
fail at least as often as those without. But the
statistical base is not very large.)
> I didn't get that part - does growisofs have broaken
> "BD defect management"?
The upstream version has problems caused by its habit
to automatically format yet unformatted BD-R. After
formatting, it still has a flag set that indicates
unformatted BD-R. This flag causes an inappropriate
SCSI command to be emitted at the end of the burn run
https://bugs.launchpad.net/ubuntu/+source/dvd+rw-tools/+bug/1113679
This is on its way to be fixed in the distros.
Next problem is that it does the check for predictable
medium overflow before formatting, using the unformatted
size. If the input size is larger than the formatted
size but smaller than unformatted, then the burn on
automatically formatted medium will end badly after
having used up the whole medium.
https://bugs.launchpad.net/ubuntu/+source/dvd+rw-tools/+bug/1424215
But as stated, my growisofs proposals circumvent the
situation. Either by presenting an already formatted
BD-R, or by telling growisofs not to format.
> > http://www.gnu.org/software/xorriso/xorriso-tcltk-screen.gif
> Wow! :) That's great! Didn't know about that program. Thanks!
It is mainly intended to demonstrate the capability
of xorriso to serve graphical frontends as dialog partner
and not as child worker.
I.e. the frontend does the presentation and xorriso
does the ISO 9660 and MMC stuff. No duplicate file trees
in GUI and backend. No hald or udev which tell nonsense
about drive and medium.
I used Tcl/Tk because it is easy, quite incapable of
serious computing, and lightweight.
My hope is that some GUI programmer uses a real
programming language and a fancy look+feel.
But currently there are a lot of half-dead frontends
lying around.
Clicking right mouse button on button "Burn image file:"
yields a pop-up window with:
The "Burn image file:" button executes command -as "cdrecord" to
burn a data file from hard disk onto the output drive.
The address of the disk file is taken from the neighboring text field.
If you do not plan to append further data to the medium, then consider
to enable the "Close" switch.
No input drive may be aquired. (Delete all characters from the field
"Input drive/image" and hit Return to give up the input drive.)
The medium in the drive must be blank.
(It is well possible to burn image files to appendable media. But the
image needs to be prepared for the address offset. Who can do that can
as well use one of the command line tools for burning the result. E.g.
xorriso -as cdrecord -v dev=/dev/sr0 -multi stream_recording=32s image.iso
)
It is worth to read man xorriso about xorriso commands
mentioned in the help texts of xorriso-tcltk.
Have a nice day :)
Thomas
Reply to: