Jonatã Bolzan <jon...@jonata.org> 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...@schily.net                    (home) Jörg Schilling D-13353 Berlin
       joerg.schill...@fokus.fraunhofer.de (work) Blog: 
http://schily.blogspot.com/
 URL:  http://cdrecord.org/private/ 
http://sourceforge.net/projects/schilytools/files/'

------------------------------------------------------------------------------
Don't Limit Your Business. Reach for the Cloud.
GigeNET's Cloud Solutions provide you with the tools and support that
you need to offload your IT needs and focus on growing your business.
Configured For All Businesses. Start Your Cloud Today.
https://www.gigenetcloud.com/
_______________________________________________
Cdrtools-developers mailing list
Cdrtools-developers@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/cdrtools-developers

Reply via email to