Jamming the Tascam's HD-P2

N

naavt

Well-known member
Hi,

I'm looking for advice on how to jam sync a Tascam HD-P2.
I just bought Fisher-Robotics Timetool L to feed TC to my Tascam recorder but I've tried all the Tascam Manual says about TC (which isn't much!), plus all that I can remember to make it work and... After 4 or 5 hours I'm still wondering how to jam the damn thing!

I'm feeding it trough the Timetool L BNC out to XLR TC in on the Tascam. The cable is fine (I've checked it!).

On the Tascam System settings/Audio clock information I can read the TC in when I connect my XH-A1 to it. Strangely it reads 24fps on TC pane when I have chosen 25 on the project menu, and it floats at about 25.08fps on the measure rate pane. Some times it looses signal for less than a second.

All this info is lost to "No signal" when I disconnect the Timetool or the camera, leaving me to assume that TC signal is being fed to the Tascam recorder.

When I press REC on my XH-A1 it goes from the displayed 24fps to 25fps (the settings on the camera).

So what am I doing wrong and how I jam sync it?

Thanks in advance
 
Have you pushed the Timecode button? That is the way to get it to display the tc when not recording. Also make sure the tc source is set to ltc.

Phil
 
Yes. I've done both. Time code is set to LTC but when I press the TC button it flashes when it should be steady :(
 
I'm just guessing here and I haven't been able to locate the TimeTool manual online to check its operating details, but I think timecode only appears on the LANC terminal when the camera is recording. If that's right, it would mean the Timetool has nothing to chase unless the camera is running.

See what happens if you ... connect everything together, put the camera into record and wait for the Tascam to sync up, then first disconnect the Tascam from the Timetool and then stop the camera and disconnect the Timetool from it.

I'm thinking the Tascam's audio clock source needs to be set to internal unless yiou're feeding the incoming timecode continuously. Try it both ways - internal and LTC - and see if it changes anything.

If that doesn't help, I've run out of ideas as I don't own any of those three devices to experiment with.
 
Last edited:
Thank you for your sugestions Steve,

I'm going to try both ways like you say and post the results here.
If it doesn't work, I plan to try a Ambient Lock It box and see if the problem is in the Timetool box.

But I wish I could put the Timetool working!!!

By the way, you can find the Timetool L datasheet here: http://www.fisher-robotics.com/
 
Last edited:
naavt said:
Thank you for your sugestions Steve,

I'm going to try both ways like you say and post the results here.
If it doesn't work, I plan to try a Ambient Lock It box and see if the problem is in the Timetool box.

But I wish I could put the Timetool working!!!

By the way, you can find the Timetool L datasheet here: http://www.fisher-robotics.com/
Click to expand...

Yep, datasheet I found but a manual, if it exists, would hopefully have more detailed information.

I have to be frank with you ... I think you're making a tempest in a teapot by spending so much time and money to use timecode for what is really going to be a very limited benefit. If you set the camera and the recorder's time of day cloks together you should be able to get them within a second or two of each other. Set the Tascam's clock then set the camera's clock to it, pushing the button to start the camera clock when the Tascam screen displays 00 seconds.

I don't have a Tascam so take my comments with a grain of salt but I read in the manual that when the Tascam is chasing timecode, the BWF file header timestamp is the timecode reading. If it's not chasing timecode, it says that the timestamp is based on the system clock. So the real difference between using TOD timecode and system TOD is with TC it reads hours, minutes, seconds, and frames while with the system clock it reads hours, minutes, seconds, and hundreths. Even without chasing timecode, it appears you have a TOD timestamp on the audio file based on the current system clock reading when the file starts recording. With TOD timecode on the video and the TOD timestamp on the audio files you have all the information you need to match up what audio clip belongs with what video clip. Yes, you may have to slip the audio a little bit in the editor to get them in sync but you're probably going to have to do that anyway even if you get the timecode thing sorted out. When you drop the audio into your editing timeline, assuming you're using an editor that recognizes the BWF timestamp in the first place, it will drop in so the first sample in the file lands at the position on the timeline that matches what the system clock was reading when you began recording. If the video clip's TOD timecode is aligned to the editing timeline so the two match, you'll be very close to sync.

IMHO Lockit's would be way overkill, they're not cheap, and would be of very limited use when the camera doesn't have TC in/out and genlock in. You would still have the same problem of reading the camera's timecode in order to jam the lockit that you do now.

Take a look at the program called BWF Widget Pro - you can find it on the web and there's a free 15 day trial. Make a couple of test recordings on your Tascam and examine the files using it. With widget you can see for yourself just exactly what is in the header timestamp of the files even without chasing timecode. You'll be able to see the starting timecode, and the file date and time timestamp. If the TC isn't time-of-day (and I think it will be) Widget allows you to edit it to whatever you want. I think you'll find that even without the Timetool you have everything you really need already.
 
Last edited:
Hi Steve,

That's some great info and I thank you in advance for it. I have a couple of questions though.

I know that the Tascam timestamps every file in a sequential form (if I begin recording at zeros and end the first take at 00:00:35:18 it will begin the next on 00:00:35:19 and so on), but having TOD timestamp without chasing is new for me. I was under the impression that it only could generate TOD if jammed by a TC generator (that's why the Timetool), am I wrong? Or...

...Are you saying that TOD is stamped only on BWF, hence your sugestion to look for the Widget Pro to read it. Thus this means that are two stamped TCs on a BWF file? TOD and Tascam's internal clock?

Besides that, I've checked the LOG info on the Timetool app, the one that permits you to download to computer every REC/Stop event from the camera with TC and user bits associated. The thing is that every REC/Stop is sharply recorded by the Timetool so... I just don't know why it isn't jamming my Tascam! I've just emailed Ben Fisher about this.

Thanks
 
Last edited:
naavt said:
Hi Steve,

That's some great info and I thank you in advance for it. I have a couple of questions though.

I know that the Tascam timestamps every file in a sequential form (if I begin recording at zeros and end the first take at 00:00:35:18 it will begin the next on 00:00:35:19 and so on), but having TOD timestamp without chasing is new for me. I was under the impression that it only could generate TOD if jammed by a TC generator (that's why the Timetool), am I wrong? Or...

...Are you saying that TOD is stamped only on BWF, hence your sugestion to look for the Widget Pro to read it. Thus this means that are two stamped TCs on a BWF file? TOD and Tascam's internal clock?

Besides that, I've checked the LOG info on the Timetool app, the one that permits you to download to computer every REC/Stop event from the camera with TC and user bits associated. The thing is that every REC/Stop is sharply recorded by the Timetool so... I just don't know why it isn't jamming my Tascam! I've just emailed Ben Fisher about this.

Thanks
Click to expand...

In a manner of speaking there are two timestamps on a BWF file. There's the file creation/modication date and time itself, just like any other computer file. Then there's the timestamp embedded in the file header that records the beginning timecode of the first sample. It's my understanding that the Tascam uses the timecode handed to it as its timestamp when the recorder is chasing timecode and the system time when it's not. I wish I had one of the recorders to check it but unfortunately I don't. But be that as it may, I think you're getting far too hung up on the whole timecode issue. Movies were made for close to a seventy-five years with nothing more than a clapper slate to sync them together and the traditional method still works just fine.
 
I think you're getting far too hung up on the whole timecode issue. Movies were made for close to a seventy-five years with nothing more than a clapper slate to sync them together and the traditional method still works just fine.
Click to expand...
You probably right Steve. But it's just a waste having a great functionality and don't make any use of it. I think it's like all that people who buys iPhones just to make calls!!! :D
 
Last edited:
naavt said:
You probably right Steve. But it's just a waste having a great functionality and don't make any use of it. I think it's like all that people who buys iPhones just to make calls!!! :D
Click to expand...
I hear ya and I'm the same way. Was just thinking though, if you're at the point of considering something like a Lockit, I'd strongly suggest instead upgrading the recorder to a Sound Devices 702T. The SD's timecode module is by Ambient and it most definitely is a full blown generator, not just a reader. Another choice might be the Foxtex FR-2.
 
Last edited:
naavt said:
You probably right Steve. But it's just a waste having a great functionality and don't make any use of it. I think it's like all that people who buys iPhones just to make calls!!! :D
Click to expand...

The thing is you have to keep that old axiom in mind "is it better, or just different?". TC is cool, all those numbers and blinky lights. But in the end it's just a complicated clapper slate. Digital sound files are only marked at the start. Now good old analog TC and a Reel to Reel and you could watch it shimmy around till it locked up, That was fun. The other little fly in the ointment with TC is that there isn't just one kind. You have a slate clap or a two pop and it doesn't matter what machine put it there or if they were shooting PAL or SECAM or 35mm, it's the same pop. Sync the clap/ pop and your there. Now if you stamp your files with 29.97 TC and the camera is writing 23.98 and it goes to FCP where it defaults to 29.97 drop frame... Your numbers don't match the camera and nobody matches the NLE and nobody slated because we have this nifty TC thing that never fails.

Of course everybody should have talked and be on the same page and the same TC and time base etc. But I can tell you that the longer you spend working in the biz (especially if your in post where all the chickens (ah mistakes) come home to roost the more you will realize that more often than not somebody didn't tell the right person the right info and things are off. You will hear that it's cheaper to fix in post than slate in production, but you won't often hear that from folks who do or pay for post.

That said TC is great when it works .
 
That said TC is great when it works
Click to expand...
I'm with you in all that you've posted here and I'm going to explain myself why I have this TC obsession :)

I mostly do direct documentary work. I shoot and my wife is my sound operator. Until now, we have been using a H4 recorder with an Art mixer feeding the H4 line in. The workflow was fine every time we were on the set but as soon as we hit the NLE it was a pain.

Soooo many hours spent to find that piece of audio that belongs to that picture, just because we just don't have the time and opportunity to slate every take! On another kind of jobs.... Ok! You are going to make an interview? You can slate every take, but on the run? No way!

So the Tascam was the logical adition to our gear. The problem was that we didn't realize that it could not iniciate TC (so needing a generator for that).

But I have some good and some bad news now. We've managed to buy a piece of kit that's really great (if it could function with our XH-A1 :(). It's a LANC to LTC converter and it works like a breeze... On my older SD XM2 camera. It syncs, it jams, it does everything right! But on my newer XH-A1 it won't and I don't know why :(

I'm in contact with the developer and he's going to look for what is happening and try to fix it. If he finds a way, it's one of the best TC piece of kit that I can think of :)
 
Naavt - it may be the camera's fault. I recall reading that not all cameras properly implement the TC coding on the LANC terminal. I don't know specifically about the XH-A1 but it's a possibility that it's one of those that don't..
 
Steve House said:
Naavt - it may be the camera's fault. I recall reading that not all cameras properly implement the TC coding on the LANC terminal. I don't know specifically about the XH-A1 but it's a possibility that it's one of those that don't..
Click to expand...


Hi Steve,

That crossed my mind also, but I'm expecting a miracle here :D

The thing is that the LANC to LTC LOG (which can be downloaded from the kit's flash memory), is very much the same from the two cameras (XM2 and XH-A1).

Both have REC and STOP logs accompanied by the respective TC in/out and user bits. So this has to mean that my XH-A1 is sending TC out info from the LANC terminal.
So I'm expecting it to work... Hopefully! :)
 
You must log in or register to reply here.
Back
Top