[pthyseba]

Hello,


I have been experimenting (MXF first-timer) with mxflib tools (mxfdump, mxfsplit, mxfwrap) in an attempt to extract essence from OP-Atom files, and wrap them into OP1a files (we need this in some worklfow automation setup)

I have stumbled across the following: one OPAtom MXF (Avid Media Composer 5) file contains the following essence (retrieved using BBC Ingex MXFDump tool)

06.0e.2b.34.04.01.01.01.0d.01.03.01.02.06.02.00
= [ AES3/BWF - BWF (clip wrapped) ]

mxfsplit -w does not detect this as a PCM file (and consequently, does not add a WAV header)
mxfdump interprets this as
OperationalPattern = MXF Specialized OP Atom
EssenceContainers
EssenceContainer = MXF-GC AES-BWF Audio
which seems correct to me.

I have determined that after rewrapping with another tool into OP1a, the essence is identified (using MXFDump again) as
0 = 06.0e.2b.34.04.01.01.01.0d.01.03.01.02.06.01.00
= [ AES3/BWF - BWF (frame wrapped) ]

(note single-digit difference, frame-wrapped vs clip-wrapped)

This new file can be split by mxfsplit (ie essence is detected as sound track).

Note that raw essence (without -w) is identical for essence extracted from both MXF files (ie raw essence dump seems correct anyway)

I have the following questions:
1) dict.xml and ulmap.h don't contain key for Clip-Wrapped AES3/BWF audio as produced by MC5, how does mxfdump identify it as sound (AES3/BWF) correctly?

2) Is it difficult to make mxfsplit recognize it as a sound track? (dict.xml update? ulmap.h update? having to write new esp_... ??)

3) How would I go about extracting some metadata from OpAtom file, and inserting it into the OP1A? I can textually dump using mxfdump and "reserve space" using mxfwrap -h, but how do I actually get the metadata IN the resulting MXF file? Can it be done with mxfwrap/default mxflib tools?

Thanks in advance for any insights!
Pieter

[Matt Beard]

This one has been puzzling me. The code that determines whether to split the essence as a wave file is as follows:

Code:

if(SplitWave && Track && (Track->GetTrackType() == Track::TrackTypeSoundEssence) && (Descriptor->IsA(GenericSoundEssenceDescriptor_UL)))

So, if the SplitWave option has been set, and the track exists, and it is of type "TrackTypeSoundEssence", with a Generic Sound Essence Descriptor, then it will be split out into a wave file.

The determination of the track type is based on the DataDefinition property in the Structural Components of the Track. Maybe that is wrong in the original file.

[pthyseba]

Matt, thanks for your time.


I have taken another look at the "clip-wrapped" OP1a containg audio (a simple audio mixdown from Avid Media Composer 5)

It seems to have both a timecode track and an audio track.

mxfdump doesn't seem to like either as it spits out numerical values only for the DataDefinition ULs:
8 in total, 4 in MaterialPackage, 4 in sourcePackage

2 different DataDefinition ULs:
DataDefinition = {7f275e81-77e5-11d2-807f-006008143e6f} (i Think the TimeCodeComponent)
DataDefinition = {78e1ebe1-6cef-11d2-807d-006008143e6f} (source Clip)

it gives me 2 timecode DataDefiniton and 6 source clip DataDefinitions (but doesn't translate either of them into a readable form, indicating to me that the type hasn't been recognized)

BBC's Ingex MXFdump gives these two different ULs for the DataDefinition

timecode: [k = DataDefinition
02.01, l = 16 (0010) ]
0 80 7f 00 60 08 14 3e 6f 7f 27 5e 81 77 e5 11 d2 ...`..>o.'^.w...

essence: [ k = DataDefinition
02.01, l = 16 (0010) ]
0 80 7d 00 60 08 14 3e 6f 78 e1 eb e1 6c ef 11 d2 .}.`..>ox...l...


When I unwrap (using either freemxf mxfsplit or BBC Ingex mxf2raw), and then re-wrap it as frame-wrapped essence (using BBC Ingex raw2mxfop1a --pcm) the resulting file has following properties:
grepping mxfdump output for DataDefinition now yields
DataDefinition = SMPTE 12M Timecode Track
DataDefinition = SMPTE 12M Timecode Track
DataDefinition = Sound Essence Track
DataDefinition = Sound Essence Track
DataDefinition = SMPTE 12M Timecode Track
DataDefinition = SMPTE 12M Timecode Track
DataDefinition = Sound Essence Track
DataDefinition = Sound Essence Track
So 2 major differences:
1. mxfdump seems to "recognize" the track type
2. they are distributed 4-4 instead of 2-6

Using BBC Ingex MXFdump to obtain numerical values I get these 2 distinct ULs:
[ k = DataDefinition
02.01, l = 16 (0010) ]
0 06 0e 2b 34 04 01 01 01 01 03 02 01 01 00 00 00 ..+4............

[ k = DataDefinition
02.01, l = 16 (0010) ]
0 06 0e 2b 34 04 01 01 01 01 03 02 02 02 00 00 00 ..+4............

Clearly, the ULs differ wildly from the ULs in the original file (0 06 0e vs 0 80 7) ?! I can't immediately find 80... in the SMPTE registry at http://www.smpte-ra.org/diffuser/mg-diffuser.php

I have attached processing output of original and re-wrapped file using both tools (freemxf's mxfdump and BBC's MXFDump) to this message.

Do you have any clue whether this is some Avid specific issue?
Note that the essence container UL is "as expected" :
06.0e.2b.34.04.01.01.01.0d.01.03.01.02.06.02.00
= [ AES3/BWF - BWF (clip wrapped) ]

vs
06.0e.2b.34.04.01.01.01.0d.01.03.01.02.06.01.00
= [ AES3/BWF - BWF (frame wrapped) ]


You are also positive that the fact that the clip-wrapped EssenceContainer UL is not present in my dict.xml has nothing to do with the track identification?

Thanks!
Pieter

[pthyseba]

Matt,



I stumbled across the following URL


http://wenku.baidu.com/view/85b20835f11 ... 05a08.html

I quote, page 4/5,

An MXF parser reading the value of the DataDefinition property of a StructuralComponent should recognize the following non-standard data type identifiers:
< list of ULs starting with 80 >

So I guess the question becomes: how do I make mxfdump aware that an UL is of type Sound? Is it as simple as "adding" this UL somewhere in the code or in an external config file?

Also, can mxfwrap use textual output from mxfdump to include some metadata elements in the resulting new MXF file?


Thanks!
Pieter

[Matt Beard]

The key here is the phrase "non-standard" - what is happening is that some Avid MXF files indicate track types using a method derived from AAF. This method is not in the published 377, but a new specification will add something similar.

If you want to parse these files, you can add the data defs to those defined in "Track::InitTrackTypes(void)" at the bottom of metadata.cpp (assuming you are using the latest code from the CVS). This is not a complete solution, but it should work!