Subject: [Cellar] Matroska metadata for digitization and process history

From: Dave Rice <[email-masked]>
Date: Wed, 7 Sep 2016 15:09:22 -0400

Hi all,

I wanted to bring a discussion here which happened a bit at the No Time to Wait symposium a few months ago regarding metadata in Matroska about digitization, transfer, and source. This was a discussion on how to store data in Matroska about the history of that stored audiovisual data, which would cover the source of that data and the historical process used to create the current Matroska file, possibly itemizes out that process generation by generation.

For precedence a few other av standards cover this type of data, for instance in WAV files the bext <https://tech.ebu.ch/docs/tech/tech3285.pdf> chunk contains 'codinghistory' which is a list of historical processes used to create the stored audio. An example of bext coding history:

A=ANALOG,M=mono,T=Studer A810; SN3690; 15 ips; open reel tape,
A=PCM,F=96000,W=24,M=mono,T=Benchmark; ADC1; SN00252; A/D,
A=PCM,F=96000,W=24,M=mono,T=Lynx; AES16; DIO,

Also etree has a database where md5 and ffps values from SHN and FLAC files can be related to historical processes data: see http://db.etree.org/shnlist.php?artist=2&year=1995 (in this case the process data is stored in a separate database rather than the file itself but the scope is similar).

Some use cases I'm thinking of:

- A set of Matroska files are created using various digitization processes and hardware and those processes should be document (example: 1.mkv created from the output of a film scanner, 2.mkv from running a VHS through component video to a blackmagic card  and 3.mkv from running a Betamax through cosposite video to an Elgato capture card). In some cases the data could be collected as introduced into the mkv file as it is written and in other cases it could be added after via mkvpropedit.

- Another case, an mkv is created from a film scanner, then another mkv is created from the first to make some correct corrections, and then a third mkv is created as an access copy with a lossy compressed codec. The process data of each mkv file could be added to with each generational move, so that with the third file the history of its creation could be clear.

- One mkv file is used to create another at a different set of characteristics, such data could communicate that the data used to be in a different frame rate, interlacement pattern, or colorspace to give some context to why it looks the way it does.

There is some overlap with this concept and the PREMIS <http://www.loc.gov/standards/premis/> metadata standard which documents an XML document that defines and relates concepts such as Agents (hardware, software, people), Events (digitization, transcoding, processing), and Objects (source mkv files, source videotapes, source film, etc). It could be feasible to simply determine a method of documenting this data in PREMIS XML and then store that as an attachment, though I think it makes it more accessible as a set of Matroska metadata tags.

I tried working on this subject a few years ago and created this sample <https://archive.org/download/MatroskaSampleWithEmbeddedPreservationMetadata/pres_metadata_sample_20110608.mkv> which attaches a photo of the source tape and adds process metadata. Here's an output of that metadata from FFmpeg.

  Metadata:
    CREATION_TIME   : 2011-05-03 02:12:03
    COMPATIBLE_BRANDS: qt  
    ORIGINAL_MEDIA_TYPE: {Physical format of the source tape. Vocabulary?}
    ORIGINAL_MEDIA_TYPE/BARCODE: {Barcode or other identifier from the tape.}
    ORIGINAL_MEDIA_TYPE/BARCODE/source: {name of barcode authority or creator; example "XYZ Archive Barcode"}
    ORIGINAL_MEDIA_TYPE/LABEL: {The record label or imprint on the source media object.}
    ORIGINAL_MEDIA_TYPE/DATE_RECORDED: {The time that the recording began. This is akin to the TDRC tag in ID3.}
    ORIGINAL_MEDIA_TYPE/condition: {Comments on the condition of the source, any preparation for playback of the source tape (if relevant).}
    ORIGINAL_MEDIA_TYPE/initial_source_timecode: 01:02:15;10
    ORIGINAL_MEDIA_TYPE/initial_source_timecode/settings: DropFrame=Yes / 24HourMax=No / IsVisual=No
    DATE_DIGITIZED  : {Date and time of the file creation process. Enter in ISO 8601 format.}
    ENCODED_BY      : {Name of the technician or organization responsible for the encoding and file creation process}
    ENCODED_BY/URL  : {URL for the technician or organization listed in ENCODED_BY.}
    ENCODED_BY/processing_actions: {Description of any actions performed during processing, such as trimming silence.}
    ENCODED_BY/capture_software: Blackmagic Media Express
    ENCODED_BY/capture_software/version: 2.0.3
    ENCODED_BY/capture_operating_system: Ubuntu
    ENCODED_BY/capture_operating_system/version: 10.10
    ENCODED_BY/capture_device: Decklink Studio SDI
    ENCODED_BY/capture_device/manufacturer: Blackmagic-Design
    ENCODED_BY/capture_device/serial_no: xyz6789
    ENCODED_BY/capture_device/settings: {notes on adjustments or settings}
    ENCODED_BY/playback_device: SVO-5800
    ENCODED_BY/playback_device/manufacturer: Sony
    ENCODED_BY/playback_device/serial_no: abc1234
    ENCODED_BY/playback_device/settings: {notes on adjustments or settings}
    ENCODED_BY/playback_device/playback_signal_path: {Protocols used to transfer audiovisual data between the playback deck and the capture device. example: Component}
    MAJOR_BRAND     : qt  
    MINOR_VERSION   : 537199360
    ENCODER         : Lavf53.2.0

Official tags are in ALL CAPS and my own local tags are in lowercase.

I propose a discussion on:

- Is defining process metadata (aka digitization metadata, coding history) worthwhile to include in CELLAR work?

- Should such metadata be added to Matroska tags or should we use existing metadata standards as attachments?

- Or (building off the prior question) should we add namespaces to Matroska metadata tags so that externally defined standards may be used within Matroska metadata directly?

- And .... what metadata values are needed?

Best Regards,
Dave Rice

---

From: Kieran O Leary <[email-masked]>
Date: Thu, 8 Sep 2016 01:53:36 +0100

Hi,

I'm very happy that this topic has come up for discussion.

On Wed, Sep 7, 2016 at 8:09 PM, Dave Rice <[email-masked]> wrote:
>
> - A set of Matroska files are created using various digitization processes
> and hardware and those processes should be document (example: 1.mkv
created
> from the output of a film scanner, 2.mkv from running a VHS through
> component video to a blackmagic card and 3.mkv from running a Betamax
> through cosposite video to an Elgato capture card). In some cases the data
> could be collected as introduced into the mkv file as it is written and in
> other cases it could be added after via mkvpropedit.
>

Inserted as it is written sounds very interesting, as the capture file does
not end up with an altered whole file checksum, which is what would happen
with post capture metadata insertion. I'm not sure of how mkvpropedit
works, and I wonder if a framemd5 check of the streams would be paranoid or
reasonable after such an update? Perhaps the embedding of stream level
checksums is a good idea at this stage? I saw that Andrew Weaver was
experimenting with this on vrecord.

> - Another case, an mkv is created from a film scanner, then another mkv is
> created from the first to make some correct corrections, and then a third
> mkv is created as an access copy with a lossy compressed codec. The
process
> data of each mkv file could be added to with each generational move, so
that
> with the third file the history of its creation could be clear.
>

This is pretty much an exact scenario that the Irish Film Archive is
dealing with right now. We're investigating PREMIS as a means of recording
this information and linking all the different assets to each other via
UUIDs. Does/could mkvpropedit generate UUIDs? It would be interesting if it
did, as the identifier could then be harvested and also inserted into a
PREMIS xml description afterwards.. Digital Cinema Packages use UUIDs in
their xml files (also embedded in the mxfs) in order to create
relationships between single/multi reel audio, visual and subtitle files.
Perhaps they could also help create this provenance description among this
chain of film assets as well? I don't think that there would be an
automated way to make the link between assets though.

> - One mkv file is used to create another at a different set of
> characteristics, such data could communicate that the data used to be in a
> different frame rate, interlacement pattern, or colorspace to give some
> context to why it looks the way it does.
>

I think that this is a very valid use case, especially for access copies. I
can see the potential for something like vimeo or other streaming platforms
being able to possibly harvest and display this metadata if they bought
into this idea?

> There is some overlap with this concept and the PREMIS metadata standard
> which documents an XML document that defines and relates concepts such as
> Agents (hardware, software, people), Events (digitization, transcoding,
> processing), and Objects (source mkv files, source videotapes, source
film,
> etc). It could be feasible to simply determine a method of documenting
this
> data in PREMIS XML and then store that as an attachment, though I think it
> makes it more accessible as a set of Matroska metadata tags.
>

I'm not very familiar with Matroska attachments. I think this is a nice
idea for distributing files publicly, in that a user could gain additional
context if required. For long term preservation, I can't help but think
that the PREMIS xml would function just as well in a sidecar in an AIP,
with the added benefit of not altering the checksum of the Matroska file.

> I tried working on this subject a few years ago and created this sample
> which attaches a photo of the source tape and adds process metadata.
Here's
> an output of that metadata from FFmpeg.
>
> Metadata:
> ORIGINAL_MEDIA_TYPE/condition: {Comments on the condition of the source,
> any preparation for playback of the source tape (if relevant).}
> ENCODED_BY : {Name of the technician or organization responsible
> for the encoding and file creation process}
> ENCODED_BY/processing_actions: {Description of any actions performed
> during processing, such as trimming silence.}
> ENCODED_BY/playback_device/playback_signal_path: {Protocols used to
> transfer audiovisual data between the playback deck and the capture
device.
> example: Component}

I think that looks great! Were you local tags based on a controlled
vocabulary?

> worthwhile to include in CELLAR work?

Just to be 100% clear, do you mean defining process metadata for insertion
into a Matroska container, or a general vocabulary/schema? Perhaps the
latter is out of the scope of CELLAR, but selfishly I'd like it included:))
I'm very interested in this topic and think that it is essential metadata
that should be captured. I'm on the fence with regards to embedding the
metadata versus storing it in a sidecar file or database.

> metadata standards as attachments?

I'm in favour of increasing the number of Matroska's official tags. Would
using existing metadata standards as attachments require any extra work or
discussion as attaching metadata xml files could probably be done right
now? I took a look at the Matroska tags recently and they do not map well
to process history for digitisation. As Matroska is increasingly used as a
format for digitisation and preservation, I think it would be very useful
if the tag vocabulary could support this kind of metadata.

> - Or (building off the prior question) should we add namespaces to
Matroska
> metadata tags so that externally defined standards may be used within
> Matroska metadata directly?

This is interesting, but can you give an example? Would a tag look
something like PREMIS:AgentType=Software? I wonder if this is actually the
best of both worlds, as it allows reference to other standards through
embedding rather than attachments. I'm not sure how this would be any
different to your example of using a customised local vocabulary, unless
there was some kind of reference to these standards built into the Matroska
spec, which could even be validated?

> - And .... what metadata values are needed?

I think that this is a great discussion topic that would have benefit
beyond the scope of Matroska. PREMIS is ultimately quite vague in terms of
what is actually recorded. It would be very helpful if archives shared what
kind of information they recorded pre/during/post capture. I'm sure that we
would be happy to share the outcomes of what we record in PREMIS for our
film and tape workflows, once we actually get that far.

Best,

Kieran.

---

From: Brecht Declercq <[email-masked]>
Date: Thu, 8 Sep 2016 17:33:35 +0200

Dear all,

My first contribution to this discussion group!
In principle I endorse Kieran stating that PREMIS-based info on the
digitization (preservation in general) history of the essence may as well
(even preferably?) be stored in a side-car file.
The logic is that metadata in general, and preservation metadata in
particular are by nature more evolutive than the essence. Altering the
whole file when only the metadata should be altered might cause an
unnecessary workload for the archive's system.

I'd also like to point to the work done on this issue for the MP-AF under
MPEG-A, by a working group lead by Walter Allasia (however, I don't know
what the current status of this work is):
http://david-preservation.eu/wp-content/uploads/2014/10/ipres2014_mpaf_cr_v4.pdf

In the FIAT/IFTA MMC we have contributed to this work by pointing to the
fact that many (broadcasting?) archives don't stick to a 1-to-1 relation
between the original physical carrier and the new digital master file. This
is because they consider the limits of the physical carrier format largely
(but not completely, cfr. e.g. the max size of 4GB size of a .wav)
irrelevant in the digital world.
Basically there are 3 situations possible:

1 carrier = multiple files (we've always called this "div")
1 carrier = 1 file ("equal")
multiple carriers = 1 file ("append")

It would be interesting if this could be documented as preservation
metadata too...

Best,

2016-09-08 2:53 GMT+02:00 Kieran O Leary <[email-masked]>:

> Inserted as it is written sounds very interesting, as the capture file
> does not end up with an altered whole file checksum, which is what would
> happen with post capture metadata insertion. I'm not sure of how
> mkvpropedit works, and I wonder if a framemd5 check of the streams would be
> paranoid or reasonable after such an update? Perhaps the embedding of
> stream level checksums is a good idea at this stage? I saw that Andrew
> Weaver was experimenting with this on vrecord.
>
> I think that this is a very valid use case, especially for access copies.
> I can see the potential for something like vimeo or other streaming
> platforms being able to possibly harvest and display this metadata if they
> bought into this idea?
>
> > - Is defining process metadata (aka digitization metadata, coding
> history)
> > worthwhile to include in CELLAR work?
> >
>
> > - Should such metadata be added to Matroska tags or should we use
> existing
> > metadata standards as attachments?
> >
>
> _______________________________________________
> Cellar mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/cellar
>
>

-- 

     Brecht Declercq
     Manager Digitalisering & Acquisitie

     VIAA vzw* | Sassevaartstraat 46/209 | 9000 Gent | België | www.viaa.be
<http://www.viaa.be/>*
     T: +32 9 298 05 01 *|* M: +32 474 25 04 67

<https://onderwijs.hetarchief.be/> <https://onderwijs.hetarchief.be/>
<https://onderwijs.hetarchief.be/> <https://onderwijs.hetarchief.be/>
<https://onderwijs.hetarchief.be/> <https://onderwijs.hetarchief.be/>

---

From: Dave Rice <[email-masked]>
Date: Thu, 8 Sep 2016 12:32:14 -0400

Hi Brecht and Kieran,
Replying to both posts inline.

> On Sep 8, 2016, at 11:33 AM, Brecht Declercq <[email-masked]> wrote:
> 
> Dear all, 
> 

Welcome Brecht!

> In principle I endorse Kieran stating that PREMIS-based info on the digitization (preservation in general) history of the essence may as well (even preferably?) be stored in a side-car file.

There are reasons for both and I'm not sure it's in the scope of CELLAR to defined which tactic (embedded or sidecar) is preferred in a given situation, but to define (and/or consider defining) the option to store preservation metadata.

I can think of several AV formats where transfer metadata is embedded when there is no standardized method to store the equivalent data in a side car file. For example in DV transferred from tapes each DIF block contains a STA value which documents the status (success or error) of the playback device reading the data from tape. Similar a recovered stream from DAT tape stores data on the verification of parity data in tape reads when the DAT stream is moved from tape to file.

Many containers generally stores some context about the creation of the file such as encoding timestamp and in the case of Matroska it also stores the WritingApp and MuxingApp. When archives or Matroska creators need to manage further context about the creation and/or provenance of that file we'd have to decide if that additional data should be stored within the file (such as WritingApp and MuxingApp are) or stored in a separate sidecar file. If using a sidecar file then we have a division of some creation data being within Matroska and some without.

... Just noticed that the AS-07 project with MXF addresses this in their specification. See in particular pages 90-91 of http://www.amwa.tv/downloads/specifications/AS-07_Proposed_Application_Specification.pdf where it defines fields for AS_07_Core_DMS_Devices to document capture history. Page 91 defines metadata to document capture devices such as device type, manufacturer, model, serial number, etc.

> The logic is that metadata in general, and preservation metadata in particular are by nature more evolutive than the essence. Altering the whole file when only the metadata should be altered might cause an unnecessary workload for the archive's system.

I think Matroska's design well considers the scenario of such alteration. The EBML specification recommends that all Top-Level Elements have a CRC-32 Element. With this the fixity of the components of the Matroska file are managed independently, so the metadata in the Tags element may be edited without a compromise to the fixity of the AV data in Clusters or other sections. In other containers without internal fixity, a sidecar checksum must be used, and any metadata edit impacts the fixity of the entire file. Additionally Matroska's main metadata wranglers such as mkvpropedit do well to edit the file efficiently so that metadata may be manipulated while impacting only a minimal amount of the file.

> I'd also like to point to the work done on this issue for the MP-AF under MPEG-A, by a working group lead by Walter Allasia (however, I don't know what the current status of this work is):
> http://david-preservation.eu/wp-content/uploads/2014/10/ipres2014_mpaf_cr_v4.pdf <http://david-preservation.eu/wp-content/uploads/2014/10/ipres2014_mpaf_cr_v4.pdf>
Thanks for the reference.

> In the FIAT/IFTA MMC we have contributed to this work by pointing to the fact that many (broadcasting?) archives don't stick to a 1-to-1 relation between the original physical carrier and the new digital master file. This is because they consider the limits of the physical carrier format largely (but not completely, cfr. e.g. the max size of 4GB size of a .wav) irrelevant in the digital world.
> It would be interesting if this could be documented as preservation metadata too...

Matroska does have a linking mechacism via PrevUID and NextUID where multiple Matroska files may be linked in order to emulate the linking of multiple physical carriers. Additionally Matroska has Ordered Chapters so that one Matroska file may represent one physical carrier which has multiple presentations. I've been testing with Ordered Chapters and Matroska so that we can digitize videotapes in their entirety with one Edition for the presentation of the whole captured tape and subsequent editions for each presentation within that content.

[...]

> 2016-09-08 2:53 GMT+02:00 Kieran O Leary <[email-masked] <mailto:[email-masked]>>:
> Hi,
> 
> On Wed, Sep 7, 2016 at 8:09 PM, Dave Rice <[email-masked] <mailto:[email-masked]>> wrote:
> >
> > and hardware and those processes should be document (example: 1.mkv created
> Inserted as it is written sounds very interesting, as the capture file does not end up with an altered whole file checksum, which is what would happen with post capture metadata insertion. I'm not sure of how mkvpropedit works, and I wonder if a framemd5 check of the streams would be paranoid or reasonable after such an update?
> 
Moritz may have some comments, but IIUC mkvpropedit wouldn't affect the Clusters at all while editing the metadata. It would just edit the Tags in place and adding a Void element if needed to cover space or extend the Tags if at the end of the file, or Void the existing tags and append a new larger Tags element to the end of the file.
> Perhaps the embedding of stream level checksums is a good idea at this stage? I saw that Andrew Weaver was experimenting with this on vrecord.
> 
Yes, this is a good use case. vrecord already manages variable to store which connection is going into the Blackmagic card and other context about the creation of files in video digitization. These are currently written out to a sidecar file.
> > mkv is created as an access copy with a lossy compressed codec. The process
> > data of each mkv file could be added to with each generational move, so that
> This is pretty much an exact scenario that the Irish Film Archive is dealing with right now. We're investigating PREMIS as a means of recording this information and linking all the different assets to each other via UUIDs. Does/could mkvpropedit generate UUIDs?
> 
I think most Matroska muxers generate a UUID in the Info Element. Though technically the UUID Element is not required so there many be muxers that opt not too. IIRC webm muxers do not add the UUID Element.
> It would be interesting if it did, as the identifier could then be harvested and also inserted into a PREMIS xml description afterwards.. Digital Cinema Packages use UUIDs in their xml files (also embedded in the mxfs) in order to create relationships between single/multi reel audio, visual and subtitle files.
> 
That sounds reasonable. The UUIDs are easy to harvest via mkvinfo, ffmpeg, mediainfo, etc.
> Perhaps they could also help create this provenance description among this chain of film assets as well? I don't think that there would be an automated way to make the link between assets though.
> 
> I think that this is a very valid use case, especially for access copies. I can see the potential for something like vimeo or other streaming platforms being able to possibly harvest and display this metadata if they bought into this idea?
> 
> > processing), and Objects (source mkv files, source videotapes, source film,
> > etc). It could be feasible to simply determine a method of documenting this
> I'm not very familiar with Matroska attachments. I think this is a nice idea for distributing files publicly, in that a user could gain additional context if required.
> 
Most historical documentation of Matroska attachments specifically documents Attachments for storage of cover art and publicity materials, but any file could be stored and described in there.
> For long term preservation, I can't help but think that the PREMIS xml would function just as well in a sidecar in an AIP, with the added benefit of not altering the checksum of the Matroska file.
> 
> > which attaches a photo of the source tape and adds process metadata. Here's
> > transfer audiovisual data between the playback deck and the capture device.
> > example: Component}
> > MAJOR_BRAND : qt 
> I think that looks great! Were you local tags based on a controlled vocabulary?
> 
I don't think so, I was just making things up.
> Just to be 100% clear, do you mean defining process metadata for insertion into a Matroska container, or a general vocabulary/schema?
> 
Both (though the second one may just be an adoption). Currently Matroska's metadata documentation primarily covers descriptive metadata and a little technical metadata. I was considering whether this should be expanded to cover digitization / process history / provenance metadata as well, as discussed at the No Time to Wait symposium.
> Perhaps the latter is out of the scope of CELLAR, but selfishly I'd like it included:)) I'm very interested in this topic and think that it is essential metadata that should be captured. I'm on the fence with regards to embedding the metadata versus storing it in a sidecar file or database.
> 
> I'm in favour of increasing the number of Matroska's official tags. Would using existing metadata standards as attachments require any extra work or discussion as attaching metadata xml files could probably be done right now?
> 
Yes.
mkvpropedit cellar.mkv -add-attachment premis.xml
> I took a look at the Matroska tags recently and they do not map well to process history for digitisation. As Matroska is increasingly used as a format for digitisation and preservation, I think it would be very useful if the tag vocabulary could support this kind of metadata.
> 
I found the same in the sample I referenced above where ORIGINAL_MEDIA_TYPE and ENCODED_BY are awkwardly used to cover digitization context.
> > - Or (building off the prior question) should we add namespaces to Matroska
> This is interesting, but can you give an example? Would a tag look something like PREMIS:AgentType=Software? I wonder if this is actually the best of both worlds, as it allows reference to other standards through embedding rather than attachments. I'm not sure how this would be any different to your example of using a customised local vocabulary, unless there was some kind of reference to these standards built into the Matroska spec, which could even be validated?
> 
Currently Matroska tags are either local-defined or official Matroska tags which are defined, but there's not a way to use an official tag from another standard. So it would something like the example below, which is the XML representation of Matroska tags but adds a new element for <NameSpace> which references the authority of Tag Names for that value and all nested SimpleTags below it.

<?xml version="1.0"?>
<Tags>
  <Tag>
    <Targets>
      <TargetTypeValue>50</TargetTypeValue>
    </Targets>
    <Simple>
      <Name>event</Name>
      <NameSpace>http://www.loc.gov/standards/premis/premis.xsd</NameSpace >
      <Simple>
        <Name>eventIdentifier</Name>
        <Simple>
          <Name>eventIdentifierType</Name>
          <String>local</String>
        </Simple>
        <Simple>
          <Name>eventIdentifierValue</Name>
          <String>CELLAR.123.Event-4321</String>
        </Simple>
      </Simple>
      <Simple>
        <Name>eventType</Name>
        <String>digitization</String>
      </Simple>
      <Simple>
        <Name>eventDateTime</Name>
        <String>2016-09-08T14:32:11-05:00</String>
      </Simple>
      <Simple>
        <Name>eventDetail</Name>
        <String>umatic vo9850 -> dps575 -> ultrastudio express -> vrecord</String>
      </Simple>
    </Simple>
  </Tag>
</Tags>
> I think that this is a great discussion topic that would have benefit beyond the scope of Matroska. PREMIS is ultimately quite vague in terms of what is actually recorded.
> 
I agree. It crams a lot of detail into a few vague fields.
> It would be very helpful if archives shared what kind of information they recorded pre/during/post capture. I'm sure that we would be happy to share the outcomes of what we record in PREMIS for our film and tape workflows, once we actually get that far.
> 

Thanks,
Dave Rice

---

From: Tobias Rapp <[email-masked]>
Date: Fri, 9 Sep 2016 11:08:11 +0200

On 07.09.2016 21:09, Dave Rice wrote:
> Hi all,
>
> I wanted to bring a discussion here which happened a bit at the No Time
> to Wait symposium a few months ago regarding metadata in Matroska about
> digitization, transfer, and source. This was a discussion on how to
> store data in Matroska about the history of that stored audiovisual
> data, which would cover the source of that data and the historical
> process used to create the current Matroska file, possibly itemizes out
> that process generation by generation.
>
> For precedence a few other av standards cover this type of data, for
> instance in WAV files the bext
> <https://tech.ebu.ch/docs/tech/tech3285.pdf> chunk contains
> 'codinghistory' which is a list of historical processes used to create
> the stored audio. An example of bext coding history:
>
> Also etree has a database where md5 and ffps values from SHN and FLAC
> files can be related to historical processes data:
> see http://db.etree.org/shnlist.php?artist=2&year=1995 (in this case the
> process data is stored in a separate database rather than the file
> itself but the scope is similar).
>
> - A set of Matroska files are created using various digitization
> processes and hardware and those processes should be document (example:
> 1.mkv created from the output of a film scanner, 2.mkv from running a
> VHS through component video to a blackmagic card  and 3.mkv from running
> a Betamax through cosposite video to an Elgato capture card). In some
> cases the data could be collected as introduced into the mkv file as it
> is written and in other cases it could be added after via mkvpropedit.
>
> - Another case, an mkv is created from a film scanner, then another mkv
> is created from the first to make some correct corrections, and then a
> third mkv is created as an access copy with a lossy compressed codec.
> The process data of each mkv file could be added to with each
> generational move, so that with the third file the history of its
> creation could be clear.
>
> characteristics, such data could communicate that the data used to be in
> a different frame rate, interlacement pattern, or colorspace to give
> some context to why it looks the way it does.
>
> There is some overlap with this concept and the PREMIS
> <http://www.loc.gov/standards/premis/> metadata standard which documents
> an XML document that defines and relates concepts such as Agents
> (hardware, software, people), Events (digitization, transcoding,
> film, etc). It could be feasible to simply determine a method of
> documenting this data in PREMIS XML and then store that as an
> attachment, though I think it makes it more accessible as a set of
> Matroska metadata tags.

The good thing about PREMIS (as far as I understand it) would be that it
has a very flexible structure. In the film scanner example the video
frames may be digitized on machine A, the audio part may be digitized
by some different hardware B and both is later joined into a single MKV 
file by software C. The structure of PREMIS allows to describe this 
relationship between A/B/C.

The bad thing about PREMIS is that while its structure is quite 
elaborated the specific details to be stored are not (IMHO).

> <https://archive.org/download/MatroskaSampleWithEmbeddedPreservationMetadata/pres_metadata_sample_20110608.mkv> which
> attaches a photo of the source tape and adds process metadata. Here's an
> output of that metadata from FFmpeg.
>
>   Metadata:
>     ORIGINAL_MEDIA_TYPE/BARCODE/source: {name of barcode authority
> or creator; example "XYZ Archive Barcode"}
>     ORIGINAL_MEDIA_TYPE/DATE_RECORDED: {The time that the recording
> began. This is akin to the TDRC tag in ID3.}
>     ORIGINAL_MEDIA_TYPE/condition: {Comments on the condition of
> the source, any preparation for playback of the source tape (if relevant).}
>     ENCODED_BY      : {Name of the technician or organization
> responsible for the encoding and file creation process}
>     ENCODED_BY/processing_actions: {Description of any actions
> performed during processing, such as trimming silence.}
>     ENCODED_BY/playback_device/playback_signal_path: {Protocols used
> to transfer audiovisual data between the playback deck and the
> capture device. example: Component}
>     MAJOR_BRAND     : qt
> history) worthwhile to include in CELLAR work?

I think that finding/building the one-and-only process metadata standard 
for audio/video archiving might take some time and it can be separated 
from the work on the file format itself.

> existing metadata standards as attachments?

Because of the above argument I'd propose to focus on adding such 
metadata as attachments.

> Matroska metadata tags so that externally defined standards may be used
> within Matroska metadata directly?

Not sure. What would be the benefit compared to directly prefixing the 
tag name (e.g. "noa:archive_signature" or "noa_archive_signature")?

BTW: I like the uppercase => official tags, lowercase => local tags 
convention.

> - And .... what metadata values are needed?

Yeah, that would take the most discussion time. First the list of 
entities that are part of the process needs to be defined ("actors" or 
"roles") like hardware (computer, replayer, A/D converter), software 
(OS, ingest application, transcoder, quality check) and users (ingest 
operator, visual inspector).

Then there needs to be some way to describe how each step of the process 
builds on other steps. This can be linear (like in BWF or reVTMD), 
tree-like or even freely linked (like in PREMIS).

Best regards,
Tobias