[Gregg Michaels]

Hi Floh. Actually, I just figured it out. For some reason, batch re-acquire does not like using hd-sdi-2 as the input. This input was working fine for my normal acquisition, only when I was trying to use the batch procedure did I have the problem. When I moved my input to hd-sdi-1 on the kona breakout box, everything behaved normally. Interesting though, when I would use the batch acquisition on input 2, when it cued the tape, I could see the first frame, when I hit “ready” is when I lost my signal. Maybe the M100 guys can confirm this.

GM

[Gregg Michaels]

If you’re using Compressor, you might want to make sure that under “av attributes” that your source file is showing the correct field dominance before encoding.

GM

[Gregg Michaels]

OK. Thanks for the explanation Floh. I just wanted to make sure that I understood why things were happening the way they were.

GM

[Gregg Michaels]

OK, here are the results. When I use your method, only the edit that is assembled on is timecode accurate, and when I try to assemble the entire program with leader, the deck won’t even roll. I think that the issue is the lag time from when the laser actually starts burning on the in point, and I just couldn’t get the deck to use the timecode that was being sent from Media100. BTW, I got identical results from FCP.

So my solution which has worked 6 times now, was a setting on the deck itself. After breaking out the manual, I realized that on the Timecode Generator menu, usually just int/ext options, there was a secret option c- sdi. This forced the deck to record the timecode from the hd-sdi signal, which was correct no matter when the recorder actually started burning.

I don’t know if this helps anyone else out there, but that has definitely worked for me.

Thanks for your help Floh.

GM

[Gregg Michaels]

Thanks for the response Floh. I just didn’t expect to see a jump when the entire project is already in the pro-res codec. Just so I’m understanding this, Media100 is capturing everything in “studio rgb”. So when I export either by reference or self-contained, I’m still in the 16-235 color range. And when you import a quicktime, any quicktime, Media100 is assuming that your importing computer rgb- 0 to 255. Does that sound right to you?

GM

[Gregg Michaels]

Thanks Floh, I’ll give that a try and post back.

GM

[Gregg Michaels]

Thanks for the response. I’ve actually tried all the different preferences, with no success. Also, I have about thirty of these Media100 generated color clips, and editing each one individually wasn’t my favorite option. Maybe the folks at Media100 can add this preference to the existing replace media procedure.

GM

[Gregg Michaels]

Thanks Wick.

GM

[Gregg Michaels]

Hi Wick. Sorry, I’ve been out of touch until today. I’ll have to post the file to our website, and I’ll email a link to support. It sounds like the same problem that’s listed as a fix in Suite V1.01.

Thanks!

GM

[Gregg Michaels]

Hi Wick. Actually, I did try his workaround, but I still have the same problem. When I drag the clip from the bin to the program, I see that the audio tracks are cut shorter than the video. In fact, I’d say that the audio tracks are only 25% of the total length of the clip. In addition, the audio has slipped, so that the end of the audio track is at the beginning of the clip.

GM