Re: Cooperation between MPC and MCF

Hello Frank,

Christian forwarded this to the MCF dev mailing list.

ChristianHJW wrote:
> We got an reply from Frank Klemm [[email protected]], coder of MPC
> on the cooperation matter :
> 
> ----------------------------------------------------------------------------
> It's always the same problem:
> 
> - Where it is completely and unambiguously documented?

http://mcf.sourceforge.net/
It's not yet complete and unambiguous. But closer to being complete.

> - When and where was the discussion about the format specification?

The mcf-dev mailing list, IRC (#mcf on openprojects) with people coming 
from different interrest (codec coders, mplayer coders, directshow 
coders). It's been started more than 1 year ago and is close to version 
1. (no dot releases allowed)

> - Is there any code available which is portable in the ISO way

Yep, check libmcf on the Sourceforge CVS.
The mplayer people also want to create their own parser in C (libmcf is 
in C++).

> (no autoconf, automake, configure, bash, perl stuff, but portable)

Not sure it's still compiling on Unices so far. I should update the 
makefile. But none of the things you mentioned are used so far. I was 
thinking about automake BTW. Why don't you like it ?

> I was searching for some USABLE documentation of the Ogg/Vorbis file format
> and found nothing.

We also had the same problem. It's supposed to be an open format, but is 
a bit obsucure and not much support is added. That's I (personally) 
think that Xiph should concentrate on their codec, while other ppl 
(MCF?) concentrate on the container.

> Needs of container format:
> 
> - less overhead ( less 1% )

copy from the website :
FormatTotal file sizeAmount of structures
MCF 729 Mo + 2.6 Mo = 732 Mo 0.4 % of file size
Legacy AVI 729 Mo + 65 o * 129567 frames = 737 Mo 1.1 % of file size
OpenDML AVI 729 Mo + 81 o * 129567 frames = 739 Mo 1.4 % of file size

For audio it might be more. But we should have a deeper look at that 
(I'll check with my mpa2mcf program). Also we allow lacing like in OGG 
which can significantly improve the overhead.

> - comfortable fast and exact review and cueing

No probs, we have mandatory seek entries for that.

> - easy to parse

Very ! ;)
Less that AVI I think, probably not much than OGG.

> - endian independent

Dunno what you mean here. But all data in the MCF structure are big 
endian. I don't know an endian independant way to store a 32 bit 
value... libmcf have a class for big/little/platform endian conversion 
that makes the use transparent.