[MPlayer-users] Re: Re: OGG/OGM on XCD/MODE2 CDs

[de_xt]

Hi there. Why headaches, it's just a backup file written in Form1 which the
XCD reader uses in order to recover the most sensible parts in case of a
read error. Under Windows this is done in a transparent manner, because it's
the XCD DSF the one which does this. It would require special support from
mplayer if you want to take advantage of it, but the format for the backup
file is pretty simple.

It's up to the backup creator how much to backup from each file. It could
specifically support a series of formats (such as OGM), scan it and just
save the most sensible parts of it, but in a start we are using a KISS (keep
it simple, stupid) design which just backups the first 64 kb of every file
(and maybe the last 64 Kb, too).

A structure of a XCD is pretty similar to that of VCDs: a ISO bridge track,
and then a series of Form2 tracks containing just the contents of each file,
linked from the ISO filesystem so you can load them directly from OSs
supporting M2F2 files under ISO 9660 (which unfortunately is not the case of
Linux, because its iso9660 fs driver lacks M2F2 support). This last thing is
pretty annoying since you have to watch them in raw form using -vcd 2, so
you can't take advantage of the new single-track mode which lets you save a
good amount of space and has less burning problems.

The backup data is written inside the first track and is linked from the ISO
FS, too. It would be possible to put it in a separate track but I don't see
the need for it.

The draft XCD specs written by avih are available at http://xcd.sf.net

Hope this helps to clarify things.

DeXT
http://webs.ono.com/de_xt/



"Moritz Bunkus" <moritz at bunkus.org> escribió en el mensaje
news:20030108210844.GJ8762 at bunkus.org...
> [Automatic answer: RTFM (read DOCS, FAQ), also read DOCS/bugreports.html]
> Hi.
>
> > Very soon the real XCD backup creator tool should be available, saving
> > the first 64 KB of every file ( headers ) on a separate mode 2 form 1
> > track with ECC ...
>
> Which will create headaches for OGM... At least if the demuxer aims at
> also reading the vorbis setup packets (which do not necessarily come
> directly after the 'beginning of stream' and comment packets). Oh well,
> whatever, the idea to store the headers independently with ECC is good.
>
> Just curious... Will there be a filesystem on this track (bad because
> of the overhead involved), or will it consist only of the 64k data? I
> assume tha latter as 64kb sounds 'just like the right size' :)
>
> --
>  ==> Ciao, Mosu (Moritz Bunkus)
>
> _______________________________________________
> RTFM!!!  http://www.MPlayerHQ.hu/DOCS
> Search:  http://www.MPlayerHQ.hu/cgi-bin/htsearch
> http://mplayerhq.hu/mailman/listinfo/mplayer-users
>