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 :)

Tools & reverse engineering

Nick Shaw said:
Not completely simple, as I believe audio at 48KHz does not work out as an exact number of samples per frame at 29.97 fps or 23.98 fps. There is a pattern set down by SMPTE, based on timecode, used to vary how many audio samples pair up with particular video frames. (See p327 of the FCP manual for details)

Much easier for us Europeans at 25fps, which fits exactly!
Click to expand...

Interleaving audio within in video is the only place where this would be a concern and, even then, is easily handled. Again, audio doesn't need embedded time code as long as we are talking about uncompressed PCM (which is what RED will be storing) as it has a fixed sample interval and a fixed word length. In any conform audio would be a separate asset. Even with an interleaved delivery format (such as QT or AVI) audio does not require any timecode (it may display in units that are timecode, but its not required within the samples).

How any NLE chooses to handle it is specific to the NLEs nature (such as the FCP example you site) but not for the actual audio data. Regardless of PAL or NTSC frame rates, audio has a sample rate which is independent of frame rate.

Also, just as an aside, the use of a unit of frequency "Hz" or "kHz" in listing sample rates is not an ideal choice (though very common). The preferred unit is Samples/second listed as S/s or kS/s.
 
For audio, you could offer the ability to extract it un-modified as bwfs.
The file size of the audio is not an issue here, so there is no need really to enable modification. And with the embedded bwf timecode it should be easy to get it to sync up using custom tools.

Again of cause this still depends on how exactly audio is handled.
 
Thanks Rob I look forward to more RED goodness.

I don't have a problem with dropping audio or keeping it. It's only a few hundred KB per frame even with it being uncompressed. However if dropping it is easier that's fine too. Like Mark said it's at this point almost exclusively for splitting off sequences for compositors so that they can extract the best possible r3d file for their purposes and not having to mail a 500GB hard drive when you could get it up on an FTP server in a couple of minutes.

But I'm also going to repeat my request for something like REDAlert for PC with basic command line support (even if you're limited to burning in the color from a previous session). Personally I would rather see that in the immediate future (1-3 months) than continued REDCine development especially if developing a REDCentric pipeline isn't recommended at the current time and people need to rely on their current bag of tricks.

P.S. Mark glad to hear you're going to press forward on the EDL parsers. That was the part I was most excited about anyway. ;)
 
Anders Holck said:
For audio, you could offer the ability to extract it un-modified as bwfs.
The file size of the audio is not an issue here, so there is no need really to enable modification. And with the embedded bwf timecode it should be easy to get it to sync up using custom tools.

Again of cause this still depends on how exactly audio is handled.
Click to expand...

I was thinking the exact same thing. I was just wondering if you can just export bwfs from the QT wrapper with embedded TC? Can you do that now with a standard self-contained QT w/audio? Have not tried. Now that Final Cut FINALLY reads the meta-data from BWF - exporting BWF from .r3d with TC is .... well ... pretty damn handy. No pressure Rob, just feedback and ideas.:w00t:
 
The additional information that is contained in the broadcast wave format's header as opposed to wave or aiff formats is of limited value for PCM data; but since the hit to the overhead is so insignificant, I have no objections as long as the data is stored as uncompressed PCM.

.bwf, .wav, .aif, are all fine as getting from anyone to another is trivial.

Form nearly any purpose that I can think of needing now is a tool that extracts a specified number of video frames from a .r3d and writes them out to a new .r3d file, anything else would be great, but I would rather see a simpler tool sooner than a more complex one later.
 
offhollywood said:
AUDIO:
For now, I think it would be okay to just drop the audio in the truncated clip as everybody is double-system now anyway. That being said, and I understand it's a time/resource thing, you should be able to truncate the audio in sync and write that to the new file. You'll need to do this, but I think you calm the angry villagers (I'm kidding here) with a command line that truncates and just drops audio.

I am unaware at this time if the audio data is in fact in INSIDE the .r3d file as opposed to a separate linked file inside the .r3d folder. Very curious if your audio data has it's own TC data. Looking forward to seeing how you deal with audio.

FILE NAMING:
I would add the letter T (for "trimmed" or "truncated") and then KEEP the reel + clip naming convention on the truncated clip followed by a USER DEFINED extension.

T_A001_C001_fx102.r3d

so, every .r3d that has a "T_" in front of it is an "altered" .r3d - and can never be confused with a "camera original"
Click to expand...

I know this is getting out of the range of a simple 'trim' tool. But for the sake of having the conversation now rather than later, it would appear that this functionality would eventually become the base core of either a pull-list or even onlining type function. Correct me if I'm off base here, but if a tool (like yours for example Mark ?) has access to this from the command line, and we can feed it an EDL, then we can create an online folder of R3D files, along with a new EDL, right ? From there it's just one step (and a command line driven batch convert functionality from RED) to convert that new EDL and folder, to a conformed folder full of DPX files .. Just thinking out loud, and not thinking about audio at this point.

My point is, if we are to access this functionality at SOME POINT down the track with either an EDL or a PULL LIST, then we might/will have overlapping sections to be extracted. We will need to extract multiple R3D's from one single R3D for example. Now we don't NEED this NOW, but again.. I'm just thinking out loud. Maybe a file naming convention that would allow for this at least ? I don't know if maybe it needs timecode in the name or some kind of other variable ?
 
The *optimal* solution would be for RED not to decide for us what to call it but give us flags like:

trimmer.exe -output "\\user\folder\%Filename_%Date2_s%Start-e%End.r3d"

That way your EDL tools could instruct RED what to call it and where to put it and rename it based on the metadata.

If RED knows the offsets for all of the meta data, exposing it in the file name should be peanuts.
 
Seth Larney said:
My point is, if we are to access this functionality at SOME POINT down the track with either an EDL or a PULL LIST, then we might/will have overlapping sections to be extracted. We will need to extract multiple R3D's from one single R3D for example. Now we don't NEED this NOW, but again.. I'm just thinking out loud. Maybe a file naming convention that would allow for this at least ? I don't know if maybe it needs timecode in the name or some kind of other variable ?
Click to expand...

well ... you need to think of filenames as COMMENTS.

The real goods are in the REEL# and the TC.

RED has the REEL # in the filename AND the meta-data - which is very cool.

So, extracting multiple .3rd from a longer one is just like capturing a bunch of clips off of a tape.

The EASIEST way to stop a bunch of people from screwing up is to ALLOW USER to CHANGE THE REEL # in the new clip if they need to.
 
offhollywood said:
well ... you need to think of filenames as COMMENTS.

The real goods are in the REEL# and the TC.

RED has the REEL # in the filename AND the meta-data - which is very cool.

So, extracting multiple .3rd from a longer one is just like capturing a bunch of clips off of a tape.

The EASIEST way to stop a bunch of people from screwing up is to ALLOW USER to CHANGE THE REEL # in the new clip if they need to.
Click to expand...

Agreed
 
offhollywood said:
this scares me a bit - we work in such a "FTP me the clip" world - AND you will often (for FX) have a reason to make MULTIPLE "sub-clips" from one .r3d - I could live with a .1 .2 .3 but then you need a database that remembers how many clips you already made from that .r3d file - BEST answer IMHO is user defined extension following original reel# + clip# after a identifier (that it is not an original file) like "T_" - although I do like your folder structure
Click to expand...

I think we're basically saying the same things. I don't really have any problem with appending the original file name with a "trimmed" identifier. But although I think it's a noble attempt to try to automate and organize things like VFX shots, it doesn't have a lot of meaning when the final composites come back and hold none of the original plate metadata and with names that don't relate to what you called them. Any conform is always going to contain elements that need to be eye matched, be they VFX shots, stock footage, graphics/animation elements, or what-have-you.
 
mmost said:
I think we're basically saying the same things. I don't really have any problem with appending the original file name with a "trimmed" identifier. But although I think it's a noble attempt to try to automate and organize things like VFX shots, it doesn't have a lot of meaning when the final composites come back and hold none of the original plate metadata and with names that don't relate to what you called them. Any conform is always going to contain elements that need to be eye matched, be they VFX shots, stock footage, graphics/animation elements, or what-have-you.
Click to expand...
Agreed.

But things will change. You can count on it. Meta-data is the future (of faster, more efficient workflows and the filmmaking process). I STRONGLY believe you will see more and more VFX shots come back WITH the proper meta-data. Part of the reason you don't, is the pathetic "Frankenstein-ed" post pipelines even the "best of the best" and "big guns" use. I see tremendous opportunity with RED to create powerful workflows and pipelines that change the rules. But you are 100% correct, conforms will ALWAYS have elements that need to be eye-matched.

I am very into the concept of the filename INCLUDING an identifier to the original file - reel# + clip# - so, even if I choose to change the REEL# - to fx01 or whatever - I can always see by the filename where it originated.

PS - someone needs to start a thread called - "Don't ask mmost and Offhollywood ANYTHING 'cause they will tell you ANYWAY."
 
mmost said:
I think we're basically saying the same things. I don't really have any problem with appending the original file name with a "trimmed" identifier. But although I think it's a noble attempt to try to automate and organize things like VFX shots, it doesn't have a lot of meaning when the final composites come back and hold none of the original plate metadata and with names that don't relate to what you called them. Any conform is always going to contain elements that need to be eye matched, be they VFX shots, stock footage, graphics/animation elements, or what-have-you.
Click to expand...


I haven't worked _directly_ in large facility vfx pipelines in a couple of years, but when I did, metadata was not a spec in any pipelines on productions I was involved with.

But, that's something that could be fixed pretty easily on a facility basis, and as a producer I would definitely make part of my package for bids to outside (or even internal) post production.

Most vfx facilities I've worked with use asset tracking database systems, so it'd be a piece of cake maintain plate metadata through out the pipeline via this database (I'm picturing a world where different software possibly strips the metadata, so keeping it outside the artists' tools would be the safest), and then re-integrate it to the final output files (dpx, exr, whatever) via script flavor of choice. The script would be the final step in internal shot management.

This would be very easy to implement in any size facility with a simple post-processing script in whatever software is used to render the final comp.


cheers,

jt
 
lunacie said:
(I'm picturing a world where different software possibly strips the metadata, so keeping it outside the artists' tools would be the safest), and then re-integrate it to the final output files (dpx, exr, whatever) via script flavor of choice. The script would be the final step in internal shot management.
Click to expand...

Coming soon my friend.
 
offhollywood said:
this scares me a bit - we work in such a "FTP me the clip" world - AND you will often (for FX) have a reason to make MULTIPLE "sub-clips" from one .r3d - I could live with a .1 .2 .3 but then you need a database that remembers how many clips you already made from that .r3d file - BEST answer IMHO is user defined extension following original reel# + clip# after a identifier (that it is not an original file) like "T_" - although I do like your folder structure
Click to expand...

Whoops, sorry Mark. I missed this post before I posted my suggestion .. this is essentially exactly what I meant.

Cheers,
Seth.
 
1) what do we do with audio and keeping things in sync? Would it be okay to simply drop the audio for the new clip?
Click to expand...

If we can demux the audio in REDCINE and export it on its own, then we can cut it with other tools, so dropping the audio seems OK.

The user would provide the file name, mark in and mark out on the command line and it would run. Is mark in and out in frame number, time code or both? The output file name could be the input file name + the mark in and out.
 
I'm pretty sure audio will be dropped in a first release. Just to keep it simple and get everyone going.

I'd also like to keep it as simple as possible so we can quickly release something instead of doing another full featured application.

We take all your feedback extremely serious. I do like to keep it plain and simple and adding more features over time.

Cool?
 
Rob would it be ok to post any trimmed LART footage as long as the tools aren't released? Would that be a fair compromise? (Assuming I could get a trimmer working tomorrow.)
 
Hey Rob,

I too am total cool with the idea of dropping audio and keeping the tool extremely simple. No need for any GUI, just command line would be fine (and preferable as far as I am concerned). Assuming its coded in something generic, I assume that it can be compiled for both Mac and PC platforms?

Kevin
 
You must log in or register to reply here.
Back
Top