Menu
▾
▴
cdrtools-support — Cdrtools user support
You can subscribe to this list here.
| 2014 |
Jan
|
Feb
|
Mar
|
Apr
|
May
|
Jun
|
Jul
(4) |
Aug
(3) |
Sep
|
Oct
|
Nov
(2) |
Dec
(1) |
|---|---|---|---|---|---|---|---|---|---|---|---|---|
| 2015 |
Jan
(3) |
Feb
|
Mar
(3) |
Apr
|
May
(5) |
Jun
|
Jul
|
Aug
|
Sep
|
Oct
(23) |
Nov
(5) |
Dec
(6) |
| 2016 |
Jan
(22) |
Feb
(20) |
Mar
|
Apr
|
May
(4) |
Jun
(4) |
Jul
|
Aug
(7) |
Sep
(1) |
Oct
|
Nov
(2) |
Dec
(1) |
| 2017 |
Jan
|
Feb
|
Mar
(8) |
Apr
|
May
|
Jun
|
Jul
|
Aug
(1) |
Sep
|
Oct
|
Nov
|
Dec
(1) |
| 2018 |
Jan
(1) |
Feb
(1) |
Mar
(1) |
Apr
|
May
|
Jun
|
Jul
(1) |
Aug
|
Sep
|
Oct
|
Nov
|
Dec
(1) |
| 2019 |
Jan
|
Feb
|
Mar
|
Apr
|
May
|
Jun
|
Jul
|
Aug
|
Sep
|
Oct
|
Nov
(3) |
Dec
|
| 2021 |
Jan
(6) |
Feb
(3) |
Mar
(2) |
Apr
|
May
|
Jun
|
Jul
|
Aug
|
Sep
|
Oct
|
Nov
(1) |
Dec
|
|
From: Joerg S. <Joe...@fo...> - 2016-01-12 12:19:34
|
Noel Butler <noe...@au...> wrote:
> > Do you never update your software?
> >
> > This is a man page that is more than 8.5 years old.
> >
> > Jörg
>
>
> always, see my other post.
>
> I remove everything related to cdrtools and try a fresh install
> tomorrow, cant see how some things update and some dont...but obviously
> some shit is not updating on make install, at least the man pages for
> one.
Unless your shell or your make is broken, this would stop the install
procedure, so I guess that you have different releases installed in different
PATHs and your PATH does not find the recent versions first.
Jörg
--
EMail:jo...@sc... (home) Jörg Schilling D-13353 Berlin
joe...@fo... (work) Blog: http://schily.blogspot.com/
URL: http://cdrecord.org/private/ http://sourceforge.net/projects/schilytools/files/'
|
|
From: Noel B. <noe...@au...> - 2016-01-12 12:04:53
|
On 12/01/2016 21:58, Joerg Schilling wrote: > Noel Butler <noe...@au...> wrote: > >> hrmmm OK, thanks, sorry for teh noise, I'll have to investigate why >> current man pages are not installed, since I have man page saying >> >> >> >> -iso-level level >> Set the iso9660 conformance level. Valid numbers are 1..3 and 4. >> >> With level 1, files may only consist of one section and filenames >> are restricted to 8.3 characters. >> >> With level 2, files may only consist of one section. >> >> With level 3, no restrictions (other than ISO-9660:1988) do >> apply. >> >> With all iso9660 levels from 1..3, all filenames are restricted >> to >> upper case letters, numbers and the underscore (_). The maximum >> filename >> length is restricted to 31 characters, the directory nesting level is >> restricted to 8 and the maximum path length is limited to 255 >> characters. > > Do you never update your software? > > This is a man page that is more than 8.5 years old. > > Jörg always, see my other post. I remove everything related to cdrtools and try a fresh install tomorrow, cant see how some things update and some dont...but obviously some shit is not updating on make install, at least the man pages for one. -- If you have the urge to reply to all rather than reply to list, you best first read http://members.ausics.net/qwerty/ |
|
From: Joerg S. <Joe...@fo...> - 2016-01-12 12:03:47
|
Noel Butler <noe...@au...> wrote:
> > And BTW: since a year, mkisofs prints:
> >
> > mkisofs: Value too large for defined data type. File zen.tar.tc is too
> > large for current mkisofs settings (-iso-level 3 or more required) -
> > ignoring
> >
> > instead of:
> >
> > mkisofs: Value too large for defined data type. File zen.tar.tc is too
> > large for current mkisofs settings - ignoring
> >
> > so your problem is outdated software as well.
> >
> > Jörg
>
>
>
> Cdrecord-ProDVD-ProBD-Clone 3.02a04 (x86_64-unknown-linux-gnu) Copyright
> (C) 1995-2015 Joerg Schilling
If you used that software, you did get the man page I mention and you did get
the error message I mentioned....
Jörg
--
EMail:jo...@sc... (home) Jörg Schilling D-13353 Berlin
joe...@fo... (work) Blog: http://schily.blogspot.com/
URL: http://cdrecord.org/private/ http://sourceforge.net/projects/schilytools/files/'
|
|
From: Noel B. <noe...@au...> - 2016-01-12 12:01:49
|
On 12/01/2016 21:54, Joerg Schilling wrote: > Joerg Schilling <Joe...@fo...> wrote: > >> Noel Butler <noe...@au...> wrote: >> >> > > The mkisofs man page contains the explanation, did you read it? >> > > >> > > Jörg >> > >> > I read the man page 5 times over, nowhere does it mention that if you >> > want to burn single files greater than 4GB do you _need_ to use for >> > example -iso-level 3 >> >> This is not correct, see at page #18: >> >> -iso-level level >> Set the ISO-9660 conformance level. Valid numbers are >> 1..3 and 4. >> >> With level 1, files may only consist of one section and >> filenames are restricted to 8.3 characters. >> >> With level 2, files may only consist of one section. >> >> With level 3, no restrictions (other than ISO- >> 9660:1988) do apply. Starting with this level, mkisofs >> also allows files to be larger than 4 GB by implement- >> ing ISO-9660 multi-extent files. >> ... > > And BTW: since a year, mkisofs prints: > > mkisofs: Value too large for defined data type. File zen.tar.tc is too > large for current mkisofs settings (-iso-level 3 or more required) - > ignoring > > instead of: > > mkisofs: Value too large for defined data type. File zen.tar.tc is too > large for current mkisofs settings - ignoring > > so your problem is outdated software as well. > > Jörg Cdrecord-ProDVD-ProBD-Clone 3.02a04 (x86_64-unknown-linux-gnu) Copyright (C) 1995-2015 Joerg Schilling -- If you have the urge to reply to all rather than reply to list, you best first read http://members.ausics.net/qwerty/ |
|
From: Joerg S. <Joe...@fo...> - 2016-01-12 11:59:15
|
Noel Butler <noe...@au...> wrote:
> hrmmm OK, thanks, sorry for teh noise, I'll have to investigate why
> current man pages are not installed, since I have man page saying
>
>
>
> -iso-level level
> Set the iso9660 conformance level. Valid numbers are 1..3 and 4.
>
> With level 1, files may only consist of one section and filenames
> are restricted to 8.3 characters.
>
> With level 2, files may only consist of one section.
>
> With level 3, no restrictions (other than ISO-9660:1988) do apply.
>
> With all iso9660 levels from 1..3, all filenames are restricted to
> upper case letters, numbers and the underscore (_). The maximum filename
> length is restricted to 31 characters, the directory nesting level is
> restricted to 8 and the maximum path length is limited to 255
> characters.
Do you never update your software?
This is a man page that is more than 8.5 years old.
Jörg
--
EMail:jo...@sc... (home) Jörg Schilling D-13353 Berlin
joe...@fo... (work) Blog: http://schily.blogspot.com/
URL: http://cdrecord.org/private/ http://sourceforge.net/projects/schilytools/files/'
|
|
From: Noel B. <noe...@au...> - 2016-01-12 11:56:57
|
On 12/01/2016 21:49, Joerg Schilling wrote:
> Noel Butler <noe...@au...> wrote:
>
>> > The mkisofs man page contains the explanation, did you read it?
>> >
>> > Jörg
>>
>> I read the man page 5 times over, nowhere does it mention that if you
>> want to burn single files greater than 4GB do you _need_ to use for
>> example -iso-level 3
>
> This is not correct, see at page #18:
>
> -iso-level level
> Set the ISO-9660 conformance level. Valid numbers are
> 1..3 and 4.
>
> With level 1, files may only consist of one section and
> filenames are restricted to 8.3 characters.
>
> With level 2, files may only consist of one section.
>
> With level 3, no restrictions (other than ISO-
> 9660:1988) do apply. Starting with this level, mkisofs
> also allows files to be larger than 4 GB by implement-
> ing ISO-9660 multi-extent files.
> ...
>
> Jörg
hrmmm OK, thanks, sorry for teh noise, I'll have to investigate why
current man pages are not installed, since I have man page saying
-iso-level level
Set the iso9660 conformance level. Valid numbers are 1..3 and 4.
With level 1, files may only consist of one section and filenames
are restricted to 8.3 characters.
With level 2, files may only consist of one section.
With level 3, no restrictions (other than ISO-9660:1988) do apply.
With all iso9660 levels from 1..3, all filenames are restricted to
upper case letters, numbers and the underscore (_). The maximum filename
length is restricted to 31 characters, the directory nesting level is
restricted to 8 and the maximum path length is limited to 255
characters.
Level 4 officially does not exists but mkisofs maps it to
ISO-9660:1999 which is ISO-9660 version 2.
With level 4, an enhanced volume descriptor with version number and
file structure version number set to 2 is emitted. There may be more
than 8 levels of directory nesting, there is no need for a file to
contain a dot and the dot has no more special meaning, file names do not
have version numbers, the maximum length for files and directory is
raised to 207. If Rock Ridge is used, the maximum ISO-9660 name length
is reduced to 197.
When creating Version 2 images, mkisofs emits an enhanced volume
descriptor which looks similar to a primary volume descriptor but is
slightly different. Be careful not to use broken software to make
ISO-9660 images bootable by assuming a second PVD copy and patching this
putative PVD copy into an El Torito VD.
...... which obviously differs from what you show...
Cheers
|
|
From: Joerg S. <Joe...@fo...> - 2016-01-12 11:54:20
|
Joerg Schilling <Joe...@fo...> wrote:
> Noel Butler <noe...@au...> wrote:
>
> > > The mkisofs man page contains the explanation, did you read it?
> > >
> > > Jörg
> >
> > I read the man page 5 times over, nowhere does it mention that if you
> > want to burn single files greater than 4GB do you _need_ to use for
> > example -iso-level 3
>
> This is not correct, see at page #18:
>
> -iso-level level
> Set the ISO-9660 conformance level. Valid numbers are
> 1..3 and 4.
>
> With level 1, files may only consist of one section and
> filenames are restricted to 8.3 characters.
>
> With level 2, files may only consist of one section.
>
> With level 3, no restrictions (other than ISO-
> 9660:1988) do apply. Starting with this level, mkisofs
> also allows files to be larger than 4 GB by implement-
> ing ISO-9660 multi-extent files.
> ...
And BTW: since a year, mkisofs prints:
mkisofs: Value too large for defined data type. File zen.tar.tc is too large for current mkisofs settings (-iso-level 3 or more required) - ignoring
instead of:
mkisofs: Value too large for defined data type. File zen.tar.tc is too large for current mkisofs settings - ignoring
so your problem is outdated software as well.
Jörg
--
EMail:jo...@sc... (home) Jörg Schilling D-13353 Berlin
joe...@fo... (work) Blog: http://schily.blogspot.com/
URL: http://cdrecord.org/private/ http://sourceforge.net/projects/schilytools/files/'
|
|
From: Joerg S. <Joe...@fo...> - 2016-01-12 11:49:21
|
Noel Butler <noe...@au...> wrote:
> > The mkisofs man page contains the explanation, did you read it?
> >
> > Jörg
>
> I read the man page 5 times over, nowhere does it mention that if you
> want to burn single files greater than 4GB do you _need_ to use for
> example -iso-level 3
This is not correct, see at page #18:
-iso-level level
Set the ISO-9660 conformance level. Valid numbers are
1..3 and 4.
With level 1, files may only consist of one section and
filenames are restricted to 8.3 characters.
With level 2, files may only consist of one section.
With level 3, no restrictions (other than ISO-
9660:1988) do apply. Starting with this level, mkisofs
also allows files to be larger than 4 GB by implement-
ing ISO-9660 multi-extent files.
...
Jörg
--
EMail:jo...@sc... (home) Jörg Schilling D-13353 Berlin
joe...@fo... (work) Blog: http://schily.blogspot.com/
URL: http://cdrecord.org/private/ http://sourceforge.net/projects/schilytools/files/'
|
|
From: Noel B. <noe...@au...> - 2016-01-12 11:40:46
|
On 12/01/2016 20:22, Joerg Schilling wrote: > Noel Butler <noe...@au...> wrote: > >> On 11/01/2016 23:11, Joerg Schilling wrote: >> > Noel Butler <noe...@au...> wrote: >> > >> >> Hi Joerg >> >> >> >> Whats the largest single file size for mkisofs? >> >> >> >> 4.2G Jan 11 22:00 zen.tar.tc >> >> >> >> mkisofs: Value too large for defined data type. File zen.tar.tc is too >> >> large for current mkisofs settings - ignoring >> >> Total translation table size: 0 >> >> Total rockridge attributes bytes: 185 >> >> Total directory bytes: 0 >> >> Path table size(bytes): 10 >> >> Max brk space used 0 >> >> 175 extents written (0 MB) >> >> >> >> >> >> This is an encrypted file so hard to reduce its size, but I thought >> >> 4.4 >> >> gb in normal file size totals but cant handle 4.2gb in one file? >> > >> > The current maximum is 8 TB for a single file, which is the media size >> > limitation. >> > >> > Jörg >> >> Hrmm, any ideas why it bails out over 4G? I am using the latest >> release >> on linux. >> I did build 4.4G then 4.2G as you see above, it did not like it, yet >> the >> OS has no problem with it.. > > Isn't the message from mkisofs obvious? > > You did not send your command line that caused the message, so I have > no idea > what you indend but mkisofs mentions that the settings you used do not > permit > large files. > yes my bad I should have included the misofs options I was using > The mkisofs man page contains the explanation, did you read it? > > Jörg I read the man page 5 times over, nowhere does it mention that if you want to burn single files greater than 4GB do you _need_ to use for example -iso-level 3 perhaps you can add that in the notes for this option, you should not expect everyone to know or understand iso9660:2009/1999/2999 or whatefer space age year you want to add, you know this stuff, you have to in order to perfect cdrtools, 99.9999999999% of the rest of us dont know this stuff :) anyways, it has been resolved using -iso-level 3, I guess its rare that people burn an iso with a single file larger than 4G, please take on board my suggestion to add that example in man (maybe GUI proggies like k3b etc know how to do it, but I'm scripting secondary backup CD's in addition to other backup methods, so this is run from bash silently in cron. perhaps take on board another suggestion, default iso-level that does this (I tried 3 not 2, maybe 2 does it too) be set as default, as I said, its 2016.. not 2006. thanks -- If you have the urge to reply to all rather than reply to list, you best first read http://members.ausics.net/qwerty/ |
|
From: Joerg S. <Joe...@fo...> - 2016-01-12 10:22:59
|
Noel Butler <noe...@au...> wrote:
> On 11/01/2016 23:11, Joerg Schilling wrote:
> > Noel Butler <noe...@au...> wrote:
> >
> >> Hi Joerg
> >>
> >> Whats the largest single file size for mkisofs?
> >>
> >> 4.2G Jan 11 22:00 zen.tar.tc
> >>
> >> mkisofs: Value too large for defined data type. File zen.tar.tc is too
> >> large for current mkisofs settings - ignoring
> >> Total translation table size: 0
> >> Total rockridge attributes bytes: 185
> >> Total directory bytes: 0
> >> Path table size(bytes): 10
> >> Max brk space used 0
> >> 175 extents written (0 MB)
> >>
> >>
> >> This is an encrypted file so hard to reduce its size, but I thought
> >> 4.4
> >> gb in normal file size totals but cant handle 4.2gb in one file?
> >
> > The current maximum is 8 TB for a single file, which is the media size
> > limitation.
> >
> > Jörg
>
> Hrmm, any ideas why it bails out over 4G? I am using the latest release
> on linux.
> I did build 4.4G then 4.2G as you see above, it did not like it, yet the
> OS has no problem with it..
Isn't the message from mkisofs obvious?
You did not send your command line that caused the message, so I have no idea
what you indend but mkisofs mentions that the settings you used do not permit
large files.
The mkisofs man page contains the explanation, did you read it?
Jörg
--
EMail:jo...@sc... (home) Jörg Schilling D-13353 Berlin
joe...@fo... (work) Blog: http://schily.blogspot.com/
URL: http://cdrecord.org/private/ http://sourceforge.net/projects/schilytools/files/'
|
|
From: Noel B. <noe...@au...> - 2016-01-12 02:35:28
|
-------- Original Message -------- Subject: Re: [Cdrtools-support] file size Date: 12/01/2016 10:59 From: Noel Butler <noe...@au...> To: Joerg Schilling <Joe...@fo...> On 12/01/2016 10:13, Noel Butler wrote: > On 11/01/2016 23:11, Joerg Schilling wrote: >> Noel Butler <noe...@au...> wrote: >> >>> Hi Joerg >>> >>> Whats the largest single file size for mkisofs? >>> >>> 4.2G Jan 11 22:00 zen.tar.tc >>> >>> mkisofs: Value too large for defined data type. File zen.tar.tc is >>> too >>> large for current mkisofs settings - ignoring >>> Total translation table size: 0 >>> Total rockridge attributes bytes: 185 >>> Total directory bytes: 0 >>> Path table size(bytes): 10 >>> Max brk space used 0 >>> 175 extents written (0 MB) >>> >>> >>> This is an encrypted file so hard to reduce its size, but I thought >>> 4.4 >>> gb in normal file size totals but cant handle 4.2gb in one file? >> >> The current maximum is 8 TB for a single file, which is the media size >> limitation. >> >> Jörg > > Hrmm, any ideas why it bails out over 4G? I am using the latest > release > on linux. > I did build 4.4G then 4.2G as you see above, it did not like it, yet > the > OS has no problem with it.. Ahhhm hang on I just fund an old redhat forum post (no I dont use redhat, I use Slackware) that might give answer from you, apply -iso-level 3 I'll try that when I get home tonight, and if it works I'll slap myself and let you know :) -- If you have the urge to reply to all rather than reply to list, you best first read http://members.ausics.net/qwerty/ |
|
From: Noel B. <noe...@au...> - 2016-01-12 00:13:59
|
On 11/01/2016 23:11, Joerg Schilling wrote: > Noel Butler <noe...@au...> wrote: > >> Hi Joerg >> >> Whats the largest single file size for mkisofs? >> >> 4.2G Jan 11 22:00 zen.tar.tc >> >> mkisofs: Value too large for defined data type. File zen.tar.tc is too >> large for current mkisofs settings - ignoring >> Total translation table size: 0 >> Total rockridge attributes bytes: 185 >> Total directory bytes: 0 >> Path table size(bytes): 10 >> Max brk space used 0 >> 175 extents written (0 MB) >> >> >> This is an encrypted file so hard to reduce its size, but I thought >> 4.4 >> gb in normal file size totals but cant handle 4.2gb in one file? > > The current maximum is 8 TB for a single file, which is the media size > limitation. > > Jörg Hrmm, any ideas why it bails out over 4G? I am using the latest release on linux. I did build 4.4G then 4.2G as you see above, it did not like it, yet the OS has no problem with it.. -- If you have the urge to reply to all rather than reply to list, you best first read http://members.ausics.net/qwerty/ |
|
From: Joerg S. <Joe...@fo...> - 2016-01-11 13:11:28
|
Noel Butler <noe...@au...> wrote:
> Hi Joerg
>
> Whats the largest single file size for mkisofs?
>
> 4.2G Jan 11 22:00 zen.tar.tc
>
> mkisofs: Value too large for defined data type. File zen.tar.tc is too
> large for current mkisofs settings - ignoring
> Total translation table size: 0
> Total rockridge attributes bytes: 185
> Total directory bytes: 0
> Path table size(bytes): 10
> Max brk space used 0
> 175 extents written (0 MB)
>
>
> This is an encrypted file so hard to reduce its size, but I thought 4.4
> gb in normal file size totals but cant handle 4.2gb in one file?
The current maximum is 8 TB for a single file, which is the media size
limitation.
Jörg
--
EMail:jo...@sc... (home) Jörg Schilling D-13353 Berlin
joe...@fo... (work) Blog: http://schily.blogspot.com/
URL: http://cdrecord.org/private/ http://sourceforge.net/projects/schilytools/files/'
|
|
From: Noel B. <noe...@au...> - 2016-01-11 12:43:16
|
On 11/01/2016 22:22, Noel Butler wrote: > Hi Joerg > > Whats the largest single file size for mkisofs? > > 4.2G Jan 11 22:00 zen.tar.tc > > mkisofs: Value too large for defined data type. File zen.tar.tc is too > large for current mkisofs settings - ignoring > Total translation table size: 0 > Total rockridge attributes bytes: 185 > Total directory bytes: 0 > Path table size(bytes): 10 > Max brk space used 0 > 175 extents written (0 MB) > > > This is an encrypted file so hard to reduce its size, but I thought 4.4 > gb in normal file size totals but cant handle 4.2gb in one file? > > Cheers OK, so I seeq a lot of old reports it is limited to 4GB??? surely, today, and the age of american privacy invading spies, this surely can not still be a limitation here in 2016 ? -- If you have the urge to reply to all rather than reply to list, you best first read http://members.ausics.net/qwerty/ |
|
From: Noel B. <noe...@au...> - 2016-01-11 12:39:49
|
Hi Joerg Whats the largest single file size for mkisofs? 4.2G Jan 11 22:00 zen.tar.tc mkisofs: Value too large for defined data type. File zen.tar.tc is too large for current mkisofs settings - ignoring Total translation table size: 0 Total rockridge attributes bytes: 185 Total directory bytes: 0 Path table size(bytes): 10 Max brk space used 0 175 extents written (0 MB) This is an encrypted file so hard to reduce its size, but I thought 4.4 gb in normal file size totals but cant handle 4.2gb in one file? Cheers -- If you have the urge to reply to all rather than reply to list, you best first read http://members.ausics.net/qwerty/ |
|
From: Joerg S. <Joe...@fo...> - 2015-12-17 15:33:08
|
grarpamp <gra...@gm...> wrote:
> This example is from a disk on my desk that does not use "no emul'...
>
> El Torito VD version 1 found, boot catalog is in sector 36
> Eltorito validation header:
> Hid 1
> Arch 0 (x86)
> ID ''
> Cksum AA 55 OK
> Key 55 AA
> Eltorito defaultboot header:
> Bootid 88 (bootable)
> Boot media 2 (1.44MB Floppy)
> Load segment 0
> Sys type 0
> Nsect 1
> Bootoff 25 37
This kind of booting has become really rare in the past 15 years.
In your case, the boot image starts at sector 37 (2048 * 37) and uses a size of
720 * 2048 bytes.
Jörg
--
EMail:jo...@sc... (home) Jörg Schilling D-13353 Berlin
joe...@fo... (work) Blog: http://schily.blogspot.com/
URL: http://cdrecord.org/private/ http://sourceforge.net/projects/schilytools/files/'
|
|
From: grarpamp <gra...@gm...> - 2015-12-17 07:47:13
|
On Wed, Dec 16, 2015 at 5:17 AM, Joerg Schilling
> Sorry, but this is impossible in general.
Not in general, only for such cases where the boot
image does that.
> The reason is that most recent boot CDs use no-emulation boot and mark the boot
> "file" as 2048 bytes only.
The definition of most is really quite dependant on the cases
of the end user, not us.
> The first 2048 bytes of the file contain code that pulls the rest of the file from
> disk and only this code knows the size.
In that case, a proper tool of the sort I'm looking for would still
print out all the metadata up to the point where it went off-spec,
including the no emul flags and offset and size of the [length] file,
and extract that file to disk, since it is infact the in-spec physical
boot image the bios jumps to, regardless of whether or not it is the
last humanly logical boot image embedded or placed on disk.
Further, though "2k" is large, there are probably only small
handful of apps generating this code, certainly some of them
opensource, such that decoding and extracting the real logical
image from that wouldn't be hard for a good tool to do. It could
even mask dynamic bits and hash the rest of the "2k" to ID
known instances of it.
> What you can to is calling "isoinfo -i image -d" and check the results.
The initial purpose of my post was to survey any already existing
unix tools for this that people know of or prefer...
... if there are none, isoinfo, in conjunction with mkisofs, would
already have good library knowledge of the spec such that isoinfo
could certainly be made to print the full chain of metadata and
then actually dump the [no emul] boot image.
This example is from a disk on my desk that does not use "no emul'...
El Torito VD version 1 found, boot catalog is in sector 36
Eltorito validation header:
Hid 1
Arch 0 (x86)
ID ''
Cksum AA 55 OK
Key 55 AA
Eltorito defaultboot header:
Bootid 88 (bootable)
Boot media 2 (1.44MB Floppy)
Load segment 0
Sys type 0
Nsect 1
Bootoff 25 37
|
|
From: Joerg S. <Joe...@fo...> - 2015-12-16 11:45:31
|
Hi, a new version of cdrtools is available and makes testing necessary. Mkisofs now supports DVD-Audio and the changes may affect DVD-Video as well. It may be that this change prevents the problem with the abort message: "Implementation botch. Video pad for file %s is %d\n" All changes as a list: NEW features of cdrtools-3.02a04: All: - Added new files RULES/os-mingw32_nt-6.*.id - include/schily/stdint.h Better comment on how to set up an unsigned with the positive value of TYPE_MINVAL(type). Libschily: - libschily: New file astoul.c - libschily: astoi.c now supports ERANGE and parsing TYPE_MINVAL(long) - libschily: astoll.c now supports ERANGE and parsing TYPE_MINVAL(long long) Libcdrdeflt: Libdeflt: Libedc (Optimized by Jörg Schilling, originated by Heiko Eißfeldt he...@he...): Libfile: Libfind: Libhfs_iso: Libmdigest: Libparanoia (Ported/enhanced by Jörg Schilling, originated by Monty xip...@mi...): Libscg: Libscgcmd: Libsiconv: Rscsi: Cdrecord: Cdda2wav (Maintained/enhanced by Jörg Schilling, originated by Heiko Eißfeldt he...@he...): - cdda2wav: A new local autoconfiguration from Heiko Eißfeldt that is indended to better deal with incomplete Linux installations Readcd: Scgcheck: Scgskeleton: Btcflash: Mkisofs (Maintained/enhanced by Jörg Schilling since 1997, originated by Eric Youngdale): - mkisofs/diag/isoinfo.c: fixed directory loop recognition. - mkisofs/diag/isoinfo.c: now adds write permission to directories only temporarily. - mkisofs/diag/isovfy.c add a directory loop recognition to avoid endless loops that eat up all memory with file system images that contain loops. - mkisofs: make sure that the stream media filename honors the -omit-version-number option - mkisofs: use the correct directory size for the stream media filename. mkisofs did write 1 Byte too few data in case of an odd file name length. - mkisofs/diag all diagnostic helper programs had a typo in the usage() speficied instead of specified - mkisofs + diag all diagnostic helper programs have been vulnerable to endless loops when a defective iso image with Rock Ridge was read. Thanks to Heiko Eißfeldt for running related automated tests. - mkisofs: avoid an endless loop in multi session mode and with certain defective ISO filesystem images. - mkisofs now includes DVD-Audio support. To impelemt this, the automated sort routine for DVD/audio/video has been replaced. If there are any problems, please recompile with "smake COPTX=-DOLD_DVD_WEIGHTS" test and report. IMPORTANT: This modification may affect the rare but exitent problem with DVD-Video that aborts with: "Implementation botch. Video pad for file %s is %d\n" because of a negative patch value. It may be that the old weighting algorith let some files slip through the mesh and did not sort them so such a file could appear on a wrong position on the medium. Please test and report. HELIOS TODO: - Add the HELIOS UNICODE mapping code. This needs to be done at UCS-2 level for Joliet and UDF (instead of UTF-8) and only for Rock Ridge (in case of a UTF-8 based target locale) using UTF-8 based translations. - Make the Apple extensions work again with "mkisofs -find" TODO: - read Joliet filenames with multi-session if no TRANS.TBL or RR is present. I am looking for a volunteer for this task! Note that this can never be 100% correct as there is no relation between the names on the master (UNIX) filesystem, the ISO-9660 names and the Joliet names. Only the Rock Ridge names are untranslated with respect to the original files on the master (UNIX) filesystem. - add libecc/edc for CDI and similar. CYGWIN NT-4.0 NOTES: To compile on Cygwin32, get Cygwin and install it. For more information read README.win32 The files are located on: http://sourceforge.net/projects/cdrtools/files/alpha/ ... NOTE: These tar archives are 100% POSIX compatible. GNU tar may get some minor trouble. If you like a 100% POSIX compliant tar, get star from http://sourceforge.net/projects/s-tar/files/ of from the schily-* tarball at: http://sourceforge.net/projects/schilytools/files/ WARNING: Do not use 'winzip' to extract the tar file! Winzip cannot extract symbolic links correctly. Jörg -- EMail:jo...@sc... (home) Jörg Schilling D-13353 Berlin joe...@fo... (work) Blog: http://schily.blogspot.com/ URL: http://cdrecord.org/private/ http://sourceforge.net/projects/schilytools/files/' |
|
From: Joerg S. <Joe...@fo...> - 2015-12-16 10:17:46
|
grarpamp <gra...@gm...> wrote:
> Hello.
>
> Any suggestions on / links to unix based tools that
> will list and extract the embedded boot images from
> existing bootable cd's / dvd's?
>
> Decoding and dd discs by hand is a bit old :)
Sorry, but this is impossible in general.
The reason is that most recent boot CDs use no-emulation boot and mark the boot
"file" as 2048 bytes only.
The first 2048 bytes of the file contain code that pulls the rest of the file from
disk and only this code knows the size.
What you can to is calling "isoinfo -i image -d" and check the results.
Jörg
--
EMail:jo...@sc... (home) Jörg Schilling D-13353 Berlin
joe...@fo... (work) Blog: http://schily.blogspot.com/
URL: http://cdrecord.org/private/ http://sourceforge.net/projects/schilytools/files/'
|
|
From: grarpamp <gra...@gm...> - 2015-12-16 06:09:11
|
By listing I mean listing the metadata related to the images... locations on disc of all the tables / indexes / images, sizes, decoding of table content, etc for debugging and verification. Not whatever is inside the images themselves, of course. |
|
From: grarpamp <gra...@gm...> - 2015-12-16 05:33:53
|
Hello. Any suggestions on / links to unix based tools that will list and extract the embedded boot images from existing bootable cd's / dvd's? Decoding and dd discs by hand is a bit old :) Thanks. |
|
From: Joerg S. <Joe...@fo...> - 2015-11-24 16:32:55
|
Jakob <je...@ma...> wrote:
> On 2015?11?24? 16:22, Joerg Schilling wrote:
> > If you like to create a BluRay video disk, you need a program that creates the
> > filesystem layout together with the defined java code to control the player.
> >
> > Do you have such a program?
>
> I have the correct filesystem layout and files adhering to Blu-ray video
> standard on my hard disk. Now I was wondering how to create an .iso file
> in a manner that'd be compatible with regular Blu-ray players. The only
> information I have found out so far is that it needs to be UDF 2.5 or 2.6.
Mkisofs is currently not yet able to UDF-2.x images.
IIRC, I got a positive feedback some years ago that the UDF-1.x filesystem
works. What exactly is your problem?
Jörg
--
EMail:jo...@sc... (home) Jörg Schilling D-13353 Berlin
joe...@fo... (work) Blog: http://schily.blogspot.com/
URL: http://cdrecord.org/private/ http://sourceforge.net/projects/schilytools/files/'
|
|
From: Jakob <je...@ma...> - 2015-11-24 15:35:13
|
On 2015年11月24日 16:22, Joerg Schilling wrote: > If you like to create a BluRay video disk, you need a program that creates the > filesystem layout together with the defined java code to control the player. > > Do you have such a program? I have the correct filesystem layout and files adhering to Blu-ray video standard on my hard disk. Now I was wondering how to create an .iso file in a manner that'd be compatible with regular Blu-ray players. The only information I have found out so far is that it needs to be UDF 2.5 or 2.6. |
|
From: Joerg S. <Joe...@fo...> - 2015-11-24 15:23:09
|
Jakob <je...@ma...> wrote:
> Hello,
>
> I already have the correct file structure on my disk, and am now trying
> to generate an .iso file with an UDF 2.5 file system that could
> potentially be used to burn a Blu-ray disk. After reading the man page
> of mkisofs I am however not sure how to tackle this, as I guess my
> knowledge is simply lacking. If I just use the -UDF switch, is that
> already enough? I couldn't manage to properly mount and play back the
> .iso file after I tried this, but udf is also not listed in
> /proc/filesystems, so maybe my kernel is just not able to do that?
> That'd strike me as odd, as I'm able to play back commercial Blu-rays.
>
> Is there something like the -dvd-video switch just for Blu-ray video?
> I'm using Arch Linux with Linux kernel 4.2.5 and cdrtools 3.01 from the
> Arch Linux repositories.
If you like to create a BluRay video disk, you need a program that creates the
filesystem layout together with the defined java code to control the player.
Do you have such a program?
Jörg
--
EMail:jo...@sc... (home) Jörg Schilling D-13353 Berlin
joe...@fo... (work) Blog: http://schily.blogspot.com/
URL: http://cdrecord.org/private/ http://sourceforge.net/projects/schilytools/files/'
|
|
From: Jakob <je...@ma...> - 2015-11-24 14:09:01
|
Hello, I already have the correct file structure on my disk, and am now trying to generate an .iso file with an UDF 2.5 file system that could potentially be used to burn a Blu-ray disk. After reading the man page of mkisofs I am however not sure how to tackle this, as I guess my knowledge is simply lacking. If I just use the -UDF switch, is that already enough? I couldn't manage to properly mount and play back the .iso file after I tried this, but udf is also not listed in /proc/filesystems, so maybe my kernel is just not able to do that? That'd strike me as odd, as I'm able to play back commercial Blu-rays. Is there something like the -dvd-video switch just for Blu-ray video? I'm using Arch Linux with Linux kernel 4.2.5 and cdrtools 3.01 from the Arch Linux repositories. Cheers Jakob |
2 messages has been excluded from this view by a project administrator.
