Menu
▾
▴
cdrtools-developers — Cdrtools developers discuss
You can subscribe to this list here.
| 2014 |
Jan
|
Feb
|
Mar
|
Apr
|
May
|
Jun
|
Jul
|
Aug
|
Sep
|
Oct
|
Nov
|
Dec
(11) |
|---|---|---|---|---|---|---|---|---|---|---|---|---|
| 2015 |
Jan
(12) |
Feb
|
Mar
|
Apr
|
May
|
Jun
|
Jul
(7) |
Aug
(6) |
Sep
|
Oct
|
Nov
(5) |
Dec
(1) |
| 2016 |
Jan
|
Feb
|
Mar
|
Apr
|
May
|
Jun
|
Jul
(2) |
Aug
|
Sep
|
Oct
|
Nov
|
Dec
(6) |
| 2017 |
Jan
|
Feb
|
Mar
|
Apr
|
May
(2) |
Jun
|
Jul
|
Aug
|
Sep
(1) |
Oct
|
Nov
|
Dec
|
| 2018 |
Jan
|
Feb
(1) |
Mar
(1) |
Apr
(1) |
May
|
Jun
|
Jul
|
Aug
|
Sep
(1) |
Oct
|
Nov
(1) |
Dec
|
| 2019 |
Jan
|
Feb
|
Mar
|
Apr
|
May
|
Jun
|
Jul
(2) |
Aug
|
Sep
|
Oct
|
Nov
(2) |
Dec
(1) |
| 2021 |
Jan
|
Feb
|
Mar
(2) |
Apr
|
May
|
Jun
|
Jul
|
Aug
|
Sep
(2) |
Oct
|
Nov
|
Dec
|
|
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-11-26 14:23:08
|
Joerg Schilling <Joe...@fo...> wrote: > Good catch! > > > > > The complete patch looks like this: > > > > diff --git a/mkisofs/udf.c b/mkisofs/udf.c > > index 25feca6..04390e2 100644 > > --- a/mkisofs/udf.c > > +++ b/mkisofs/udf.c Hi, a fixed version is in the most recent schily tools: https://sourceforge.net/projects/schilytools/files/ A new cdrtools version may be created within the next 2 weeks. 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-11-26 10:47:05
|
"Ganssauge, Gottfried" <Got...@ha...> wrote:
> Hello list,
>
> We recently had to switch the machine which produces UDF images for our products from Ubuntu-12 LTS to Ubuntu-14 LTS.
> Unfortunately suddenly all UDF images produced by the new machine were rejected by our DVD-ROM manufacturer. Their
> pre production verification step spit out the following message:
>
> PI51_U14 - Fehler:
> [e] DVD 1 Volume Descriptor Sequences are not equivalent
> [w] DVD 1 Inconsistency between UDF Main and Reserve Volume Descriptor Sequence
>
> I started to investigate and found out that the Volume Set ID is slightly different between the original and the copy of the primary volume descriptor.
> As these problems remained consistently with images written on the new machine we suspected a connection to mkisofs which we use to create our images.
> On the old machine we used 3.01a24 whereas on the new machine 3.01a28 is used - in both cases directly from the Ubuntu software archives.
> Further investigation showed that the difference is in the Volume Set Identifier field at Offset 72 in the Primary Volume Descriptor.
>
> I then went through mkisofs' sources and could locate the problematic code at line 1990 in mkisofs/udf.c in routine udf_main_seq_write.
> That routine is called twice - once to write the main VDS and then again to write the reserve VDS.
> Between calls to that routine some time passes so that the call to clock() returns a slightly different time when called the second time.
> To fix that problem I used the tv_usec field of "tv_begun" which is initialized directly after "begun" and then left stable.
Good catch!
> The complete patch looks like this:
>
> diff --git a/mkisofs/udf.c b/mkisofs/udf.c
> index 25feca6..04390e2 100644
> --- a/mkisofs/udf.c
> +++ b/mkisofs/udf.c
> @@ -98,7 +98,7 @@ static UConst char sccsid[] =
> extern int use_sparcboot;
>
> extern struct directory *root;
> -extern struct timeval tv_begun;
> +extern time_t begun;
>
> static unsigned lba_main_seq;
> static unsigned lba_main_seq_copy;
> @@ -723,7 +723,7 @@ set_primary_vol_desc(buf, lba)
> /*pvd->volume_abstract;*/
> /*pvd->volume_copyright_notice;*/
> /*pvd->application_ident;*/
> - set_timestamp_from_time_t(&pvd->recording_date_and_time, tv_begun.tv_sec);
> + set_timestamp_from_time_t(&pvd->recording_date_and_time, begun);
> set_impl_ident(&pvd->impl_ident);
> set_tag(&pvd->desc_tag, UDF_TAGID_PRIMARY_VOLUME_DESC, lba, 512);
It seems that your patch is reversed.
I'll see what I can do.
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: Jonatã B. <jo...@jo...> - 2015-11-25 20:06:13
|
This would solve the issue I noted months ago: http://sourceforge.net/p/cdrtools/mailman/message/34410200/ -- Jonatã Bolzan Loss On Wed, Nov 25, 2015 at 4:40 PM, Ganssauge, Gottfried < Got...@ha...> wrote: > Hello list, > > We recently had to switch the machine which produces UDF images for our > products from Ubuntu-12 LTS to Ubuntu-14 LTS. > Unfortunately suddenly all UDF images produced by the new machine were > rejected by our DVD-ROM manufacturer. Their > pre production verification step spit out the following message: > > PI51_U14 - Fehler: > [e] DVD 1 Volume Descriptor Sequences are > not equivalent > [w] DVD 1 Inconsistency between UDF Main and > Reserve Volume Descriptor Sequence > > I started to investigate and found out that the Volume Set ID is slightly > different between the original and the copy of the primary volume > descriptor. > As these problems remained consistently with images written on the new > machine we suspected a connection to mkisofs which we use to create our > images. > On the old machine we used 3.01a24 whereas on the new machine 3.01a28 is > used - in both cases directly from the Ubuntu software archives. > > I got the sources for both versions and could verify the problem with both > versions. Then I got 3.02a2 and there I could also verify the problem. > The test script I used is as follows: > #!/usr/bin/env bash > here=$(dirname $(readlink -f $0)) > myself=$(basename $0 .sh) > UDF=${myself}.udf > LOG=${myself}.log > > MKISOFS=$here/mkisofs/OBJ/x86_64-linux-cc/mkisofs > > $MKISOFS -v -o $UDF -log-file $LOG -udf -follow-links -joliet > -rational-rock -pad -volid DVD1 -appid PI51 -publisher "Rudolf Haufe Verlag > GmbH & Co KG" -input-charset iso8859-1 -iso-level 3 $here/mkisofs > main_vds=/tmp/$$.main > reserve_vds=/tmp/$$.reserve > trap "rm -f $main_vds $reserve_vds" 0 1 2 3 5 15 > dd if=$UDF bs=2048 skip=32 count=16 of=$main_vds 2>/dev/null > dd if=$UDF bs=2048 skip=48 count=16 of=$reserve_vds 2>/dev/null > cmp -l $main_vds $reserve_vds | egrep -v '^ > *(5|13|2053|2061|4101|4109|6149|6157|8197|8205|10245|10253) +' > > Don't get confused by the egrep call on the last line - it sorts out the > locations in the descriptor tags which differ by default. > On unmodified sources this script produces the following output: > 3.02a02 (x86_64-unknown-linux-gnu) > re-directing all messages to HAUFECHECK.log > 9 10 227 > 10 151 354 > 87 70 71 > 88 102 61 > 89 66 62 > > Further investigation showed that the difference is in the Volume Set > Identifier field at Offset 72 in the Primary Volume Descriptor. > > I then went through mkisofs' sources and could locate the problematic code > at line 1990 in mkisofs/udf.c in routine udf_main_seq_write. > That routine is called twice - once to write the main VDS and then again > to write the reserve VDS. > Between calls to that routine some time passes so that the call to clock() > returns a slightly different time when called the second time. > To fix that problem I used the tv_usec field of "tv_begun" which is > initialized directly after "begun" and then left stable. > > The complete patch looks like this: > > diff --git a/mkisofs/udf.c b/mkisofs/udf.c > index 25feca6..04390e2 100644 > --- a/mkisofs/udf.c > +++ b/mkisofs/udf.c > @@ -98,7 +98,7 @@ static UConst char sccsid[] = > extern int use_sparcboot; > > extern struct directory *root; > -extern struct timeval tv_begun; > +extern time_t begun; > > static unsigned lba_main_seq; > static unsigned lba_main_seq_copy; > @@ -723,7 +723,7 @@ set_primary_vol_desc(buf, lba) > /*pvd->volume_abstract;*/ > /*pvd->volume_copyright_notice;*/ > /*pvd->application_ident;*/ > - set_timestamp_from_time_t(&pvd->recording_date_and_time, > tv_begun.tv_sec); > + set_timestamp_from_time_t(&pvd->recording_date_and_time, begun); > set_impl_ident(&pvd->impl_ident); > set_tag(&pvd->desc_tag, UDF_TAGID_PRIMARY_VOLUME_DESC, lba, 512); > } > @@ -831,7 +831,7 @@ set_logical_vol_integrity_desc(buf, lba) > udf_logical_volume_integrity_desc *lvid = > (udf_logical_volume_integrity_desc *)buf; > > - set_timestamp_from_time_t(&lvid->recording_date, tv_begun.tv_sec); > + set_timestamp_from_time_t(&lvid->recording_date, begun); > set32(&lvid->integrity_type, UDF_INTEGRITY_TYPE_CLOSE); > /*lvid->next_integrity_extent;*/ > set64(&lvid->logical_volume_contents_use.unique_id, > @@ -859,7 +859,7 @@ set_file_set_desc(buf, rba) > { > udf_file_set_desc *fsd = (udf_file_set_desc *)buf; > > - set_timestamp_from_time_t(&fsd->recording_date_and_time, > tv_begun.tv_sec); > + set_timestamp_from_time_t(&fsd->recording_date_and_time, begun); > set16(&fsd->interchange_level, 3); > set16(&fsd->maximum_interchange_level, 3); > set32(&fsd->character_set_list, 1); > @@ -1986,8 +1986,8 @@ udf_main_seq_write(out) > * volume_set_id needs to be set to a (64-bit) "unique" number. > * This will have to do for now. > */ > - volume_set_id[0] = tv_begun.tv_sec; > - volume_set_id[1] = (unsigned)tv_begun.tv_usec; /* XXX Maybe > non-portable */ > + volume_set_id[0] = begun; > + volume_set_id[1] = (unsigned)clock(); /* XXX Maybe non-portable > */ > > memset(buf, 0, sizeof (buf)); > set_primary_vol_desc(buf, last_extent_written++); > > That fixed the problem for us. > > Cheers, > > Gottfried Ganßauge > Entwickler > Content Engineering & Development > > ------------------------------------------------------------------ > Haufe-Lexware GmbH & Co. KG > Ein Unternehmen der Haufe Gruppe > Munzinger Str. 9, 79111 Freiburg > Tel. +49 761 898-0 > E-Mail: Got...@ha... > Internet: http://www.haufe-lexware.com > ------------------------------------------------------------------ > Kommanditgesellschaft, Sitz und Registergericht Freiburg, HRA 4408 > Komplementäre: Haufe-Lexware Verwaltungs GmbH, > Sitz und Registergericht Freiburg, HRB 5557; Martin Laqua > Beiratsvorsitzende: Andrea Haufe > Geschäftsführung: Isabel Blank, Markus Dränert, Jörg Frey, > Birte Hackenjos, Randolf Jessl, Markus Reithwiesner, > Joachim Rotzinger, Dr. Carsten Thies > ------------------------------------------------------------------ > > > > ------------------------------------------------------------------------------ > Go from Idea to Many App Stores Faster with Intel(R) XDK > Give your users amazing mobile app experiences with Intel(R) XDK. > Use one codebase in this all-in-one HTML5 development environment. > Design, debug & build mobile apps & 2D/3D high-impact games for multiple > OSs. > http://pubads.g.doubleclick.net/gampad/clk?id=254741551&iu=/4140 > _______________________________________________ > Cdrtools-developers mailing list > Cdr...@li... > https://lists.sourceforge.net/lists/listinfo/cdrtools-developers > |
|
From: Ganssauge, G. <Got...@ha...> - 2015-11-25 18:55:59
|
Hello list,
We recently had to switch the machine which produces UDF images for our products from Ubuntu-12 LTS to Ubuntu-14 LTS.
Unfortunately suddenly all UDF images produced by the new machine were rejected by our DVD-ROM manufacturer. Their
pre production verification step spit out the following message:
PI51_U14 - Fehler:
[e] DVD 1 Volume Descriptor Sequences are not equivalent
[w] DVD 1 Inconsistency between UDF Main and Reserve Volume Descriptor Sequence
I started to investigate and found out that the Volume Set ID is slightly different between the original and the copy of the primary volume descriptor.
As these problems remained consistently with images written on the new machine we suspected a connection to mkisofs which we use to create our images.
On the old machine we used 3.01a24 whereas on the new machine 3.01a28 is used - in both cases directly from the Ubuntu software archives.
I got the sources for both versions and could verify the problem with both versions. Then I got 3.02a2 and there I could also verify the problem.
The test script I used is as follows:
#!/usr/bin/env bash
here=$(dirname $(readlink -f $0))
myself=$(basename $0 .sh)
UDF=${myself}.udf
LOG=${myself}.log
MKISOFS=$here/mkisofs/OBJ/x86_64-linux-cc/mkisofs
$MKISOFS -v -o $UDF -log-file $LOG -udf -follow-links -joliet -rational-rock -pad -volid DVD1 -appid PI51 -publisher "Rudolf Haufe Verlag GmbH & Co KG" -input-charset iso8859-1 -iso-level 3 $here/mkisofs
main_vds=/tmp/$$.main
reserve_vds=/tmp/$$.reserve
trap "rm -f $main_vds $reserve_vds" 0 1 2 3 5 15
dd if=$UDF bs=2048 skip=32 count=16 of=$main_vds 2>/dev/null
dd if=$UDF bs=2048 skip=48 count=16 of=$reserve_vds 2>/dev/null
cmp -l $main_vds $reserve_vds | egrep -v '^ *(5|13|2053|2061|4101|4109|6149|6157|8197|8205|10245|10253) +'
Don't get confused by the egrep call on the last line - it sorts out the locations in the descriptor tags which differ by default.
On unmodified sources this script produces the following output:
3.02a02 (x86_64-unknown-linux-gnu)
re-directing all messages to HAUFECHECK.log
9 10 227
10 151 354
87 70 71
88 102 61
89 66 62
Further investigation showed that the difference is in the Volume Set Identifier field at Offset 72 in the Primary Volume Descriptor.
I then went through mkisofs' sources and could locate the problematic code at line 1990 in mkisofs/udf.c in routine udf_main_seq_write.
That routine is called twice - once to write the main VDS and then again to write the reserve VDS.
Between calls to that routine some time passes so that the call to clock() returns a slightly different time when called the second time.
To fix that problem I used the tv_usec field of "tv_begun" which is initialized directly after "begun" and then left stable.
The complete patch looks like this:
diff --git a/mkisofs/udf.c b/mkisofs/udf.c
index 25feca6..04390e2 100644
--- a/mkisofs/udf.c
+++ b/mkisofs/udf.c
@@ -98,7 +98,7 @@ static UConst char sccsid[] =
extern int use_sparcboot;
extern struct directory *root;
-extern struct timeval tv_begun;
+extern time_t begun;
static unsigned lba_main_seq;
static unsigned lba_main_seq_copy;
@@ -723,7 +723,7 @@ set_primary_vol_desc(buf, lba)
/*pvd->volume_abstract;*/
/*pvd->volume_copyright_notice;*/
/*pvd->application_ident;*/
- set_timestamp_from_time_t(&pvd->recording_date_and_time, tv_begun.tv_sec);
+ set_timestamp_from_time_t(&pvd->recording_date_and_time, begun);
set_impl_ident(&pvd->impl_ident);
set_tag(&pvd->desc_tag, UDF_TAGID_PRIMARY_VOLUME_DESC, lba, 512);
}
@@ -831,7 +831,7 @@ set_logical_vol_integrity_desc(buf, lba)
udf_logical_volume_integrity_desc *lvid =
(udf_logical_volume_integrity_desc *)buf;
- set_timestamp_from_time_t(&lvid->recording_date, tv_begun.tv_sec);
+ set_timestamp_from_time_t(&lvid->recording_date, begun);
set32(&lvid->integrity_type, UDF_INTEGRITY_TYPE_CLOSE);
/*lvid->next_integrity_extent;*/
set64(&lvid->logical_volume_contents_use.unique_id,
@@ -859,7 +859,7 @@ set_file_set_desc(buf, rba)
{
udf_file_set_desc *fsd = (udf_file_set_desc *)buf;
- set_timestamp_from_time_t(&fsd->recording_date_and_time, tv_begun.tv_sec);
+ set_timestamp_from_time_t(&fsd->recording_date_and_time, begun);
set16(&fsd->interchange_level, 3);
set16(&fsd->maximum_interchange_level, 3);
set32(&fsd->character_set_list, 1);
@@ -1986,8 +1986,8 @@ udf_main_seq_write(out)
* volume_set_id needs to be set to a (64-bit) "unique" number.
* This will have to do for now.
*/
- volume_set_id[0] = tv_begun.tv_sec;
- volume_set_id[1] = (unsigned)tv_begun.tv_usec; /* XXX Maybe non-portable */
+ volume_set_id[0] = begun;
+ volume_set_id[1] = (unsigned)clock(); /* XXX Maybe non-portable */
memset(buf, 0, sizeof (buf));
set_primary_vol_desc(buf, last_extent_written++);
That fixed the problem for us.
Cheers,
Gottfried Ganßauge
Entwickler
Content Engineering & Development
------------------------------------------------------------------
Haufe-Lexware GmbH & Co. KG
Ein Unternehmen der Haufe Gruppe
Munzinger Str. 9, 79111 Freiburg
Tel. +49 761 898-0
E-Mail: Got...@ha...
Internet: http://www.haufe-lexware.com
------------------------------------------------------------------
Kommanditgesellschaft, Sitz und Registergericht Freiburg, HRA 4408
Komplementäre: Haufe-Lexware Verwaltungs GmbH,
Sitz und Registergericht Freiburg, HRB 5557; Martin Laqua
Beiratsvorsitzende: Andrea Haufe
Geschäftsführung: Isabel Blank, Markus Dränert, Jörg Frey,
Birte Hackenjos, Randolf Jessl, Markus Reithwiesner,
Joachim Rotzinger, Dr. Carsten Thies
------------------------------------------------------------------
|
|
From: Joerg S. <Joe...@fo...> - 2015-11-06 12:31:59
|
See: https://sourceforge.net/projects/cdrtools/files/alpha/ Please note that due to the fact that this release mainly enhances portability, adds a bugfix for libparanoia and ointroduced better sound output support, there is a plan to make the test phase short and create a 3.02-final soon. ***************** Please Test ********************************* NEW features of cdrtools-3.02a01: This is the first localization step for cdrtools. All programs now (hopefully) call gettext() for all strings that need localization. - The next step will include dgettext() calls for the libraries. - The following step will include the extracted strings - The last step will include German translations and install support for the resulting binary message object files. ----------> Please test and report compilation problems! <--------- ***** NOTE: As mentioned since 2004, frontends to cdrtools should ***** ***** call all programs from cdrtools in the "C" locale ***** ***** by e.g. calling: LC_ALL=C cdrecord .... ***** ***** unless these frontends support localized strings ***** ***** used by the cdrtools with NLS support. ***** This version compiles on Win-DOS using the Microsoft compiler cl.exe but warning: due to missing POSIX compliance with basic features (e.g. stat() does not return inode numbers), there are many problems with the resulting code and thus it is recommended to better use a POSIX layer on top of WIN-DOS. *** WARNING *** *** Need new smake *** *** Due to the fact that schily-2014-04-03 introduced to use new macro *** expansions and a related bug fix in smake, you need a new smake *** to compile this source. To ensure this, get a recent "schily" *** tarball from http://sourceforge.net/projects/schilytools/files/ *** and call: cd ./psmake ./MAKE-all cd .. psmake/smake psmake/smake install The new smake version mentioned above is smake-1.2.4. Note that smake-1.2.5 exists and is preferrable. Now you have a new smake that is able to compile this source. Note that the major makefile restructuring introduced in schily-2014-04-03 is now more than one month ago and thus seems to work without problems. WARNING: the new version of the isoinfo program makes use of the *at() series of functions that have been introduced by Sun in August 2001 and added to POSIX.1-2008. For older platforms, libschily now includes emulations for these functions but these emulations have not yet been tested thoroughly. Please report problems! All: - As the defective typedef for idtype_t is already in NetBSD-5, we added a workaround based on a new related autoconf test. - Added support to compile on "Bitrig", an OpenBSD fork for non automake aware make implementations like gmake. - Added an autoconf test for tcgetsid() Libschily: Libcdrdeflt: Libdeflt: Libedc (Optimized by Jörg Schilling, originated by Heiko Eißfeldt he...@he...): Libfile: Libfind: - libfind: a final workaround for the problems with vfork() in the linux system include files has been introduced and a variable has been declared volatile. - libfind no longer uses gettext() but dgettext() and thus no longer destroys the message binding from the Bourne Shell - libfind: find -mtime +2s -mtime +20s now works, as file timestamps are now compared to the current time. Before, the current time +60s was used - a timestamp that is needed for switching between both time stamp variants for -ls. Libhfs_iso: Libmdigest: Libparanoia (Ported/enhanced by Jörg Schilling, originated by Monty xip...@mi...): - libparanoia: Make abs() a self defined macro as ISO-C defines abs() to be a function with int parameter. - libparanoia: work around a bug that resulted from uninitalized statistics data for C2 checks in case that C2 checking was disabled. Libscg: - libscg: added a new error code to make search for the right device node work again with newer OpenBSD versions. Libscgcmd: Libsiconv: Rscsi: Cdrecord: - The man page now mentions that root-less operation is possible with Solaris fine grained privileges or Linux capabilties. - The man page now mentions the SCSI CAM standard for dev= Cdda2wav (Maintained/enhanced by Jörg Schilling, originated by Heiko Eißfeldt he...@he...): - cdda2wav: Comparison of function name with NULL replaced with comparison of function pointer with NULL. - cdda2wav: Do no longer initialize the sound card from the main process as pulseaudio does not follow UNIX rules for forked processes. - cdda2wav: Fixed a bug in the DMA residual computation for the C2 read functions where a wrong divisor (2353 instead of 2646) was used. - cdda2wav: Heiko tried to make audio output work on OpenBSD - cdda2wav: Heiko added code for pulseaudio support in Linux - cdda2wav: Fixed a typo ("KHz" -> "kHz") - cdda2wav: fixed a problem related to position differences between the CD extract part and the filesystemwrite part. - cdda2wav: We now include "c2check" in the paranoia mode "proof" again and fallback to a non-C2 mode in case the drive does not support C2checks. - The man page now mentions the SCSI CAM standard for dev= Readcd: - The man page now mentions the SCSI CAM standard for dev= Scgcheck: Scgskeleton: Btcflash: Mkisofs (Maintained/enhanced by Jörg Schilling since 1997, originated by Eric Youngdale): - mkisofs: HFS creation: fixed comparison of array with 0 to become comparison of array value with 0. 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-08-27 11:14:10
|
Jonatã Bolzan <jo...@jo...> wrote:
> According to chkudf tool (present on linux udf 0.9.0), it is possible
> that mkisofs is not generating compliant volumes. Please check this
> output:
This needs a lot of care to read, please give me some time.
I hope this is not a non-portable piece of software.
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: Jonatã B. <jo...@jo...> - 2015-08-24 20:48:22
|
According to chkudf tool (present on linux udf 0.9.0), it is possible
that mkisofs is not generating compliant volumes. Please check this
output:
--Determining device/media parameters.
ioctl error 1.
Guessing revealed 2048 byte sector size.
Last Sector = 131285 (0x200d5) and is not accurate
Adjusted last sector to 131283.
--Verifying the Volume Recognition Sequence.
VRS 0 (sector 16): ISO 9660 Primary Volume Descriptor
VRS 1 (sector 17): ISO 9660 Volume Descriptor Set Terminator
VRS 2 (sector 18): 2 ISO 9660 descriptors found.
VRS 2 : Beginning Extended Area descriptor found.
VRS 3 (sector 19): NSR02 descriptor found.
VRS 4 (sector 20): VRS sequence was terminated.
--Verifying the Anchor Volume Descriptor Pointers.
Checking 256: AVDP present.
Checking 512: No AVDP.
Checking 131283 (n - 0): AVDP present.
Checking 131133 (n - 150): No AVDP.
Checking 131027 (n - 256): No AVDP.
Checking 130877 (n - 406): No AVDP.
Found 2 Anchor Volume Descriptor Pointers.
Main Volume Descriptor Sequence is at 32, 32768 bytes long.
Reserve Volume Descriptor Sequence is at 48, 32768 bytes long.
--Verifying Volume Descriptor Sequences.
--Reading the Main Volume Descriptor Sequence.
Main VDS (00000020): Found first PVD.
Main VDS (00000021): Found first IUVD.
Main VDS (00000022): Found first PD.
Main VDS (00000023): Found first LVD.
Main VDS (00000024): Found first USD.
Main VDS (00000025): terminated by a Terminating Descriptor.
--Reading the Reserve Volume Descriptor Sequence.
Reserve VDS (00000030): Found first PVD.
Reserve VDS (00000031): Found first IUVD.
Reserve VDS (00000032): Found first PD.
Reserve VDS (00000033): Found first LVD.
Reserve VDS (00000034): Found first USD.
Reserve VDS (00000035): terminated by a Terminating Descriptor.
--Primary Volume Descriptor Information:
(M) Volume Identifier: 'dvd_pedrinho'
(M) Volume Set ID: '55D5E6BD000053F5'
**(R) Volume Set ID: '55D5E6BD0000545A'
(M) Recording Time: 2015/08/20 11:39:57.000000 (Local), -180 min. from CUT
(M) Primary Volume Descriptor number is 0.
**(M) Max. Interchange level is 2.
(M) App. ID: '' OS: 0,0 (Undefined)
(M) Impl. ID: '*mkisofs' OS: 0,0 (Undefined)
--Unallocated Volume Space Descriptor Information:
(M) Number of Allocation Descriptors: 0
--Logical Volume Descriptor Information:
(M) Logical Volume ID: 'dvd_pedrinho'
(M) Impl. ID: '*mkisofs' OS: 0,0 (Undefined)
(M) File Set Descriptor location is 4096 bytes @ 0:0
(M) There is 1 partition map entry.
(M) Partition map entry 0 is type 1 (real) and references partition 0.
(M) Integrity Sequence is 4096 bytes at 64.
Verifying the Logical Volume Integrity Descriptor Sequence.
LVID at 00000040: recorded at 2015/08/20 11:39:57.000000 (Local),
-180 min. from CUT
[Close]
3 directories, 6 files, highest UniqueID is 271.
Min read ver. 102, min write ver. 102, max write ver 102.
Recorded by: '*mkisofs' OS: 0,0 (Undefined)
Partition reference 0 has 0 of 130879 blocks available.
Length of Implementation use is 46.
End of LVID sequence.
--Partition Descriptor Information:
(M) Partition number 0.
(M) Partition flags: 0001 (Space Allocated)
(M) Impl. ID: '*mkisofs' OS: 0,0 (Undefined)
(M) Access Type Read Only.
(M) Partition starts at sector 257.
(M) Partition length is 130879 sectors.
--Implementation Use Volume Descriptor information:
(M) Impl. ID: '*UDF LV Info', UDF Ver.: 01.02 OS: 0,0 (Undefined)
(M) Logical Volume Identifier: 'dvd_pedrinho'
(M) Logical Volume Info 1: ''
(M) Logical Volume Info 2: ''
(M) Logical Volume Info 3: ''
(M) Impl. ID: '*mkisofs' OS: 0,0 (Undefined)
--Volume space report:
16 : 20 - Volume Recognition Sequence
32 : 47 - Main VDS (Front AVDP)
48 : 63 - Reserve VDS (Front AVDP)
64 : 65 - Integrity Sequence
256 : 256 - Front AVDP
257 : 131135 - A partition
131283 : 131283 - Back AVDP
--File Space report:
**[00000001] Expected Tag ID of 256, found 8.
Displaying directory hierarchy:
0000:00000002: \
[type=SHORT, ad_start=0x805bf70, ADlength=8, info_length=136]
[ad_offset=0, atype=0, loc=3, len=136, file_length=0] [file_length=136]
ICB 0:00002 offset 0
+0000:00000002: [parent] NAME OK parent location OK
ICB 0:00002 offset 28
+0000:00000004: 'AUDIO_TS'
[type=SHORT, ad_start=0x805bf04, ADlength=8, info_length=40]
[ad_offset=0, atype=0, loc=5, len=40, file_length=0]
[file_length=40] ( 40)
ICB 0:00004 offset 0
+0000:00000002: [parent] NAME OK parent location OK
ICB 0:00004 offset 28
++End of directory
ICB 0:00002 offset 58
+0000:00000006: 'VIDEO_TS'
[type=SHORT, ad_start=0x805bf04, ADlength=8, info_length=352]
[ad_offset=0, atype=0, loc=7, len=352, file_length=0]
[file_length=352] ( 352)
ICB 0:00006 offset 0
+0000:00000002: [parent] NAME OK parent location OK
ICB 0:00006 offset 28
-0000:00000008: 'VIDEO_TS.IFO'
[type=SHORT, ad_start=0x805bf24, ADlength=8, info_length=12288]
[ad_offset=0, atype=0, loc=21, len=12288, file_length=0]
[file_length=12288] ( 12288)
ICB 0:00006 offset 5c
-0000:00000009: 'VIDEO_TS.BUP'
[type=SHORT, ad_start=0x805bf24, ADlength=8, info_length=12288]
[ad_offset=0, atype=0, loc=47, len=12288, file_length=0]
[file_length=12288] ( 12288)
ICB 0:00006 offset 90
-0000:0000000a: 'VTS_01_0.BUP'
[type=SHORT, ad_start=0x805bf24, ADlength=8, info_length=20480]
[ad_offset=0, atype=0, loc=130868, len=20480, file_length=0]
[file_length=20480] ( 20480)
ICB 0:00006 offset c4
-0000:0000000b: 'VTS_01_0.IFO'
[type=SHORT, ad_start=0x805bf24, ADlength=8, info_length=20480]
[ad_offset=0, atype=0, loc=53, len=20480, file_length=0]
[file_length=20480] ( 20480)
ICB 0:00006 offset f8
-0000:0000000c: 'VTS_01_0.VOB'
[type=SHORT, ad_start=0x805bf24, ADlength=8, info_length=31948800]
[ad_offset=0, atype=0, loc=63, len=31948800, file_length=0]
[file_length=31948800] ( 31948800)
ICB 0:00006 offset 12c
-0000:0000000d: 'VTS_01_1.VOB'
[type=SHORT, ad_start=0x805bf24, ADlength=8, info_length=235939840]
[ad_offset=0, atype=0, loc=15663, len=235939840, file_length=0]
[file_length=235939840] ( 235939840)
ICB 0:00006 offset 160
++End of directory
ICB 0:00002 offset 88
++End of directory
--Testing link counts.
There are 3 directories and 6 files.
0 FIDs had a wrong location value.
--Checking Unique ID list.
The maximum Unique ID is 131125.
**The Integrity Descriptor indicated a maximum Unique ID of 270.
I can note that the following
**(R) Volume Set ID: '55D5E6BD0000545A'
does not appear with a compliant volume.
Thanks for your attention.
--
Jonatã Bolzan Loss
On Thu, Aug 20, 2015 at 11:40 AM, Joerg Schilling
<Joe...@fo...> wrote:
> Jonatã Bolzan <jo...@jo...> wrote:
>
>> > I am not sure, could you please repeat the description for that problem?
>>
>> "The ECMA specifications support the use of a Reserve Volume
>> Descriptor Sequence (Reserve VDS) as a backup to the Main Volume
>> Descriptor Sequence (Main VDS). When the Reserve VDS is recorded, it
>> must be equivalent to the Main VDS. This rule indicates that two
>> Volume Descriptor Sequences are not equivalent.
>>
>> Since the Reserve VDS is a backup to the Main VDS, technically this
>> should not cause any playability problems as long as the Reserve VDS
>> does not need to be used. However, since there are differences in the
>> interpretation of the file system specifications by different playback
>> systems, it is unknown if this problem will have any effect.
>>
>> Type: UDF
>> Reference: ECMA 167 3/28.4.23, BR-ROm UO0-057 & UO0-050"
>
> OK, didn't we finish with this discussion already?
>
> mkisofs creates such a backup VDS and I believe it does in a compliant way.
>
> 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-08-20 14:40:12
|
Jonatã Bolzan <jo...@jo...> wrote:
> > I am not sure, could you please repeat the description for that problem?
>
> "The ECMA specifications support the use of a Reserve Volume
> Descriptor Sequence (Reserve VDS) as a backup to the Main Volume
> Descriptor Sequence (Main VDS). When the Reserve VDS is recorded, it
> must be equivalent to the Main VDS. This rule indicates that two
> Volume Descriptor Sequences are not equivalent.
>
> Since the Reserve VDS is a backup to the Main VDS, technically this
> should not cause any playability problems as long as the Reserve VDS
> does not need to be used. However, since there are differences in the
> interpretation of the file system specifications by different playback
> systems, it is unknown if this problem will have any effect.
>
> Type: UDF
> Reference: ECMA 167 3/28.4.23, BR-ROm UO0-057 & UO0-050"
OK, didn't we finish with this discussion already?
mkisofs creates such a backup VDS and I believe it does in a compliant way.
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: Jonatã B. <jo...@jo...> - 2015-08-20 14:36:19
|
> I am not sure, could you please repeat the description for that problem? "The ECMA specifications support the use of a Reserve Volume Descriptor Sequence (Reserve VDS) as a backup to the Main Volume Descriptor Sequence (Main VDS). When the Reserve VDS is recorded, it must be equivalent to the Main VDS. This rule indicates that two Volume Descriptor Sequences are not equivalent. Since the Reserve VDS is a backup to the Main VDS, technically this should not cause any playability problems as long as the Reserve VDS does not need to be used. However, since there are differences in the interpretation of the file system specifications by different playback systems, it is unknown if this problem will have any effect. Type: UDF Reference: ECMA 167 3/28.4.23, BR-ROm UO0-057 & UO0-050" |
|
From: Joerg S. <Joe...@fo...> - 2015-08-20 14:31:26
|
Jonatã Bolzan <jo...@jo...> wrote:
> >> did you find out the numbers?
>
> >> Did you try to contact the author of the mastering program?
>
> I contacted the developers of dvdauthor and they provided a patch that
> solves the IFO - BUP problem. Do you think that the first error I am
> looking for ( Volume Descriptor Sequences are not equivalent ) is
> related?
I am not sure, could you please repeat the description for that 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: Jonatã B. <jo...@jo...> - 2015-08-20 13:56:54
|
>> did you find out the numbers? >> Did you try to contact the author of the mastering program? I contacted the developers of dvdauthor and they provided a patch that solves the IFO - BUP problem. Do you think that the first error I am looking for ( Volume Descriptor Sequences are not equivalent ) is related? Thanks for your attention. |
|
From: Jonatã B. <jo...@jo...> - 2015-07-30 16:41:53
|
> did you find out the numbers? Here is the verbose output of mkisofs: Scanning dvd Scanning dvd/AUDIO_TS Scanning dvd/VIDEO_TS Writing: Initial Padblock Start Block 0 Done with: Initial Padblock Block(s) 16 Writing: Primary Volume Descriptor Start Block 16 Done with: Primary Volume Descriptor Block(s) 1 Writing: End Volume Descriptor Start Block 17 Done with: End Volume Descriptor Block(s) 1 Writing: UDF volume recognition area Start Block 18 Done with: UDF volume recognition area Block(s) 3 Writing: Version block Start Block 21 Done with: Version block Block(s) 1 Writing: UDF pad to sector 32 Start Block 22 Done with: UDF pad to sector 32 Block(s) 10 Writing: UDF main seq Start Block 32 Done with: UDF main seq Block(s) 16 Writing: UDF second seq Start Block 48 Done with: UDF second seq Block(s) 16 Writing: UDF integ seq Start Block 64 Done with: UDF integ seq Block(s) 2 Writing: UDF pad to sector 256 Start Block 66 Done with: UDF pad to sector 256 Block(s) 190 Writing: UDF Anchor volume Start Block 256 Done with: UDF Anchor volume Block(s) 1 Writing: UDF file set Start Block 257 Done with: UDF file set Block(s) 2 Writing: UDF directory tree Start Block 259 Done with: UDF directory tree Block(s) 6 Writing: UDF file entries Start Block 265 Done with: UDF file entries Block(s) 6 Writing: Path table Start Block 271 Done with: Path table Block(s) 4 Writing: Directory tree Start Block 275 Done with: Directory tree Block(s) 3 Writing: Directory tree cleanup Start Block 278 Done with: Directory tree cleanup Block(s) 0 Writing: The File(s) Start Block 278 3.81% done, estimate finish Thu Jul 30 13:16:34 2015 7.64% done, estimate finish Thu Jul 30 13:15:41 2015 11.44% done, estimate finish Thu Jul 30 13:15:32 2015 15.26% done, estimate finish Thu Jul 30 13:15:21 2015 19.06% done, estimate finish Thu Jul 30 13:15:15 2015 22.86% done, estimate finish Thu Jul 30 13:15:11 2015 26.67% done, estimate finish Thu Jul 30 13:15:08 2015 30.49% done, estimate finish Thu Jul 30 13:15:05 2015 34.30% done, estimate finish Thu Jul 30 13:15:03 2015 38.10% done, estimate finish Thu Jul 30 13:14:59 2015 41.90% done, estimate finish Thu Jul 30 13:14:58 2015 45.73% done, estimate finish Thu Jul 30 13:14:57 2015 49.53% done, estimate finish Thu Jul 30 13:14:57 2015 53.34% done, estimate finish Thu Jul 30 13:14:54 2015 57.14% done, estimate finish Thu Jul 30 13:14:54 2015 60.97% done, estimate finish Thu Jul 30 13:14:54 2015 64.77% done, estimate finish Thu Jul 30 13:14:52 2015 68.57% done, estimate finish Thu Jul 30 13:14:52 2015 72.38% done, estimate finish Thu Jul 30 13:14:52 2015 76.20% done, estimate finish Thu Jul 30 13:14:50 2015 80.01% done, estimate finish Thu Jul 30 13:14:50 2015 83.81% done, estimate finish Thu Jul 30 13:14:50 2015 87.61% done, estimate finish Thu Jul 30 13:14:49 2015 91.44% done, estimate finish Thu Jul 30 13:14:49 2015 95.24% done, estimate finish Thu Jul 30 13:14:49 2015 99.04% done, estimate finish Thu Jul 30 13:14:49 2015 Total translation table size: 0 Total rockridge attributes bytes: 0 Total directory bytes: 4096 Path table size(bytes): 42 Done with: The File(s) Block(s) 130837 Writing: UDF Anchor end volume Start Block 131115 Done with: UDF Anchor end volume Block(s) 1 Writing: UDF Pad end Start Block 131116 Done with: UDF Pad end Block(s) 150 Max brk space used 0 131266 extents written (256 MB) > Regarding the CD data, here is what I get: > > the IFO file is extremely small and usually IFO is big enough to have IFO and > BUP in differen 32k blocks. > > As you can see from my hand crafted hints, there does not seem to be any > padding in the data. So if you would like to have padding between IFO and BUP, > it seems that you first need to tell your Video mastering program to insert the > required padding into IFO information to have space for moving the BUP file. > > Did you try to contact the author of the mastering program? Yes, it seems that they does not understand what I am talking about. I will try to explain better. You can check the answer here: http://sourceforge.net/p/dvdauthor/mailman/message/34326721/ that continues here: http://sourceforge.net/p/dvdauthor/mailman/message/34332795/ Thanks for your attention. |
|
From: Joerg S. <Joe...@fo...> - 2015-07-15 12:55:51
|
Jonatã Bolzan <jo...@jo...> wrote: > On Tue, Jul 14, 2015 at 2:01 PM, Joerg Schilling > <Joe...@fo...> wrote: > > I would need all data to understand the structure. This may be the whole disk, > > at least the file names, the file sizes and the content of the IFO file, as the > > IFO file is what the DVD players understand. > > The test image file I sent to replication is the following: > > http://jonata.org/ddp_TEST.zip > > I will check with -v and return back what I find. Hi, did you find out the numbers? Regarding the CD data, here is what I get: the IFO file is extremely small and usually IFO is big enough to have IFO and BUP in differen 32k blocks. As you can see from my hand crafted hints, there does not seem to be any padding in the data. So if you would like to have padding between IFO and BUP, it seems that you first need to tell your Video mastering program to insert the required padding into IFO information to have space for moving the BUP file. Did you try to contact the author of the mastering program? isoinfo -i MAIN.DAT -l Setting input-charset to 'ISO8859-1' from locale. Directory listing of / 275 dr-xr-xr-x 1 0 0 2048 Jul 10 2015 [ 275 02] . 275 dr-xr-xr-x 1 0 0 2048 Jul 10 2015 [ 275 02] .. 276 dr-xr-xr-x 1 0 0 2048 Jul 10 2015 [ 276 02] AUDIO_TS 277 dr-xr-xr-x 1 0 0 2048 Jul 10 2015 [ 277 02] VIDEO_TS Directory listing of /AUDIO_TS/ 276 dr-xr-xr-x 1 0 0 2048 Jul 10 2015 [ 276 02] . 275 dr-xr-xr-x 1 0 0 2048 Jul 10 2015 [ 275 02] .. Directory listing of /VIDEO_TS/ 277 dr-xr-xr-x 1 0 0 2048 Jul 10 2015 [ 277 02] . 275 dr-xr-xr-x 1 0 0 2048 Jul 10 2015 [ 275 02] .. 284 -r-xr-xr-x 1 0 0 12288 Jul 10 2015 [ 284 00] VIDEO_TS.BUP;1 278 -r-xr-xr-x 1 0 0 12288 Jul 10 2015 [ 278 00] VIDEO_TS.IFO;1 131105 -r-xr-xr-x 1 0 0 20480 Jul 10 2015 [ 131105 00] VTS_01_0.BUP;1 290 -r-xr-xr-x 1 0 0 20480 Jul 10 2015 [ 290 00] VTS_01_0.IFO;1 300 -r-xr-xr-x 1 0 0 31948800 Jul 10 2015 [ 300 00] VTS_01_0.VOB;1 15900 -r-xr-xr-x 1 0 0 235939840 Jul 10 2015 [ 15900 00] VTS_01_1.VOB;1 isoinfo -i MAIN.DAT -ls Setting input-charset to 'ISO8859-1' from locale. Directory listing of / 275 dr-xr-xr-x 1 0 0 1 Jul 10 2015 [ 275 02] . 275 dr-xr-xr-x 1 0 0 1 Jul 10 2015 [ 275 02] .. 276 dr-xr-xr-x 1 0 0 1 Jul 10 2015 [ 276 02] AUDIO_TS 277 dr-xr-xr-x 1 0 0 1 Jul 10 2015 [ 277 02] VIDEO_TS Directory listing of /AUDIO_TS/ 276 dr-xr-xr-x 1 0 0 1 Jul 10 2015 [ 276 02] . 275 dr-xr-xr-x 1 0 0 1 Jul 10 2015 [ 275 02] .. Directory listing of /VIDEO_TS/ 277 dr-xr-xr-x 1 0 0 1 Jul 10 2015 [ 277 02] . 275 dr-xr-xr-x 1 0 0 1 Jul 10 2015 [ 275 02] .. 284 -r-xr-xr-x 1 0 0 6 Jul 10 2015 [ 284 00] VIDEO_TS.BUP;1 Ends before sector 290 278 -r-xr-xr-x 1 0 0 6 Jul 10 2015 [ 278 00] VIDEO_TS.IFO;1 Ends before sector 284 131105 -r-xr-xr-x 1 0 0 10 Jul 10 2015 [ 131105 00] VTS_01_0.BUP;1 290 -r-xr-xr-x 1 0 0 10 Jul 10 2015 [ 290 00] VTS_01_0.IFO;1 Ends before sector 300 300 -r-xr-xr-x 1 0 0 15600 Jul 10 2015 [ 300 00] VTS_01_0.VOB;1 Ends before sector 1590 15900 -r-xr-xr-x 1 0 0 115205 Jul 10 2015 [ 15900 00] VTS_01_1.VOB;1 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: Jonatã B. <jo...@jo...> - 2015-07-14 19:22:58
|
On Tue, Jul 14, 2015 at 2:01 PM, Joerg Schilling <Joe...@fo...> wrote: > I would need all data to understand the structure. This may be the whole disk, > at least the file names, the file sizes and the content of the IFO file, as the > IFO file is what the DVD players understand. The test image file I sent to replication is the following: http://jonata.org/ddp_TEST.zip I will check with -v and return back what I find. |
|
From: Joerg S. <Joe...@fo...> - 2015-07-14 17:01:48
|
Jonatã Bolzan <jo...@jo...> wrote: > I tried to understand following some information about the UDF > specification. What I understand is that this is a kind of data that > is duplicated as "Primary" and "Supplementary". The real description > of the error that I received is the following: > > "The ECMA specifications support the use of a Reserve Volume > Descriptor Sequence (Reserve VDS) as a backup to the Main Volume > Descriptor Sequence (Main VDS). When the Reserve VDS is recorded, it > must be equivalent to the Main VDS. This rule indicates that two > Volume Descriptor Sequences are not equivalent. > > Since the Reserve VDS is a backup to the Main VDS, technically this > should not cause any playability problems as long as the Reserve VDS > does not need to be used. However, since there are differences in the > interpretation of the file system specifications by different playback > systems, it is unknown if this problem will have any effect. > > Type: UDF > Reference: ECMA 167 3/28.4.23, BR-ROm UO0-057 & UO0-050" I recomend to use mkisofs -v. The main sequence is called: "UDF main seq" typically written at sector 32 The copy sequence is called: "UDF second seq" typically written at sector 48. > "The DVD-Video specifications require that the Video Manager Information > file (VIDEO_TS.IFO) and its backup (VIDEO_TS.BUP) NOT be recorded in > the same ECC block. > > Background > For redundancy purposes, the DVD-Video specifications require a backup > file for the Video Manager Information file. If this file should > become corrupt, a DVD-Player can locate the backup file and use it > instead. If the two files overlap within the same ECC Block, it is > possible that if the ECC fails, it will cause both files to be > unreadable. > > Possible Cause > This problem is caused by the authoring system that created the image. > It is the responsibility of the authoring system to ensure that these > files do not overlap within the same ECC Block. > > Possible Solution > This problem can only be corrected by an authoring system." > > So, I search about this. IFO and BUP can not be on the same ECC > sector, that is 32k large (16 x 2048). The behaviour is described > here: I would need all data to understand the structure. This may be the whole disk, at least the file names, the file sizes and the content of the IFO file, as the IFO file is what the DVD players understand. > > If you do not set a volume descriptor, how should mkisofs know? > > Did you read the man page? > > Yes, I read ALL mkisofs man as version 3.01a30 and did not find how to > "set a volume descriptor". The only option related with volume > descriptor is the -iso-level option. The options should allow to find the volume ID.... > > > According to the mkisofs man, and it seems that there is the option > > > "-iso-level" that is related to the volume descriptor. > > > > > > My questions: could you explain me something about what the errors are > > > related with? It is possible that the option "-iso-level 4" solve this > > > issues? If this is some bug in mkisofs, could I help with some test? > > > > Iso "level 4" is a method in mkisofs to tell that the ISO-9660 filesystem part > > should be ISO-9660:1999, see man page. > > Yes, I know that, but you think that this option would help me with > the lack of 'Volume Descriptor Sequences equivalence'? > > According to this information: > > https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=194233 > > would the -iso-level 4 "force" the supplementary volume descriptor? This is related to ISO-9660 but not to UDF. Also note that a DVD video player does not understand UDF at all, but instead searches for the IFO file using pattern matching. The IFO file contains the structuring information and mkisofs is required to follow the block addresses mentioned in that file. This why it adds padding... 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: Jonatã B. <jo...@jo...> - 2015-07-14 16:17:31
|
On Tue, Jul 14, 2015 at 6:07 AM, Joerg Schilling <Joe...@fo...> wrote: > > Jonatã Bolzan <jo...@jo...> wrote: > > > - Volume Descriptor Sequences are not equivalent > > Could you explain whyt you understand by this text? > Without understanding your problem, I don't know how to help. I tried to understand following some information about the UDF specification. What I understand is that this is a kind of data that is duplicated as "Primary" and "Supplementary". The real description of the error that I received is the following: "The ECMA specifications support the use of a Reserve Volume Descriptor Sequence (Reserve VDS) as a backup to the Main Volume Descriptor Sequence (Main VDS). When the Reserve VDS is recorded, it must be equivalent to the Main VDS. This rule indicates that two Volume Descriptor Sequences are not equivalent. Since the Reserve VDS is a backup to the Main VDS, technically this should not cause any playability problems as long as the Reserve VDS does not need to be used. However, since there are differences in the interpretation of the file system specifications by different playback systems, it is unknown if this problem will have any effect. Type: UDF Reference: ECMA 167 3/28.4.23, BR-ROm UO0-057 & UO0-050" > > - Video Manager IFO and BUP files in same ECC block > > See above, this seems to be a very vague description and even if I did know > what "in same ECC block" could mean, this still does not clearly explain > whether this is expected or should be avoided. > > Also note: UDF does not have ECC blocks... > > > Well, there is not so much information on the internet about this specific > > errors. What I can understand is that they are both related with the UDF > > specification. > > The second is definitely not related to the UDF specification as this is at > file level and thus content related but not UDF structure related. You are right, my fault. It is not related with UDF. The error description is the following: "The DVD-Video specifications require that the Video Manager Information file (VIDEO_TS.IFO) and its backup (VIDEO_TS.BUP) NOT be recorded in the same ECC block. Background For redundancy purposes, the DVD-Video specifications require a backup file for the Video Manager Information file. If this file should become corrupt, a DVD-Player can locate the backup file and use it instead. If the two files overlap within the same ECC Block, it is possible that if the ECC fails, it will cause both files to be unreadable. Possible Cause This problem is caused by the authoring system that created the image. It is the responsibility of the authoring system to ensure that these files do not overlap within the same ECC Block. Possible Solution This problem can only be corrected by an authoring system." So, I search about this. IFO and BUP can not be on the same ECC sector, that is 32k large (16 x 2048). The behaviour is described here: http://club.myce.com/f62/video_ts-ifo-video_ts-bup-same-ecc-block-98278/#post621399 I read the mkisofs man and it says that mkisofs with -dvd-video will fill needed gaps. But in the case of an "empty" menu, or a VOB that is so little that the sum of IFO + VOB is less than 32K, mkisofs will not take action. In fact, this is an issue with some version of Nero too: http://download.videohelp.com/r0lZ/pgcedit/third_party/blutach/Burning%20With%20PgcEdit.htm At the same time, it seems that this kind of issue was already discussed: http://osdir.com/ml/audio.cd-record/2002-12/msg00015.html So, I think I can fix this in my case, but would not be good to have this feature on mkisofs (verify IFO + VOB length and fill it)? > > The command I am using to generate the ISO is something like this: > > > > mkisofs -dvd-video -udf -o movie.iso 'dvd' > > If you do not set a volume descriptor, how should mkisofs know? > Did you read the man page? Yes, I read ALL mkisofs man as version 3.01a30 and did not find how to "set a volume descriptor". The only option related with volume descriptor is the -iso-level option. > > According to the mkisofs man, and it seems that there is the option > > "-iso-level" that is related to the volume descriptor. > > > > My questions: could you explain me something about what the errors are > > related with? It is possible that the option "-iso-level 4" solve this > > issues? If this is some bug in mkisofs, could I help with some test? > > Iso "level 4" is a method in mkisofs to tell that the ISO-9660 filesystem part > should be ISO-9660:1999, see man page. Yes, I know that, but you think that this option would help me with the lack of 'Volume Descriptor Sequences equivalence'? According to this information: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=194233 would the -iso-level 4 "force" the supplementary volume descriptor? Thanks for your attention! |
|
From: Joerg S. <Joe...@fo...> - 2015-07-14 09:07:57
|
Jonatã Bolzan <jo...@jo...> wrote:
> Hi there!
>
> We are using mkisofs to generate ISO files in our DVD authoring tool. The
> generated images are OK for "in-house" duplication, but we would like to
> send it to a replication company. They pointed out that there are some
> errors in our ISO files:
>
> - Volume Descriptor Sequences are not equivalent
Could you explain whyt you understand by this text?
Without understanding your problem, I don't know how to help.
> - Video Manager IFO and BUP files in same ECC block
See above, this seems to be a very vague description and even if I did know
what "in same ECC block" could mean, this still does not clearly explain
whether this is expected or should be avoided.
Also note: UDF does not have ECC blocks...
> Well, there is not so much information on the internet about this specific
> errors. What I can understand is that they are both related with the UDF
> specification.
The second is definitely not related to the UDF specification as this is at
file level and thus content related but not UDF structure related.
> The command I am using to generate the ISO is something like this:
>
> mkisofs -dvd-video -udf -o movie.iso 'dvd'
If you do not set a volume descriptor, how should mkisofs know?
Did you read the man page?
> According to the mkisofs man, and it seems that there is the option
> "-iso-level" that is related to the volume descriptor.
>
> My questions: could you explain me something about what the errors are
> related with? It is possible that the option "-iso-level 4" solve this
> issues? If this is some bug in mkisofs, could I help with some test?
Iso "level 4" is a method in mkisofs to tell that the ISO-9660 filesystem part
should be ISO-9660:1999, see man page.
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: Jonatã B. <jo...@jo...> - 2015-07-13 23:53:58
|
Hi there! We are using mkisofs to generate ISO files in our DVD authoring tool. The generated images are OK for "in-house" duplication, but we would like to send it to a replication company. They pointed out that there are some errors in our ISO files: - Volume Descriptor Sequences are not equivalent - Video Manager IFO and BUP files in same ECC block Well, there is not so much information on the internet about this specific errors. What I can understand is that they are both related with the UDF specification. The command I am using to generate the ISO is something like this: mkisofs -dvd-video -udf -o movie.iso 'dvd' According to the mkisofs man, and it seems that there is the option "-iso-level" that is related to the volume descriptor. My questions: could you explain me something about what the errors are related with? It is possible that the option "-iso-level 4" solve this issues? If this is some bug in mkisofs, could I help with some test? Thanks for your attention. -- Jonatã Bolzan Loss |
|
From: Joerg S. <Joe...@fo...> - 2015-01-21 11:25:05
|
Jim Michaels <jmi...@ya...> wrote:
> I mean by original ISO the ISO I burned the disc with (which I wish to later verify the burned disc against).
Sorry, your explanation still does not explain what you like to do.
There is currently no userspace implementation for a UDF filesystem reader, so
accessing the files logically requires the OS to support understanding the FS
image.
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-01-21 11:23:22
|
Jim Michaels <jmi...@ya...> wrote: > I am on windows, there isn't such a command (but there is an API for that via COM+ or .Net possibly). I had asked, because if ISO-disc verification were available via a command (readcd?), then this would be a more cross-platform solution and the GUI would not have to implement a platform-specific version of this. I had thought it should be in the burning tools command set (?). > I noticed readcd gives different sized ISO files for the same disc depending on options, so I wasn't sure exactly how to use it best to do a verification, if that were currently the tool to use. if it is, an example command would be most helpful in the documentation. Please first register as a member of this list at: https://lists.sourceforge.net/lists/listinfo/cdrtools-developers to make discussions easier. Star of course exists for Win-DOS as well, just get the source and compile. Readcd contains a disk verification, but this verification is of course limited to it's main purpose and for this reason readcd just verifies the readability of the medium. Star is able to do a file system comparison on top of the OS filesystem layer. Isoinfo could extract all files for you without using the filesystem layer of your os, but this currently only works for the ISO-9660 part and foor the Rock-Ridge and the Joliet part. There is a plan to implement UDF support in isoinfo, but this did not yet happen. BTW: I received sample filesystem images for this problem and I see no reason why your OS should give a read error for the file from the old session, as the starting block number is in the valid range. The content of the file however is expected to be wrong due to the wrong block address in the UDF directory content. This wrong block address is a bit srange as the UDF formatter gets the same data as the ISO-9660 formatter that writes the correct block numbers in your case. 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: Jim M. <jmi...@ya...> - 2015-01-21 00:22:42
|
I mean by original ISO the ISO I burned the disc with (which I wish to later verify the burned disc against). ------------- Jim Michaels Jmi...@ya... Ji...@Re... http://RenewalComputerServices.com http://JesusnJim.com (computer repair info, programming) From: Joerg Schilling <Joe...@fo...> To: jmi...@ya...; cdr...@li... Sent: Tuesday, January 20, 2015 2:35 AM Subject: Re: [Cdrtools-developers] Fw: more details for bug report regarding -udf, -UDF in mkisofs Jim Michaels <jmi...@ya...> wrote: > how would verification/comparison to an original ISO be performed?thanks. What do you understand by "an original ISO"? 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: Jim M. <jmi...@ya...> - 2015-01-21 00:19:29
|
I am on windows, there isn't such a command (but there is an API for that via COM+ or .Net possibly). I had asked, because if ISO-disc verification were available via a command (readcd?), then this would be a more cross-platform solution and the GUI would not have to implement a platform-specific version of this. I had thought it should be in the burning tools command set (?). I noticed readcd gives different sized ISO files for the same disc depending on options, so I wasn't sure exactly how to use it best to do a verification, if that were currently the tool to use. if it is, an example command would be most helpful in the documentation. thanks. ------------- Jim Michaels Jmi...@ya... Ji...@Re... http://RenewalComputerServices.com http://JesusnJim.com (computer repair info, programming) From: Joerg Schilling <Joe...@fo...> To: jmi...@ya...; cdr...@li... Sent: Tuesday, January 20, 2015 2:33 AM Subject: Re: [Cdrtools-developers] Fw: more details for bug report regarding -udf, -UDF in mkisofs Jim Michaels <jmi...@ya...> wrote: > GUI cd burning programs have a checkbox to verify what you have written to disk to make sure it got written correctly (to make sure you don't just have made a coaster).this is what I mean by verify. for whatever reason, be it due to a program bug that the data could be written to the disk correctly, reading the data back from the disc after writing (possible need for ejection and pulling back in?) may be something the user wants. at times I have needed this, because I have not always gotten correct results. although there is no switch for this. the GUI program I have been using provides it somehow. If you like this to be in your GUI, I recommend that you send a request to the authors of your favorite GUI. If you like to do this on the commandline, you should know that UNIX offers you a toolbox of many programs that are able to do the work for you. Star -diff is e.g. something that allows you to check file content and metadata. But note that in case there are differences, this may be caused by the OS you are using. Linux e.g. did evaluate the timezones with the wrong sign in the 1990s and as a result, it looked as if the timestamps are wrong. 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-01-20 10:35:56
|
Jim Michaels <jmi...@ya...> wrote:
> how would verification/comparison to an original ISO be performed?thanks.
What do you understand by "an original ISO"?
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-01-20 10:33:45
|
Jim Michaels <jmi...@ya...> wrote:
> GUI cd burning programs have a checkbox to verify what you have written to disk to make sure it got written correctly (to make sure you don't just have made a coaster).this is what I mean by verify. for whatever reason, be it due to a program bug that the data could be written to the disk correctly, reading the data back from the disc after writing (possible need for ejection and pulling back in?) may be something the user wants. at times I have needed this, because I have not always gotten correct results. although there is no switch for this. the GUI program I have been using provides it somehow.
If you like this to be in your GUI, I recommend that you send a request to the
authors of your favorite GUI.
If you like to do this on the commandline, you should know that UNIX offers you
a toolbox of many programs that are able to do the work for you. Star -diff is
e.g. something that allows you to check file content and metadata.
But note that in case there are differences, this may be caused by the OS you
are using. Linux e.g. did evaluate the timezones with the wrong sign in the
1990s and as a result, it looked as if the timestamps are wrong.
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/'
|
