Welcome to our community

Be a part of something great, join today!

Log in
  • Hey all, just changed over the backend after 15 years I figured time to give it a bit of an update, its probably gonna be a bit weird for most of you and i am sure there is a few bugs to work out but it should kinda work the same as before... hopefully :)

Pull List

MichaelP said:
OK - but it might be a nice piece of additinal metadata to indicate whether the file is made up of two or more clips and eventually an indication to the original clip itself should another conform box be used (assuming that other vendors get access to the r3d files...).

Michael
Click to expand...

How does the _001 clip know if there will be an _002 clip? How does the _002 clips know if there will be an _003? Are you suggesting recording metadata into clips after the fact?

Or the cards could just be formatted as FAT32. :)

Lucas
 
luki said:
How does the _001 clip know if there will be an _002 clip? How does the _002 clips know if there will be an _003? Are you suggesting recording metadata into clips after the fact?
Click to expand...

In fact it does know this (no joke). The file format is quite a bit more complex then some have alluded to :)

I'm not sure I'm following what people want to do with this info though.... can someone educate me on the need for this with a conform?
 
Rob Lohman said:
In fact it does know this (no joke). The file format is quite a bit more complex then some have alluded to :)

I'm not sure I'm following what people want to do with this info though.... can someone educate me on the need for this with a conform?
Click to expand...

Rob - I don't NEED it for a conform.

I'd LIKE it so that in an asset management world, when NEW truncated clips, or VARIOUS EXPORTS or even NEW .r3d files are created on a NON FAT32 formatted drive - it would be handy, TRUST me.

Bottom line - I can identify which clips are and make my own flag in my (currently building) database/tool application - but much cooler to just see a flag in the .r3d file.
 
MichaelP said:
I agree that for final conform the pull list generating new r3d files will not have the same issues as pulling dailies for editorial, but all the same, any subset of an original r3d file should maintain the same metadata and not start counting over - right now it appears as the frame counter and the individual clip timecode both start at 0 and 00:00:00:00 respectively.
Click to expand...

Sounds like you do not have REDCINE set to source timecode (S_TC). We have two timecode tracks, one starts at 01:00:00:00 for the first clip on the magazine. The second track is either time of day or whatever it was jam-synced to.

Each frame has the correct timecode so timecode (or frame count) does not reset per 2 GB "chunk".

MichaelP said:
A question I have on the spanned 2GB files is when referencing a source in an EDL or XML, should it always refer to the original file and let the timecode determine whether it jumps to the second file (assuming 2 files of 2GB each)? Or should a single take refer to the original file name with _001 and _002 when referencing back to the original r3d? It's a matter of retaining history of the file through all its permutations that I am trying to anticipate.
Click to expand...

Ideally the reference should be to the folder (the one that ends in .RDC), since that's what a clip really is. Otherwise I would store the base name (the part before _001, _002 etc.). Then it doesn't matter how much chunks a clip consists of and you're always talking about the full clip.

We're working on making this much more consistent in our own tools as well.
 
Offhollywood said:
Rob - I don't NEED it for a conform.

I'd LIKE it so that in an asset management world, when NEW truncated clips, or VARIOUS EXPORTS or even NEW .r3d files are created on a NON FAT32 formatted drive - it would be handy, TRUST me.

Bottom line - I can identify which clips are and make my own flag in my (currently building) database/tool application - but much cooler to just see a flag in the .r3d file.
Click to expand...

It's already in there. Talking about generating new r3d files to truncate clips etc. there's no history on what to do. This is one of the many reasons why we pleaded to people to let us build this specific tool so we can make all of this work properly.

An idea I've had for such a tool was to add a history record so you always know where a clip came from. Especially important if you go over 2 GB (which I think would require a file format change, by the way!).

On the surface it looks easy, but there's lots of little snags you run in to.... Anyway, the most important thing is that we've designed a very flexible platform so all of this is possible. Just have to give us a wee bit of time :D
 
Rob Lohman said:
It's already in there. Talking about generating new r3d files to truncate clips etc. there's no history on what to do. This is one of the many reasons why we pleaded to people to let us build this specific tool so we can make all of this work properly.

An idea I've had for such a tool was to add a history record so you always know where a clip came from. Especially important if you go over 2 GB (which I think would require a file format change, by the way!).

On the surface it looks easy, but there's lots of little snags you run in to.... Anyway, the most important thing is that we've designed a very flexible platform so all of this is possible. Just have to give us a wee bit of time :D
Click to expand...
100% Understood Rob. This stuff is FEEDBACK.

As for a "history record" - yes, that's 100% needed in a an asset management world - but that does NOT need to be in a.3rd file (and I don't think should be - it's in a project database.)
 
The metadata for multiple clips is in filenames :)

More importantly, I think you'd want to store the #frames and total size
of the original aggregate clips vs the new trimmed clip.

You also have to be careful with large files. even though you may be on
a filessytem that can handle it, not all program may be handling them
properly. Meaning, while the file system can store it, the programs maybe using 32bit file handling. (like windows programs or 32 bit versions of samba, nfs, cifs, ftp, etc.)
 
I think filenames are a very fragile way to work and was wondering if there was a repair file to original name program that would allow it to be reset as though it came from camera. Also, I only have two beta files I am working with so I have no concept of what a typical folder/file set looks like when coming in directly from the production into post. I am trying to anticipate all the ways files will get manipulated through post, and as I know from experience and design of post workflows, one must anticipate all worst case scenarios and not only the single ideal one.

I do have Source TC set and the "subclip" does have the correct timecode as far as time of day is concerned. My comment is that since the other metadata is also being maintained and allowed to be burned in, it can have use in propagating its position from the original source clip by not starting over at 0 for frames and 00:00:00:00 for timecode. Also the need for consistency in the frame count overlay matching throughout the application as being frame 0 or frame 1 for first frame.

Michael
 
MichaelP said:
I think filenames are a very fragile way to work and was wondering if there was a repair file to original name program that would allow it to be reset as though it came from camera. Also, I only have two beta files I am working with so I have no concept of what a typical folder/file set looks like when coming in directly from the production into post. I am trying to anticipate all the ways files will get manipulated through post, and as I know from experience and design of post workflows, one must anticipate all worst case scenarios and not only the single ideal one.

I do have Source TC set and the "subclip" does have the correct timecode as far as time of day is concerned. My comment is that since the other metadata is also being maintained and allowed to be burned in, it can have use in propagating its position from the original source clip by not starting over at 0 for frames and 00:00:00:00 for timecode. Also the need for consistency in the frame count overlay matching throughout the application as being frame 0 or frame 1 for first frame.

Michael
Click to expand...

Michael,

I addressed the "two beta clips" issue offlist. Check e-mail. You're right that filenames are fragile - but the original filenames are also embedded as metadata in the R3D files - which cannot be changed.

Lucas
 
Good. Now a feature request would be to "restore" filename from that metadata! ;)

Feature requests never end... ;)

Michael
 
MichaelP said:
I think filenames are a very fragile way to work and was wondering if there was a repair file to original name program that would allow it to be reset as though it came from camera. Also, I only have two beta files I am working with so I have no concept of what a typical folder/file set looks like when coming in directly from the production into post. I am trying to anticipate all the ways files will get manipulated through post, and as I know from experience and design of post workflows, one must anticipate all worst case scenarios and not only the single ideal one.
Click to expand...

Michael knows from whence he speaks. There are a number of reasons why Avid's media management is considered so robust and Final Cut's is often called "media mangler". And the reliance on filenames is a major part of the problem. Relying on filenames is "Apple thinking" - in other words, consumer, not professional. Based on best case scenarios ("do this and everything will work") rather than worst case scenarios (i.e., the real world). Let's not fall into that trap with them.

Having said that, Lucas has pointed out that the file name is also included in the file itself as metadata. That's good. And it's "professional thinking."
 
mmost said:
And the reliance on filenames is a major part of the problem. Relying on filenames is "Apple thinking" - in other words, consumer, not professional.
Click to expand...

True. This has been a source of confusion for me (an "Apple thinker") before. I had thought that during a conform, you needed to keep the same file names.
 
Curran Giddens said:
True. This has been a source of confusion for me (an "Apple thinker") before. I had thought that during a conform, you needed to keep the same file names.
Click to expand...


Which doesn't work if you change, say, a clip name to better represent the shot (i.e., 23A-4 rather than A001_C095_070912) and you happen to do it on a master clip, thus breaking the relationship to the original file. What Avid did - from the beginning - was to create a media database from metadata in the files it creates. It then connects those media files to the clips in your bins. If you change the name of the clip - or a subclip - it never touches the name of the media file it points to. If the database is corrupted - or even deleted - it rebuilds itself. The files know what project they were digitized for and when. This lets editors work in whatever way is convenient without having to be concerned about "computer stuff," and allows things like recaptures for online to proceed with very few problems.

That's what I meant.
 
You must log in or register to reply here.
Back
Top