Re: [Bug-xorriso] libisofs: unsupported ECMA-119 feature (interleaved mode)

[Thomas Schmitt]

Hi,

Jonathan Dowland wrote:
> > libisofs: FAILURE : Unsupported image. This image has at least one file
> > recorded in interleaved mode. We do not support this mode, as we think it
> > is not used. If you are reading this, then we are wrong :) Please contact
> > libisofs developers, so we can fix this.
> > libisofs: SORRY : Can't open dir /HMT/RD 2009/My Settings/Application
> > Data/Microsoft/Speech
> > libisofs: NOTE :  Caused by: Unsupported ECMA-119 feature

Thanks for reporting.

The trigger for these messages is in the directory record (kindof inode)
which governs the given file "Speech". Two fields "File Unit Size" and
"Interleave Gap Size" are supposed to be 0 unless the file is stored in
"Interleaved mode".
One of them must be non-zero to trigger above messages.

"Interleaved mode" mode is described in ECMA-119 in quite obscure terms.
There are "File units" of several consecutive blocks with are separated
by gaps of several consecutive blocks. The reasons for the gaps are not
told. The byte content of the file consists of the File units without gaps.
Shrug.

It would be interesting to see an example. But:

> libisoburn: WARNING : ISO image size 4116835s larger than readable size
> 3151696s

There is a chance that the file content is in the missing 2 GB
(1s[ector] = 2048 bytes).

The command
> -find . -exec report_lba
could tell, if the directory record had been read in as IsoNode object
of libisofs. But the error message tells that it wasn't.

So even if you are willing to send me the whole image of 6 GB, it is
questionable whether i will learn anything from it. (If you give me an URL
i will download it, just for curiosity.)


> DVD-R DL

Those are rare. DVD+R DL are more often to see. But also not very reliable
to my experience.


> This happened
> for another DVD-R DL too, so I am suspicious as to what's going on around
> the layer change when I read it.

libburn reports to libisoburn a readable image size of about 75% of what
the ISO Primary Volume Descriptor tells as filesystem size. So this does not
coincide with a plausible layer limit.
(Further DVD-R DL offers "Layer Jump recording" where the layer jumps
 happen forth and back during recording. So we can only guess where the
 bad spot is.)

-------------------------------------------------------------------------

> roughly the first half of the disc read in OK by ddrescue,

I dare to state that xorriso command -check_media is a sincere competitor
to ddrescue:

  xorriso -outdev /dev/sr0 \
          -check_media \
             use=outdev \
             what=disc \
             time_limit=7200 \
             abort_file=/tmp/stop_check_media \
             data_to="$HOME"/sr0_image.iso \
             sector_map="$HOME"/sr0_image.map \
             --

This will copy readable blocks to their proper position in file
  "$HOME"/sr0_image.iso
and record the successfuly retrieved blocks in file
  "$HOME"/sr0_image.map
The run will last at most 7200 seconds or until you touch file
  /tmp/stop_check_media
Opening by -outdev will omit the attempt to interpret the problematic
filesystem metadata.

The run can be repeated with the same arguments in order to have another
two hours of attempts on yet unretrieved blocks.
(The pacifier messages of follow-up runs are misleading by telling
 the full media size without subtracting the already retrieved blocks.)

Final messages will tell about overall success. E.g. after a first run:

  Media checks :        lba ,       size , quality
  Media region :          0 ,      68576 , + good
  Media region :      68576 ,    2226528 , 0 untested

and after a second run which was allowed to end:

  Media checks :        lba ,       size , quality
  Media region :          0 ,      68576 , + valid
  Media region :      68576 ,         32 , + slow
  Media region :      68608 ,    2226496 , + good

(This was a DVD+RW of 4.7 GB.)

-------------------------------------------------------------------------

Have a nice day :)

Thomas