This is a subpage of MCF specification.
Name two reasons why people use SVCD, while AVI (with XviD in it) is a lot better in terms of quality.
We are aiming to fix both. The first one is difficult, but I believe that some smaller manufacturers will support it at some stage: we are free (ie. no licencing fees), powerful and simple to read.
The second one is the main issue here - burning data without heavy error correction present on normal CDs. We're currently using Mode 2 sectors (note: non-XA, just pure Mode 2). SVCD/VCD use Mode 2/XA, which has less space for data. The structure looks like this:
VERY IMPORTANT: MCF-CD can handle ANY FORMAT and protect its headers, without knowing anything about the format itself. The program writing MCF-CD needs to know which areas to protect. If you don't care about protecting headers, you can put ANY format (BMP, AVI, ZIP, Ogg, MCF, ..) on MCF-CD.
With MCF-format files it determines Prots (areas to be protected) automatically. If someone wants to support Prots (protected areas) with Ogm, Ogg, AVI or any other format, we invite him to send a little piece of C-code for determining Prots for that format, so that we can add support for it to MCF-CD writing software. Reading software doesn't require any changes for Prots of new formats.
| CD-ROM Mode2/XA Form 2 sector (2352 octets) | ||||
|---|---|---|---|---|
| Sync | Header | SubHeader | Data | EDC |
| 12 octets hex: 00 FF FF FF FF FF FF FF FF FF FF 00 | Minute (bcd8), Second (0-59, bcd8), Frame (0-74, bcd8), Mode (0x02) | 8 octets (4 octet struct twice) | Data (2324 octets) | 4 octets CRC |
BCD8 is Binary Coded Decimal, 8 bits (two digits) of it. In it each decimal digit (0-9) gets 4 bits. So, a value 74 (decimal) would be coded as 0111 0100 == 0x74.
SubHeader instructs the CD firmware on which Form the sector is.
struct SubHeader
{
uint8 FileNumber; // Used for interleaving, 0 = no interleaving
uint8 AudioChannel;
uint8 EndOfRecord:1;
uint8 VideoData:1; // true if the sector contains video data
uint8 ADCPM:1; // Audio data encoded with ADPCM
uint8 Data.1; // true if sector contains data
uint8 TriggerOn:1; // OS dependent
uint8 Form2:1; // true => form 2, false => form 1
uint8 RealTime:1; // Sector contains real time data
uint8 EndOfFile:1; // true if last sector of file
uint8 Encoding; // Don't know what is this
};
Data protection (for headers) is done by taking a backup of each important part. These parts we call Prots. LBA-values in MCF-CD are relative to start of the MCF-CD track (first sector is #0).
Sectors 0-2 contain MCF-CD header (which is only one sector, but there are two backups):
0x00 "MCD-CD 0.1 - more info: http://mcf.sourceforge.net/" (64 octets)
0x40 Filename (64 octets)
0x80 Size (uint32) (=total file size, if the whole file is on a single CD)
0x84 File type (4 octets) (types, except ones starting with ".", must be registered)
.MCF = MCF
MPG2 = MPEG-2
0x88 Position in the file (uint64) (where the CD starts; 0 for single-CD files)
0x90 Total file size (uint64)
0x99 Total number of discs for current file (uint8) (0=unknown, 1=single-disc file)
0x9A Number of the current disc (uint8) (1=first, ..)
0x9C LBA of the first storage sector (uint32)
0x100 Prot #1: Position in the original file (uint64)
0x108 Prot #1: Size (uint32)
0x10C Prot #1: LBA (uint32)
0x110 Prot #2: Position in the original file (uint64)
0x118 Prot #2: Size (uint32)
0x11C Prot #2: LBA (uint32)
...
0x1F0 Prot #16: Position in the original file (uint64)
0x1F8 Prot #16: Size (uint32)
0x1FC Prot #16: LBA (uint32)
Multi-disc allows storing a file up to hundreds of gigabytes in size, and to access it as a single file, even while it is spanned over several CDs.
MCF-CD supports up to 16 protected areas, so it really should be sufficient for any file format. Most formats require 1-3 of those.
The data inside starts at "LBA of the first storage sector" (typically 3). It is just 2332 octets of data per sector, copied directly from the file. After all the data, usually in the next sector, starts Protection #1, which is another copy of the data specified by size and original position. Thanks to that, we don't need ECC algorithms used on CD-ROM, but only simple Adler-32 algorithm. Also, all sectors have the same structure (and 2332 octets of data inside).
The CD consists of several tracks. One contains ISO-9660 filesystem (bridge). Others can be MCF-CD tracks (Mode 2 Form 2) or some other tracks (CD-audio, for example). Each MCF-CD track contains one file ("Shrek.avi", for example). Typical MCF-CD has 2 tracks: one Mode 1 ISO-9660 filesystem, and one Mode 2 Form 2 MCF-CD-track (with a movie in it).
ISO-9660 bridge filesystem on MCF-CD contains, in CD root directory, files names INDEX01.MCF, INDEX02.MCF, and so on (one for each file/track). Each of these files is a link to MCF-CD track. The ISO-9660 can also contain normal files (stored in Mode 1) and directories.
Current status:
Related links and info: http://www.wsu.edu/~benp/mcfcd.htm
We need following CD specs:
Steve, one of our developers, has generously offered to buy (400 dollars) the relevant data from Philips, if we can't get it any other way.
Subchannels may offer us the edge on VCDs and other formats. Those have no protection for the data, but we could have nice extra protection in a space that couldn't be used for real data anyway (not all devices/software can read subchannel data).
We need Windows-coders capable of writing filesystem drivers - one of our goals is to allow directly accessing files on MCF-CD via filesystem, with ANY program. Currently we are limited to software capable of using DS-filters, or which otherwise know MCF-CD. We could also have use for Linux-coders on the same issue. I (Tronic) can probably do the job, but that will take some time.
Avih (one of the guys hanging on #mcf) disagreed on our name (MCF-CD) and data protection (probably at the end of disc, but may change) and, with few others, started a competing project. The project is named XCD.
XCD is very similar to VCD: it has several subdirectories, and stores headers of files to separate files. Unlike MCF-CD, it cannot be read without first reading ISO-9660 filesystem of it. Also, having files divided to separate virtual files (\HEADERS\HEAD0001.XCH and \MEDIA\STRM0001.XCS, where 0001 number of the file inside it) can be problematic in many programs. The reason for separate files is that it allows using ECC of M2F1 for error-correction.
XCD also aims to multimedia only (or so it seems, with playlists and everything), while MCF-CD can contain any file format (MCF-CD is meant to be supported at filesystem level, while XCD support is player-level).
Other than that, it is very similar to MCF-CD. Both formats fully comply with the XA/Bridge format used on VCDs, XVCDs, etc.