Welcome to our community

Be a part of something great, join today!

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

Hyperdeck Shuttle file naming duplicates and Avid.

Dominik Rippl

Well-known member
Joined
Jan 3, 2008
Messages
97
Reaction score
0
Points
6
Location
London, UK
Hi,

I was wondering how people were getting around the fact the Hyperdeck Shuttle resets the file name back to 0 on each new roll (SSD) recorded, resulting in duplicate file names?

What's the best solution working with this in a post workflow?

I've searched everywhere but no one seems to be talking about it. I've just handed over 4 days worth of rushes (about 14 rolls/SSDs worth) and the post house is complaining its lots of work having to rename the files to get it into Avid. I presumed they'd import the same file structure (dividing it into rolls) as the DIT setup in the avid but they say they can't (I don't know how avid works, I know it would be straightforward in FCP 7) as all the files have to be imported from one folder...?

Anyway the whole point of recording to the Hyperdeck (on DNxHD) was to make the post quick and simple, because of this issue it hasn't been. I'd like to find out for future jobs.

Many Thanks

dom
 
Are the files .mov (QuickTime wrapped DNxHD) or are these native MXF wrapped DNxHD? I have not come across files from Hyperdeck, so I cannot comment with first hand experience. Importing is importing, what is the filename at the directory/folder level? Are they using AMA? If so, the file name in the folder is the filename used. If you want to share two files showing this, I'll be glad to take a peek.

Michael
 
I was wondering how people were getting around the fact the Hyperdeck Shuttle resets the file name back to 0 on each new roll (SSD) recorded, resulting in duplicate file names?
Is it possible for the DIT or camera assistant to manually rename the new file name before it's recorded? Does the next file name automatically increment to the next number? You would expect it to do this, but I only have experience with the PIX240.
 
Are the files .mov (QuickTime wrapped DNxHD) or are these native MXF wrapped DNxHD? I have not come across files from Hyperdeck, so I cannot comment with first hand experience. Importing is importing, what is the filename at the directory/folder level? Are they using AMA? If so, the file name in the folder is the filename used. If you want to share two files showing this, I'll be glad to take a peek.

Michael


Michael,

The files are DNxHD MXFs.

On the hyperdeck each time you put in a new/formatted drive it resets the naming structure to 0.

For example:
Roll01/v0000Capture.mxf
v0001Capture.mxf
v0002Capture.mxf
.....

Roll02/v0000Capture.mxf
v0001Capture.mxf
v0002Capture.mxf
.....

So the individual file names are the same but they are separated into roll folders. I was told that they couldn't distinguish rolls in their import method (as all the clips went into one folder) so they had the very boring task of importing each roll separately and renaming it. I don't know avid but I'm sure there has got to be a better way of doing it.

Thanks

dom
 
Is it possible for the DIT or camera assistant to manually rename the new file name before it's recorded? Does the next file name automatically increment to the next number? You would expect it to do this, but I only have experience with the PIX240.

Marc,

There is no way to manually adjust the file naming on the hyperdeck. It automatically increments and starts at 0 when a new card goes in.

Thanks

dom
 
Wow thats quite a missing feature...
 
Marc,

There is no way to manually adjust the file naming on the hyperdeck. It automatically increments and starts at 0 when a new card goes in.

Thanks

dom

Can't you rename the files at the OS level to whatever you want them to be before importing into MC? I know that's a hassle, but I would think renaming before bringing them into MC would be better than doing the renaming inside MC after the import.


P.S. BTW, do you know if the MXF files are Op1a or Op-Atom? I've read that they are Op-Atom. But that would mean, IIUC, each clip would have separate MXF files for each video and audio track. I don't believe that's how the Hyperdeck MXF files are constructed. Aren't the video and audio for a clip stored in just one MXF file? If its one file per clip then, IIUC, that would mean they are Op1a.

P.P.S. The reason why I bring this is up is b/c, IIUC, Op-Atom MXF files are added to MC by dragging them directly into the Avid MediaFiles folder or a subfolder of this folder. While MXF Op1a files are brought into MC by AMA linking or draging them into a bin.
 
Again, not having direct experience with the files themselves, I am shooting in the dark a little here. Thanks for the naming file structure. Are you accesing these files via the AMA MXF plug-in or dropping them directly into the Avid MediaFiles/MXF/"number' folder structure? I suspect the former. If so, I don't believe Media Composer, nor AMA look to folder name to create a source ID. In this case, it can be solved either by Blackmagic changing their naming structure so that for each time a drive is inserted the count is reflected in the filename - to use your example:

Roll01/v0000Capture.mxf
v0001Capture.mxf
v0002Capture.mxf
.....

Roll02/v2000Capture.mxf
v2001Capture.mxf
v2002Capture.mxf


Or, if accessing via the AMA plug-in, that it be updated to use Roll02/ as part of the REEL ID. The issue here is that everyone downstream (in and out of Avid) use the same REEL structure which cannot always be guaranteed. I am told that Avid and Blackmagic are working closely together, so perhaps this is being looked at already, or contacting either one would help accelerate an update. If being used as a proxy to a RED camera, then getting file name into the stream of the R3D would solve the file naming problem in this particular case.


Michael
 
Michael,

If using them as a proxy for Red files, would renaming at the OS level the MXF's to match the names of their .R3D counterparts help solve the problem with conforming back to the original .R3D's?
 
Can't you rename the files at the OS level to whatever you want them to be before importing into MC? I know that's a hassle, but I would think renaming before bringing them into MC would be better than doing the renaming inside MC after the import.

Yes that's what they've been doing but it kinda defeats the point of a quick and easy workflow...
 
P.S. BTW, do you know if the MXF files are Op1a or Op-Atom? I've read that they are Op-Atom. But that would mean, IIUC, each clip would have separate MXF files for each video and audio track. I don't believe that's how the Hyperdeck MXF files are constructed. Aren't the video and audio for a clip stored in just one MXF file? If its one file per clip then, IIUC, that would mean they are Op1a.

P.P.S. The reason why I bring this is up is b/c, IIUC, Op-Atom MXF files are added to MC by dragging them directly into the Avid MediaFiles folder or a subfolder of this folder. While MXF Op1a files are brought into MC by AMA linking or draging them into a bin.

The Hyperdeck shuttle creates 3 files for every clip, 2 audio and 1 video. Which would mean they have to be added in this method - "Op-Atom MXF files are added to MC by dragging them directly into the Avid MediaFiles folder or a subfolder of this folder". The post house tells me that avid takes it all in from one folder - I assumed each folder could in distinctly/kept separate so that the duplicate file names would not cause a problem...

dom
 
Yes, ideally BMD will change the file naming options (give some options) but for the present time I was looking for a work around that hopefully didn't involve renaming all the files.

Other edit systems you can import a folder of clips which stops any clash.

Also I should point out that this workflow (using the hyperdeck) is for quick turnaround jobs that treat the MXF as the master (online all the way if you like) and there is no need to relink to Red files.

Thanks

dom
 
The Hyperdeck shuttle creates 3 files for every clip, 2 audio and 1 video. Which would mean they have to be added in this method - "Op-Atom MXF files are added to MC by dragging them directly into the Avid MediaFiles folder or a subfolder of this folder". The post house tells me that avid takes it all in from one folder - I assumed each folder could in distinctly/kept separate so that the duplicate file names would not cause a problem...

dom

Thanks a lot for the info. So these ARE Op-Atom! Which means they are used directly by MC and, as such, their names have to be unique. Now you can create subfolders inside the Avid MediaFiles folder, but I honestly don't know if that would allow duplicate MXF file names as long as the files are in different subfolders.

But the Hyperdeck's naming is so generic, don't you really need to change the names to something more meaningful anyway, like scene and take number?

Now I could see how changing three files per clip would be an extra hassle, but you could instead create DNxHD QT's, which can be "fast imported" into MC. "Fast importing" is a special type of importing in MC that does not transcode; rather it creates Op-Atom MXF files from the source file. So fast importing a DNxHD .MOV will take a few seconds to less than a minute per file.

If you use QT's, you will have to only change one file name per clip instead of three. And once the QT's are fast imported, the QT files are no longer needed by MC.

Hope that helps.

But I do of course agree that it would be nice to be able to change/set file name with the Hyperdeck Shuttle.
 
You're very welcome.
 
I am curious as to the UMID used to make the files unique, since the original issue posted is that Media Composer sees files as "dupes" of each other which uses REEL (Tape) and timecode to define what an overlap might be. So while the .MXF files can be managed in numbered folders within the MXF folder, the source ID is still the same somewhere causing the dupe detection to light up. And thank God you don't need to conform these in a different system with an EDL... ;)

Michael
 
Michael,

Would it be correct to think that it would, as a general practice, be better to fast import DNxHD QT's then to use Op-Atom MXF's created outside of MC?
 
"Better" is difficult to define - in the end there is no difference to the resulting look or quality. Fast import gives you the advantage of targeting the bin and project directly via the import. I am not the biggest fan of QuickTime because it tries to be too smart with levels and gamma depending on codec, so in the end it may be a wash. Personally if I have the choice between MXF native DNxHD and QT wrapped DNxHD I'll go MXF.

Michael
 
Michael,

Let me expain why I asked about QT's potentially being better. Where I get concerned with using Op-Atom MXF's made outside of MC is the whole issue of unique UMID's. I know that if MC rewraps a batch of QT's as Op-Atom MXF's, the UMID's will all be distinct, b/c MC is creating the UMID's.

As for color shift, I agree that it can be a RPITA. But some combinations of camera and DNxHD encoder do not cause color shifts. If that happens to be the case, then it seems to me that using QT's would be a better choice. B/c this way I'm leaving the media management completely to MC.

Makes sense?


P.S. BTW, who do we have to call at Avid to get back there ASAP?
 
I can see your reasoning, which I think may make sense depending on the system making the MXF native files. Many application that make dailies such as Resolve, Redcine X Pro, Colorfront, etc. all use an SKD from Avid called AMT (Avid Media Toolkit) that takes an input file and XML and exports out the AAF and MXF DNxHD. So in essence, in those scenarios, the UMIDs are being generated by Avid. Not that AMT doesn't need a few teaks to make it better for some workflows, but the files created from AMT are native Avid by Avid.

So I rectify my stance, that if the application generating the DNxHD is not using AMT, then I agree that QT wrapped and letting Avid rewrap and manage is probably a better way to go. If it is using AMT, then the process is pretty streamlined and I prefer to go native MXF.

I will also add that the ALE generation from Redcine X Pro is Red's doing as that it not part of AMT - and the parsing and tracking of metadata is nicely done. It too needs a few tweaks for audio workflows, but all in all, it's all there.

As far as who to call at Avid? I don't know - most of the people I knew are no longer there. :(


Michael


Michael
 
Back
Top