R10: Clarification of formatStandard and formatEncoding

[pdpinch]

Up to PBCore 1.1.1 formatStandard performed a dual-duty of commenting on the video signal type or the container of architecture of the digital file. Given that formatStandard was depreciated in 1.2, there is now essenceTrackStandard to manage video signal type but nothing to track the architecture. For instance, knowing whether a digital file is BWF format or OP1A MXF is too specific to be managed within formatDigital (mime type only) but often essential for workflow. This could make formatStandard (or a renamed version of it) more equivalent to formatPhysical were there is a structure way to express generic and specific information about the architecture of the file. Adjust picklist and recommendations for the use of the field distinct from essenceTrackStandard (which focuses on video signal, file architectural info isn't as relevant at the track level). Additionally as formatStandard, formatEncoding, and formatDigital are often confused documentation and examples should be clarification to make their meaning more clear and disctinct. (Additionally the picklist for formatEncoding contains values not directly related to encoding such as MXF. There is also more need for attention to analog encoding practices such as groove type, etc) (Is there an external authority that PBCore can defer to for essenceTrackEncoding, fourcc.org?)

[pdpinch]

Despite what it says in the official change request document, this does not require a schema change.

[WeAreAVP]

Given that this issue was related to 5 of the original gathered requests and a recurring issue on the review panels, if not a schema change then what is the plan?

[jackbrighton]

I think we must provide really clear guidance on where to record metadata about 1) the wrapper 2) what version of the wrapper (e.g. MXF has several)

Why not include an optional version attribute in formatDigital? The same approach could be applied to formatPhysical.

Does this not get at the issue?

[WeAreAVP]

I think this issue needs some cooperation between the controlled vocabulary and dictionary side of the project and the schema development side of the project. In PBCore 1.1 there's confusion on why terms like 'PCM' would be in scope for both fields. Now that formatStandard is long gone and we have essenceTrackStandard, things are more confusing, because the documentation and vocabulary for formatStandard is out of context on the track level.

Since formatStandard was dropped we've lost the key field to document the 'architecture' of the file format (BWF, MXF OP1A, Quicktime reference, etc), these terms aren't track specific and are thus out of context in essenceTrackStandard.

I'm worried that if we close this issue then at a later point the documentation is written that it will become more clear that this really is a schema issue (attributes as Jack mentioned? bring back formatStandard?). It would be good to hear how PBCore 2.0 (whether in documentation, schema or both) will respond to the original use cases and requests that are associated with this issue as well as hearing why formatStandard was depreciated.

[jackbrighton]

Agreed this needs clarification so there's no ambiguity about these elements. And maybe bringing back formatStandard is the missing element.

[MarcosSueiro]

That makes sense to me. Incidentally, for audio transfers we have been using formatEncoding to describe how the audio was captured into the digital file (e.g. "78 RPM, 500 Hz turnover, 2100 Hz rolloff", etc.; or "ripped from CD using Exact Audio Copy").

[WeAreAVP]

To me this seems like improper use. essenceTrackEncoding is supposed to identify the type of encoding of the track, not necessary how that encoding was generated. So "PCM" rather than "ripped with EAC", right? Perhaps this type of workflow or creation environment data will be better in one of the new annotationtype/annotation elements.

[MarcosSueiro]

I know we are clearly stretching the definition, but to me a data-reduction standard (MPEG) and a disc playback EQ (RIAA curve) are conceptually similar, as they all refer to the way in which data/audio is stored and how it should be retrieved. The definition for essenceTrackEncoding mentions "reversible compression", and its guidelines "enter what you know you are using to encode your media item."

[pdpinch]

The schema has been changed. These fields have been replaced by essenceTrackEncoding and essenceTrackStandard and InstantiationStandard.

Each of these has a recommended CV which may be replaced.