Creative Communities of the World Forums

The peer to peer support community for media production professionals.

Activity Forums Square Box CatDV cataloging question not specific to CatDV

  • cataloging question not specific to CatDV

  • Paul Dougherty

    January 18, 2021 at 6:19 pm

    I have a cataloging question that is probably not specific to CatDV. I’ve been an Avid editor for decades and now more involved with video archiving. I put this question out to archival colleagues but also wanted to include post-production people.

    Is there a protocol for cataloging camera cards where each record describes an entire card, but there is a provision (but not a requirement) to go more granular? (All my examples involve documentary b-roll.)

    For example a camera card that has 40 minutes of similar footage, no granularity required. However a 2.5 hour card might have a great variety of footage and there might be a desire to identify/describe subsets or clusters of like-footage. I am just starting work on developing a database that will not likely ever be used to log individual clips.

    If one were to think formally of this as a data model, cards and clips are fixed entities, subsets of a card are pretty subjective. Thanks in advance for any help.

    Best,

    Paul

  • bryson jones

    January 19, 2021 at 2:32 am

    imho and the opinion of Sony (for one example) for any ENG (not cinema) format, camera cards are an acquisition format, not an archival format. Rewrap (not transcode unless you want) out of XDCAM, P2, etc asap. There’s no good reason to keep the cards intact and many good ones to not. CatDV (and other software) can extract the metadata and keep it with the new rewrapped mp4, mxf, or mov files.

    As to cinema cards, this is one I can’t really comment on due to the fact that I’ve never been hired to work on them. But I will say, as you know, the major film archives are storing dpx sequences. Not sure if they are converting RED and similar to dpx for this (sources) but masters are done this way.

    I’m personally outraged that the camera companies made these formats with little to no thought given to the archiving of these cards and media. They dropped a huge issue into the laps of shooters and content owners and took the money and ran.

    I hope someone can manage to answer this in the next round of formats.

    As to the data model, in CatDV, for example, this is accomplished by recording the “card” as an object and then clips underneath it. This is a relatively simple relationship, but it works fine. I’d assume that this idea is as old as a reel of film that can contain several scenes and your archival friends will show you how this is done in “real” archives. (Post people never get to seriously archive at a level of say a film librarian or someone from one of the studios.) I’m teasing of course but as you know, when you get to the true high end of the business, post and archive are often separate departments and post is simply delivering to the archive team.

    Hope this helps and I hope smarter people than I post up as well!

  • Paul Dougherty

    January 19, 2021 at 1:53 pm

    Hi bryson, this is great! While you make a good point about re-wrapping cards for the archive I’d love to save that for another thread.

    Even though it would be valid as a data model having a bunch of clips selected and listed in a card record (or under that “umbrella”) it might make the record a hard browse. Though if my organization one days okays a much more ambitious clip level description effort, this design would probably scale well. More likely one would want to define/describe sections of ‘like’ footage, call them clusters or as you say scenes. These would be represented by time code or maybe clip # ranges or brackets.

    One of the main things I’m wrestling with is a subjective nature of going more granular in the card description. In real life different catalogers might overdo it or under-do it resulting in a catalog that is inconsistent, neither fish nor fowl.

Viewing 1 - 3 of 3 posts

Log in to reply.

We use anonymous cookies to give you the best experience we can.
Our Privacy policy | GDPR Policy