Re: [MCF-Devel] MPEG audio

> I'm about to start a project similar to wav2mcf called mpa2mcf...
> It's a program to put MPEG audio data in an MCF file.

Btw, why don't you write a Transor instead of a program? Doing so would 
finally get this Transor thing rolling.

Then the next step would be writing a simple application that uses that 
Transor for conversion.

In this case the Transor should read from .mpa file opened by the app. 
When app calls that Transor, it should first supply a full Track Entry 
for the app. Then the actualy transforming could start: player calls the 
Transor for data, Transor reads it from .mpa and outputs Blocks for the 
app (that then uses libmcf to mux those Blocks to a MCF).

It currently seems that we won't be able to design that API from 
scratch, so just writing some Transors would be the next option. After 
all, this is how mcflib started too. I just wrote functions I need, just 
extending it on the way. And it even wasn't *that* bad code/API ;)

> And apparently the MPEG audio is not complete.

True.

Here's one option:

Format: "MPEG-Audio"
Version1: 1/2/2.5 (0x0001, 0x0002, 0x0003)
Version2: layer (0x0001-0x0003)
Version3? Dunno. Maybe should leave that zero, or maybe it would contain 
flags for VBR, etc.

If you want to change anything of what I said, let me know. Layer could 
be put in the other byte of Version1 instead of using Version2 for it. 
Any opinions?

> As I don't know about MPEG-4 audio (AAC I think), I don't know if it 
> will be contained in this "MPEG-Audio" or not.

Neither do I, but I believe it is quite much from the scratch, so it 
won't be "MPEG-Audio" ..

> BTW, if anybody could make some equivalent (portable) programs for video 
> (HuffYUV, MPEG1, MPEG2, MPEG4 and AVI compatibility) that could be 
> great. Such programs don't require Transors as they only do transcoding. 

What are _Trans_ors if not transcoders? Yes, some of those might be able 
to actually compress or decompress, but many will only transcode 
(to/from foreign file format (like AVI or MPA) or to/from foreign API 
(VfW)). Anyway, it would really kick MCF development forward if we had 
some Transors and at least some view of how the API should work, instead 
of set of *-to-mcf and mcf-to-* utils.

> And we could finally make use of the demuxing part, improve it and 
> advance further with other features of MCF (seek entries, attachement, 
> chapters, etc) when the spec are ready ;)

I consider attachments and chapters ready, but more people should review 
those before I can freeze anything.

- Tronic -