[Libcdio-devel] Fuzzy iso9660 search

[R. Bernstein]

Here's the latest hack that's I find interesting and yet again want
open it up to the community for discussion. 

A little background first. Skip to >>>THE HACK<< for those of you who are
interested in ISO 9660 filesystems but not VCD's 

One of the hacks in Mplayer that sometimes is useful is the ability to
play a VCD disk image using the ".bin" file part of a CDRWin .cue/.bin
or a cdrdao .toc/.bin *without* having the cuesheet (CUE or TOC
part). In fact Mplayer *doesn't* know how to read cuesheets! So this
means that a subtlety like where the different tracks lie (and
therefore the ability to navigate tracks) is lost.

What Mplayer I think is doing is looking for a MPEG header and just
playing from there. So mplayer gets a bit confused if one has any sort
of still frame or sequences, or a change in aspect ratio in the first
ISO-9660 track. (Just tried it...yep.)

But if this playing a .bin (or more precisely track data) without the
cuesheet works often, it means that the majority of VCD's don't have
menus, still frames or sequences in the first track, and have a single
MPEG track (track 2) or folks aren't annoyed by treating the CD image
as having only one.

In contrast, the xine VCD plugin *does* read the cue and toc part
(with some bugs for toc), and handles the full still/navigation
capabilities, sees the multiple tracks and so on.

One last thing in this regard, I note is that vcd-info (or the earlier
program vcddebug) and perhaps vcdxrip used to have options for setting
sector size (2336 or 2352) and reading a bin file. These were removed
because of the flakiness in getting the information right. Nowadays
when you give a bin, the programs look for a corresponding cue or toc
and use that. If you don't have that, no dice.

But I've been thinking might there not be a better, more reliable way
to reconstruct the cuesheet rather than scan for an MPEG header?
Especially for a VCD which has VCD meta information in the first
ISO-9600 track? Okay, that leads us to...

>>>THE HACK<<

In libcdio on my local disk, I've be added this fuzzy IS0-9600 search
within a certain range. Basically code looks for The ISO 9660 marker
"CD001" and set the byte before that as frame 16, the Primary Volume
Descriptor marker. If the other data works out, e.g. the byte before
is 1 (PVD) and whatever checks we have for PVD-ness, then the rest
might be used to get ISO 9660 information in the CD image whether
CDRWIN, cdrdao, NRG or some other image formats that we don't even
begin to know about (Alcohol?) provided the way the format works is
that once one finds the track data portion the bytes are laid out on
disk as they would be on CD. Given the way burning works for DAO (and
to a lesser extent TAO), I suspect this will often be the case. It is
pretty much true for the 3 image formats libcdio knows about.

With me so far? Now for (S)VCD's I think one can pretty much
reconstruct a cdrdao TOC or a CUE from the first ISO-9660 track. Okay,
maybe not some track flags (linear precomp, disable copy) or a
multisession CD or a CD tracks outside of the VCD range, but if you
are interested in VCD's anyway and this would pretty *reliably* get
the information. 

But it could turn out to be useful in outside VCD's. For example Data
CD's. I may add a program to VCDImager to reconstruct the TOC/CUE
and/or a program in libcdio data CDs.

As always happens in such circumstance, I have a hard time predicting
what the right user API is a priori. (Which means flakiness in the API
which I know has caused some aggravation when it changes.)

Right now, I've added only a single parameter, the frame range in
which to search onto the iso_ifs_open() routines. It might be
desirable to have a kind of open where one sets the framesize (again
probably either 2048, 2336 or 2352) and an initial offset
correction. I don't know. For now, I'll leave out but If I come across
the need or there are applications which need this it can be easily
added.