Talk:Material Exchange Format
|WikiProject Film||(Rated Start-class)|
I am very concerned about the text suggesting that MXF can be "converted into AVI". Many MXF files do not contain video (or even any linear media at all). Even then there are effectively as many video compression codecs in MXF files as there devices which create MXF files and no software can support arbitrary codecs. These are two good reasons why this line is NG, and I've nixed it. —Preceding unsigned comment added by 188.8.131.52 (talk) 15:54, 4 December 2007 (UTC)
Avid / Sony incompatibility
This is just something that bugs me, but Avid's implementation of MXF cannot be read in Sony Vegas.
why no signature on previous comment? would be interesting to chat more about this... this is the talk page, right? :-) but there are many "broken" implementations of MXF-wrapper. typically, an avid will read the stream numbers differently, so that for instance an audio track will have vanished.
bigger problems than this arise because users assume that the MXF wrapper somehow guarantees interoperability in & of itself. it does not. it merely presents its contents to different systems in a standardised way. there are two consequences of this. first, the manufacturers of different systems must all comply with the arrangement of the metadata fields within the wrapper, so that information about the MXF's contents can be found in the same place by disparate technologies (edit systems, asset managers, playout servers & automation...) second, the user must be aware of the things that MXF doesn't fix for him: codec. audio track layout & numbering. version control. "production" metadata. & so on.
MXF provides a good framework to facilitate interoperability, but it is not going to fix interoperability issues on its own. Duncanrmi (talk) —Preceding undated comment added 14:15, 15 July 2012 (UTC)
It may be enlightening to add information on why there are several different flavours of MXF. If anyone has a copy of the SMPTE journal, the information should be there... i.e. I recall skimming over an article about MPEG2 essence in MXF. AFAIK, there are issues such as:
A- Audio interleaving.
B- MPEG2 indexing for fast random access. Important for real-time editing of HDV and XDCAM material (the XDCAM type that uses MPEG2 compression).
C- Performance issues. (My knowledge is vague here.)
D- Other reasons why there needs to be several flavours of MXF.
Glennchan 06:44, 7 October 2006 (UTC)
I'd say: MXF is a wide standard for the wrapping of a range of essence types with a range of metadata schemes for a range of use cases. This is why there are so many "flavors."
Gwsyzygy 17:28, 11 May 2007 (UTC)
I believe the references to "naming convention which relies on randomly generated filenames" are UMIDs, which are not ramdomly generated but are specially crafted filenames intended to be universally unique (UUID).
--it's probably talking about P2, which has an unfortunate habit of naming files things like 001UZ.MXF, which is about as much use as a chocolate teapot. I think it's fairly obvious that MXF is an absolute disaster, a train wreck of a format that does exactly the opposite of what it set out to do, and I think this should be represented here if we can find the reference. —Preceding unsigned comment added by 184.108.40.206 (talk) 03:23, 19 October 2008 (UTC)
been a while since anybody's been in here.... I was responsible for the area on the page regarding aes audio & the lack (within the "budget" MXF toolset) of a free-text annotation functionality. I have encountered MXF-wrapped essence in many forms & scenarios, from international broadcast file traffic to domestic camcorders. I think it's important to remember that MXF is a /wrapper/, in the same way as quicktime, & should be regarded as replacing (I'm sorry about this bruce, tom...) the jiffy-bag that used to carry cassettes to & fro. that MXF fails (again, at least for those of us on a budget) to provide the same functionality as the record report or cover-letter one would find with a cassette, is probably its single biggest failure. duncan. — Preceding unsigned comment added by Duncanrmi (talk • contribs) 16:11, 13 October 2011 (UTC)
"MXF in use" section
"Most of the incompatibilities were addressed and ratified in the 2009 version of the standard."
the paper cited here was written by the director-of-product-marketing of MOG, a manufacturer of MXF tools. is it reasonable to cite this as bearing out the above statement?
I don't want to disparage mr ferreira's command of english or of the technology he addresses, but.... have any of you read the paper?
it would not pass muster as a wikipedia article itself.
the claims made for progress being made in both the wider use & the functionality of MXF are not supported by real-world case studies. none of the participating manufacturers are mentioned in connection with their adoption of or adaptation to MXF, save one brief mention of sony & panasonic early on in the piece. there are claims made on page 6, in particular, which are unsupported & probably even now (mid-2012) unsupportable.
I'd like this statement to be struck, or at least qualified as having come from an optimistic manufacturer.
I don't think it's possible or necessary for an article about an interoperability technique to avoid explicit mention of manufacturers & their products that are in real-world daily professional use, & for which this standard was explicitly developed. I would like to see more mention of the actual products, software & hardware, that MXF affects, & what effect MXF has had upon them & interoperability amongst them. I don't think this needs to turn into a forum about MXF, nor a mechanism for driving change, but at the moment the article does little to illuminate the actuality of MXF use.