Re: [MCF-Devel] MPEG audio

Lasse Karkkainen wrote:
 >> 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.

Because I don't have much idea of the API, what services a Transor would 
give, etc... Besides I'm not sure the "transcoders" (any format-to-mcf) 
really need transors. I thought the Transors were more about 
coding/decoding and they are container independant. (MPA is both a 
container and a serie of codecs)
Anyway, as I'm coding them in C++ taking the MPA objects to put them in 
a transor should be very easy.

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

Mostly for encoding/decoding.
It would rather fall in the category of what Ingo has working on.

 > 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).

Depends if the transor deals only with coding/decoding/timecode or 
container transcoding...

 > 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?

I think it's better with Version1 and Version2. The MPA headers are very 
small and close to their limits. So nothing should appear with more 
values (I think mp3Pro uses one of the few remaining reserved values).

 >> 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.

Se above.

 >> 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.

BTW, is there a way in the spec (a logo, colour scheme, etc) to know if 
a feature is freezed or not ?