[Bouke Vahl]

Have the lesser gods install the free codecs available from Sony and you should be good.

Bouke

https://www.videotoolshed.com/
smart tools for video pro’s

[Bouke Vahl]

well, i have mailed both Eric and you a couple of times about the progress, several weeks (months) ago, but never heard anything back…

Bouke

https://www.videotoolshed.com/
smart tools for video pro’s

[Bouke Vahl]

You are all wrong.
FCP is perfectly able to play back H264 RT. (No RT effects though, everything but hard cuts have to be rendered.)

There are a few reasons FCP can bitch:
The sequence settings resolution and codec MUST match the video.
The QT’s must NOT be flagged another resolution for display than they in fact are. (But QT is famous for doing so even if you don’t ask for it.)
Audio MUST have a sample rate compatible with FCP (thus 32, 44.1 or 48 Khz.)

If these requirements are met, and you drop a clip onto an empty sequence, FCP will warn you that some things won’t match. Just tell it to fix it for you and you’re golden.

Don’t believe me?
Watch the video here:
https://www.videotoolshed.com/?page=products&pID=35

Bouke

https://www.videotoolshed.com/
smart tools for video pro’s

[Bouke Vahl]

No, he doesn’t
Avid can switch it on import if needed…

But you’ll have other problems, like perhaps loosing metadata.
What are you trying to do?

Bouke

https://www.videotoolshed.com/
smart tools for video pro’s

[Bouke Vahl]

PLEASE
STOP USING THE TERM 23.98.
It does not make sense for those who want to do math.
23.976 is a better term, it avoids confusion.
(although not accurate enough to do decent math.)

And i do agree, why not start working in 23.976 from the start and keep it that way.

Bouke

https://www.videotoolshed.com/
smart tools for video pro’s

[Bouke Vahl]

Greg,
The lesson you should have learned:

BWF does NOT carry TC, it carries a Timestamp.
The TC readout you get in different software packages is calculated based on the sample rate and the project framerate.
(If the software is written correctly, and sadly, that’s not always the case…)
Don’t get confused about the math. It is only important when you run into problems. With the use of a pocked calculator you can then determine the source of the trouble. Or, if you ask help online, do include the TC numbers and TC offset, so others can do the math for you 🙂
Most important:
-Do not think it is weird if you see different TC values in different software.
-Never record ’24’ if you’re shooting ‘23.976’.
-Always test the entire workflow.

And, keep on learning. Almost all my knowledge about the subject comes from the World Wide Internets.
It’s not that hard, it just takes a huge amount of time to ingest everything (and filter the bullshit from the valuable stuff)

later,

Bouke

https://www.videotoolshed.com/
smart tools for video pro’s

[Bouke Vahl]

Greg,
Let’s keep the conversation here, so others can benefit.
(the Cow is high on Google…)

Timestamping in BWF is NOT the same as Timecode.
A BWF gets a ‘timestamp’, a number that is known as ‘samples after midnight’.
This is not a ‘stream’, but a tiny bit of metadata added to the beginning or end of the WAV file.

So in order to calculate the Timecode, you need to know the sample rate first. Normally this is 48 Khz, but it does not HAVE to be.
(Especially going from 23.976 to 24 or vice versa, it’s a known trick to alter the sample rate)

So if the Timestamp is 96000, and the sample rate is 48000, you would think the Timecode is 00:00:02:00.

But there is more to it. The playback speed comes into play.
As you know, NTSC does NOT run at 30 FPS, but at app. 29.97.
(This number is not even close enough to do decent math on BWF’s,
as the numbers become quite high, but that is beyond this piece)

So a timestamp of 96.000.000.000 will give you a time of
96.000.000 / 48.000 = 2000 seconds.

In a 24 (film) project, that would correspond with a TC of 00:33:20:00
BUT, in a 23.976 (24p Video) project, the video runs slightly slower.
After 2000 seconds have passed, there are only 1998 frames displayed.
The correct timecode in a 23.976 project thus should be a bit less (2000 / 30 * 29.97) = 1998, thus two frames less making 00:33:19:21

(to do real math, don’t use 29.97, but 30000 / 1001 = 29,97002997002997002997002997003

Now to further complicate things:
NOT ALL SOFTWARE WORKS THE SAME.

So always test your workflow. But in case of trouble, you now know what math to do to see where what goes wrong…

As for working with ‘Prosumer’ cams.
Of course, happens a lot. Putting the LTC on an audio track is your only option (except a clap and a lot of manual work)

But even with Pro cameras, there are people who prefer to use LTC on an audio track rather than having the cam locked to external TC.
There are a few reasons, mainly for tape based shootings:
(And yes, i have encountered all the trouble i’m about to mention…)

If you have to ingest, your NLE will stop capturing / re-cueing at every shot. This will take huge amounts of time extra, and if you have shot HDV and try to ingest material with TC breaks using a cheap HDV deck, the guy ingesting will go insane. (It just does not work…)

If you have not properly locked everything, the TC can slip, and the capture process can be halted as a result of that. Not a major problem, but annoying at least.

Some directors / DOP’s like to have the TC hour to match the tape/disk name. (Makes logging / troubleshooting easier).
Shooting TOD of course will give you a huge amount of overlap on clips. A mistake in reel / disk / tape labeling can cause mayem in the online.

So i would suggest, do download the FCPauxTC demo from my site and start toying with it. Better to do it now than at the moment you actually need it.
Last hint, do not record the LTC too loud. Between -18 and -9 i more than high enough. (Lower probably also works)

hth,

Bouke

https://www.videotoolshed.com/
smart tools for video pro’s

[Bouke Vahl]

Hey, cut him some slack.

Instead of bitching around, he’s doing something constructive, trying to make things better.

You gotta respect that.

Bouke

https://www.videotoolshed.com/
smart tools for video pro’s

[Bouke Vahl]

Greg,

Don’t worry, i know plenty about the BWF format.
And, it’s not ‘my’ workflow. I’ve written a program that can decode LTC and turn that into a QT TC track (see the rsync ‘n link thread a bit up).
People who use that take the LTC from the BWF recorder and put that on an audio channel of the cam.

Now it seems that when using preroll on the BWF recorder things are not in sync.
But i never actually saw the files, i just got questions from customers so i cannot put my finger on it what exactly happens where.
My guess is that the files with ‘pre recording’ get stamped the time the record button is hit, not compensated for the extra recording time.
But this is pure speculation…

Bouke

https://www.videotoolshed.com/
smart tools for video pro’s

[Bouke Vahl]

There are other alternatives:
If you sync the cam to the BWF recorder, there is not even a need for a slate. In those cases the slate/clap is a backup for both shot logging and sync.

A dirt cheap smart alate can be found here:
https://www.videotoolshed.com/?page=products&pID=38

It can slave as well as being master TC generator (although not genlockable).

If your cam has no TC in (a lot of cams used in production do not nowadays), you can record the TC (from either a smart slate, BWF recorder or the digital clapper) on one of the cams audio channels.
In order to extract the audio TC to QT tc in post, you need this:
https://www.videotoolshed.com/?page=products&pID=26

The last one also comes with an util that is a direct competition of Sync ‘n Link.
Included in the package is a tool that merges BWF with QT.
What it does is pasting the BWF into the QT, either self contained or by ref, based on timecode.

And that brings me to the most important thing.
If you start working this way, make sure you keep your material very organized. QT has timecode and reel information, BWF has only a timestamp. Thus it is impossible to track down the correct corresponding video based on the TC in the clip, so keep all BWF’s in a seperate directory per shooting day!
(assuming you don’t have overlapping TC’s)

And to answer a question before it has been asked, yes, it is stupid.
There is plenty of room for metadata inside a BWF file. But it never became a standard, so other metadata than timestamp cannot be trusted to be identical over different clips.
(But you can always rely on Andreas or me to see if customized work can be made specially for your workflow)

Bouke

https://www.videotoolshed.com/
smart tools for video pro’s