libcdio-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Libcdio-devel] Hindsight is 2020 - Let's sort multiextents at last


From: Rocky Bernstein
Subject: Re: [Libcdio-devel] Hindsight is 2020 - Let's sort multiextents at last
Date: Sun, 24 May 2020 12:00:30 -0400

On Sun, May 24, 2020 at 9:36 AM Thomas Schmitt <address@hidden> wrote:

> Hi,
>
> branch pragmatic-multiextent-2020 has now passed all my experiments
> which master would pass.
> Insofar i propose to merge it.
>

Merge it then, unless anyone objects.

It is good to see the long-standing problems (eventually) get fixed.

As a way of explanation for why things are the way they are. This was
originally a Video CD library (VCD), and nothing more embedded in
VCDImager. Herbert Valerio Riedel coded in the VCD and CD-ROM specs and
felt very strongly about any violation to the standards.

But that was then and this is now.  I doubt that any significant use of
this code is for VCDs nowadays.




>
> -----------------------------------------------------------------------
>
> There is a substantial problem with the size assessment of DVD and BD
> media, though. A fully fomatted DVD+RW of 2,295,104 blocks gets assessed
> as having only 431,849 blocks (and MSF being 95:59:74).
> The macro check_lsn in lib/driver/read.c then prevents reading of any
> block beyond that wrong small size.
>
> Since large.iso is a multi-session ISO, its root directory lies above
> the wrong size and src/cd-info reports no ISO directory tree but also no
> error message.
> (The lack of error message is caused by check_lsn only issuing a cdio_info
>  message which src/cd-info does not show. src/cd-info itself tries to
>  issue an error message on failure of iso9660_fs_readdir() by a call
>  named report(). It does not show up.)
>
> I assume that the size misperception comes from use of MSF oriented
> inquiries or conversions which are inapproriate with block counts in
> the millions.
>
> I will try to find out where it goes wrong with gnu_linux.c.
> Depending on the results, this issue might need fixing in each of the
> operating system drivers.
>

Onward and upward.

As for fixing the various drivers. Fix what you can and leave the rest for
someone else.

The commented out code in MinGW was probably put there by me. But since I
didn't have the means to test it remained commented.
Until recently when it appears to have been desired.



>
>
> Have a nice day :)
>
> Thomas
>
>
>


reply via email to

[Prev in Thread] Current Thread [Next in Thread]