[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: BD-R DL burning from ISO



On Sunday, 1. March 2015. 15.56.21 you wrote:
> Hi,
> 
> firstly:
> Your trouble has nothing to do with image content.
> You may burn what you want as long as it fits into
> the number of 2048 blocks, which the medium offers.
> 

So I suspected.

> It might be that GUI frontends are still not ready
> for BD media. The halfways modern backends (growisofs,
> cdrecord, libburn) support them.
> 

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.

> I helped to beef up xfburn version 0.5.2 so that
> it accepts BD media and makes use of the according
> libburn capabilities.
>

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.
 
> On the command line there are:
> 
>   dvd+rw-format /dev/sr0
>   growisofs -Z /dev/sr0="$HOME"/my_image.udf
> 
> or
> 
>   growisofs -use-the-force-luke=spare:none -Z /dev/sr0="$HOME"/my_image.udf
> 
> or
> 
>   cdrecord -v dev=/dev/sr0 "$HOME"/my_image.udf
> 
> or
> 
>   cdrskin -v dev=/dev/sr0 "$HOME"/my_image.udf
> 
> or
> 
>   xorriso -as cdrecord -v dev=/dev/sr0 "$HOME"/my_image.udf
> 
> 
> The drive address is assumed as /dev/sr0 here.
> You may get a list of accessible optical drives by
> 
>   xorriso -devices
> 
> which might say something like
> 
>   0  -dev '/dev/sr0' rwrw-- :  'TSSTcorp' 'CDDVDW SH-S203B'
>   1  -dev '/dev/sr1' rwrw-- :  'HL-DT-ST' 'BD-RE BH16NS40'
> 
> (I.e. i'd better use /dev/sr1 for BD burning.)
> 
>

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.

> If you want full nominal speed on formatted BD, use
> cdrskin or xorriso -as cdrecord option
>    stream_recording=on
> No checkreading and no bad block replacement will happen
> then.
> 
> If you want formatted BD-R (for slow checkreading):
> 
>   dvd+rw-format /dev/sr0
> 
> or
> 
>   cdrskin -v dev=/dev/sr0 blank=format_defectmgt
> 
> or
> 
>   xorriso -outdev /dev/sr0 -format as_needed
> 
> These will get you the default size. There are options to
> vary the formatted size, too.
> 

I've read about BD's defect management and it seems like a smart feature 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?

> > I'm trying to understand where is the problem and should this be
> > submitted as a bug report or a feature request and to whom.
> 
> The problem seems with k3b.
> 

Yes, definitelly.

> > Couldn't some program simply read raw data in the ISO image and then
> > burn it to a media bit by bit, or things just don't work that way?
> 
> Well, we have to send data in chunks of at least 2048
> bytes, better of 64 KiB. The communications protocol
> between burn (backend) program and drive is defined
> in SCSI/MMC. BD are mentioned since MMC revision 5.
> 

I see. That makes things quite clear and straitforward.

> > It is also stated on
> > dvd+rw-tools' web page that growisofs depends on cdrtools, namely
> > mkisofs,
> 
> Only on mkisofs, not on cdrecord.
> growisofs is its own burn backend.
> Hard to surpass with DVD and with only a little
> flaw about automatic formatting of BD-R. (Above
> examples work around it.)
> 

I didn't get that part - does growisofs have broaken "BD defect management"?

> > I speculate that in this case I don't need mkisofs because
> > I already have (UDF 2.5) file system in the image and I'm "merely"
> > trying to burn it on a BD-R DL disk. Right?
> 
> Yes.
> 
> > K3b claims that it supports Blu-ray
> 
> Then your problem should be considered a bug.
> At least if you manage to burn by any of the above
> command line examples.
> 

Yes, it's definitely a bug because K3b sees perfectly normal (usable) BD50 ISO 
images as "not usable".

> > who gets the job done and how? :S
> 
> Choose one of the programs mentioned above.
> The command liners have nearly no dependencies.
> xfburn might drag in half of Xfce.
> (I can offer a frontend demo named xorriso-tcltk
>   http://www.gnu.org/software/xorriso/xorriso-tcltk-screen.gif
> which depends only on Tcl/Tk.)
> 

Wow! :) That's great! Didn't know about that program. Thanks!

> 
> Have a nice day :)
> 
> Thomas

Thank you Thomas, you too.

Marcus


Reply to: