Re: [gentoo-user] mkisofs: layout

2012-01-31 Thread Joerg Schilling
Andrey Moshbear andrey@gmail.com wrote:

 On Mon, Jan 30, 2012 at 18:13, Joerg Schilling
 joerg.schill...@fokus.fraunhofer.de wrote:
 
  Then you need to get the layerbreak value from your authoring software and 
  you
  need to tell your authoring software to introduce padding. As mentioned 
  before,
  mkisofs hnors the paddung that is announced in the IFO file and it cannot
  introduce padding that is not mentioned in the IFO file.

 I thought mkisofs _was_ an authoring software for data isos.

This is correct, but it does not wholly apply to your case:

Video media needs higher level video authoring software that defines the 
padding. Mkisofs just makes the filesystem structure and honors padding from 
video authoring software.

 Experimental results have shown that mkisofs uses alpha-sort instead
 of inode, directory-order, ctime, or mtime sort.
 Is this required as per ISO 9660?

yes

 Also, is there a way to enable a debug mode so that mkisofs states
 Dir X: File Y: LBA Z
 for each file?

- man isoinfo

Jörg

-- 
 EMail:jo...@schily.isdn.cs.tu-berlin.de (home) Jörg Schilling D-13353 Berlin
   j...@cs.tu-berlin.de(uni)  
   joerg.schill...@fokus.fraunhofer.de (work) Blog: 
http://schily.blogspot.com/
 URL:  http://cdrecord.berlios.de/private/ ftp://ftp.berlios.de/pub/schily



Re: [gentoo-user] mkisofs: layout

2012-01-30 Thread Joerg Schilling
Andrey Moshbear andrey@gmail.com wrote:

 If there a way to force mkisofs to add padding after sector N so that
 the resultin image can be burned as a double layer with no files that
 reside partially on one and partially on the other layer?

Did you read the mkisofs man page?

Why do you believe there is a problem?

Jörg

-- 
 EMail:jo...@schily.isdn.cs.tu-berlin.de (home) Jörg Schilling D-13353 Berlin
   j...@cs.tu-berlin.de(uni)  
   joerg.schill...@fokus.fraunhofer.de (work) Blog: 
http://schily.blogspot.com/
 URL:  http://cdrecord.berlios.de/private/ ftp://ftp.berlios.de/pub/schily



Re: [gentoo-user] mkisofs: layout

2012-01-30 Thread Andrey Moshbear
On Mon, Jan 30, 2012 at 05:02, Joerg Schilling
joerg.schill...@fokus.fraunhofer.de wrote:
 Andrey Moshbear andrey@gmail.com wrote:

 If there a way to force mkisofs to add padding after sector N so that
 the resultin image can be burned as a double layer with no files that
 reside partially on one and partially on the other layer?

 Did you read the mkisofs man page?

I did. The closest thing that was available was -dvd-video, but it
pads all files, not just ones around a layerbreak.
-pad only pads the end of the image.


 Why do you believe there is a problem?


Cdrecord burns DVD+-R DL in PTP mode, so it's going to be inefficient
in terms of I/O if there's a file that's halfway on
one layer and halfway on the other. Were there padding or a dummy
file, this would not be an issue.

Hence, the asking about introducing padding around a layerbreak area.



Re: [gentoo-user] mkisofs: layout

2012-01-30 Thread Joerg Schilling
Andrey Moshbear andrey@gmail.com wrote:

 On Mon, Jan 30, 2012 at 05:02, Joerg Schilling
 joerg.schill...@fokus.fraunhofer.de wrote:
  Andrey Moshbear andrey@gmail.com wrote:
 
  If there a way to force mkisofs to add padding after sector N so that
  the resultin image can be burned as a double layer with no files that
  reside partially on one and partially on the other layer?
 
  Did you read the mkisofs man page?

 I did. The closest thing that was available was -dvd-video, but it
 pads all files, not just ones around a layerbreak.
 -pad only pads the end of the image.

This is not correct.

Mkisofs honors the disk layout defined by the IFO file.


  Why do you believe there is a problem?
 

 Cdrecord burns DVD+-R DL in PTP mode, so it's going to be inefficient
 in terms of I/O if there's a file that's halfway on
 one layer and halfway on the other. Were there padding or a dummy
 file, this would not be an issue.

 Hence, the asking about introducing padding around a layerbreak area.

You are missunderstanding things:

The track recording direction is defined by the pressed pree-groove and cannot 
be changed.

If you are copying DVDs, you need to call cdrecord -v -atip or similar in order 
to retrieve the layerbreak value of the original disk. This value needs to be 
given with the driveropts=layerbreak=xxx option when writing DVD+R/DL.

If someone can tell me how to read the layerbreak value from the IFO file, this 
coule be done automatically

Jörg

-- 
 EMail:jo...@schily.isdn.cs.tu-berlin.de (home) Jörg Schilling D-13353 Berlin
   j...@cs.tu-berlin.de(uni)  
   joerg.schill...@fokus.fraunhofer.de (work) Blog: 
http://schily.blogspot.com/
 URL:  http://cdrecord.berlios.de/private/ ftp://ftp.berlios.de/pub/schily



Re: [gentoo-user] mkisofs: layout

2012-01-30 Thread Andrey Moshbear
On Mon, Jan 30, 2012 at 15:06, Joerg Schilling
joerg.schill...@fokus.fraunhofer.de wrote:
 Andrey Moshbear andrey@gmail.com wrote:

 On Mon, Jan 30, 2012 at 05:02, Joerg Schilling
 joerg.schill...@fokus.fraunhofer.de wrote:
  Andrey Moshbear andrey@gmail.com wrote:
 
  If there a way to force mkisofs to add padding after sector N so that
  the resultin image can be burned as a double layer with no files that
  reside partially on one and partially on the other layer?
 
  Did you read the mkisofs man page?

 I did. The closest thing that was available was -dvd-video, but it
 pads all files, not just ones around a layerbreak.
 -pad only pads the end of the image.

 This is not correct.

 Mkisofs honors the disk layout defined by the IFO file.

Does there exist an IFO system that doesn't rely on VIDEO_TS and
DVD-Video, i.e. a DVD-ROM analog thereof?


  Why do you believe there is a problem?
 

 Cdrecord burns DVD+-R DL in PTP mode, so it's going to be inefficient
 in terms of I/O if there's a file that's halfway on
 one layer and halfway on the other. Were there padding or a dummy
 file, this would not be an issue.

 Hence, the asking about introducing padding around a layerbreak area.

 You are missunderstanding things:

 The track recording direction is defined by the pressed pree-groove and cannot
 be changed.

 If you are copying DVDs, you need to call cdrecord -v -atip or similar in 
 order
 to retrieve the layerbreak value of the original disk. This value needs to be
 given with the driveropts=layerbreak=xxx option when writing DVD+R/DL.

 If someone can tell me how to read the layerbreak value from the IFO file, 
 this
 coule be done automatically


I'm not copying. I'm making a DVD DL iso from a collection of files in
a folder. There's no ripping from
silver disc in any stage of the process.



Re: [gentoo-user] mkisofs: layout

2012-01-30 Thread Joerg Schilling
Andrey Moshbear andrey@gmail.com wrote:

  You are missunderstanding things:
 
  The track recording direction is defined by the pressed pree-groove and 
  cannot
  be changed.
 
  If you are copying DVDs, you need to call cdrecord -v -atip or similar in 
  order
  to retrieve the layerbreak value of the original disk. This value needs to 
  be
  given with the driveropts=layerbreak=xxx option when writing DVD+R/DL.
 
  If someone can tell me how to read the layerbreak value from the IFO file, 
  this
  coule be done automatically
 

 I'm not copying. I'm making a DVD DL iso from a collection of files in
 a folder. There's no ripping from
 silver disc in any stage of the process.

Then you need to get the layerbreak value from your authoring software and you 
need to tell your authoring software to introduce padding. As mentioned before, 
mkisofs hnors the paddung that is announced in the IFO file and it cannot 
introduce padding that is not mentioned in the IFO file.

Jörg

-- 
 EMail:jo...@schily.isdn.cs.tu-berlin.de (home) Jörg Schilling D-13353 Berlin
   j...@cs.tu-berlin.de(uni)  
   joerg.schill...@fokus.fraunhofer.de (work) Blog: 
http://schily.blogspot.com/
 URL:  http://cdrecord.berlios.de/private/ ftp://ftp.berlios.de/pub/schily



Re: [gentoo-user] mkisofs: layout

2012-01-30 Thread Andrey Moshbear
On Mon, Jan 30, 2012 at 18:13, Joerg Schilling
joerg.schill...@fokus.fraunhofer.de wrote:

 Then you need to get the layerbreak value from your authoring software and you
 need to tell your authoring software to introduce padding. As mentioned 
 before,
 mkisofs hnors the paddung that is announced in the IFO file and it cannot
 introduce padding that is not mentioned in the IFO file.

I thought mkisofs _was_ an authoring software for data isos.

Experimental results have shown that mkisofs uses alpha-sort instead
of inode, directory-order, ctime, or mtime sort.
Is this required as per ISO 9660?

Also, is there a way to enable a debug mode so that mkisofs states
Dir X: File Y: LBA Z
for each file?



[gentoo-user] mkisofs: layout

2012-01-29 Thread Andrey Moshbear
If there a way to force mkisofs to add padding after sector N so that
the resultin image can be burned as a double layer with no files that
reside partially on one and partially on the other layer?

~M