Panasonic Timecode woes with non-linear audio recording.
Charles Tomaras
aware that myself and others have had issues with the odd timecode values
that the Panasonic Varicam and SDX-900 output from their BNC connectors.
When running with these cameras as rec run masters, the BWF timecode stamps
sporadically mis-stamp the files as 30.00ND when they are in fact 29.97ND.
There is no pattern to the mis-stamping and it's created lots of confusion
and issues on my end as I regularly record backup and transcription in this
fashion. While Sound Devices had been buried in work getting their new V2
software/hardware update out I'm told they are trying to address the issue
with possible SD based workaround software/firmware solutions in addition to
some communication with Panasonic. I see this as a very slow process and
wanted to open this up a bit on RAMPS and see how widespread the
incompatibilities might be with other machines as well, while also making
the Panasonic timecode debate a bit more visible to the folks at Panasonic.
Are users of other non-linear recorders seeing these same sorts of timecode
output oddities when using the Panasonic cameras?
Charles Tomaras
Seattle, WA
S Lynam
I had the same problem with my 744t, but I was using a PD-4 as a
master. All SD told me was that I had a bad cable. I was able to figure
out that the 744 needs timecode at all times coming to it when it is in
Ext TC/cont-Auto record. I'm assuming you're using a wireless set-up
coming from the camera back to you. Also wondering if you are using a
pre-record buffer? Somewhere between when the 744 starts recording and
when it first sees timecode moving it has to make up code till it gets
some and it seems to default to 30.00 NDF.
I tried this with my HHB Dat recorder and it would never mess up.
The master time code always needs to be present even when the recorder
is stopped as in run/record. The HHB is sending one frame of code over
and over when it is not recording. The PD-4 sends no code until it
starts recording unless you go into the menu and tell the machine to
send time code when stopped or paused. Does the slate show garbage or
the correct TC when you first start it up with one of the cameras
already on? If garbage, then the camera only sends code when in record.
Camera has to be in run/record, not free run tc.
So you need to make sure the camera is sending time code, even
when stopped or paused. I have the belief that this is also true when
in Ext TC/cont. So the trouble is happening when the 744 is time
stamping the file since I believe there is no real time code running in
BWF. In other words the machine takes the time stamp and then applies
it to the file. So if the 744 sees no Time code, it makes up it's own
time code just like if you weren't sending any time code to it.
My files played in my machine and on some macs, but wouldn't
import to final cut. I also haven't figured out out to fix the problem
in playing them back or making sure they are stamped right. I've only
had my 744 for a month now, but I hope this helps you out. I tried
finding out if others have had this problem also, but couldn't find any
in any other Ramps notes.
Later. S Lynam
Philip Perkins
serious comparisons of 744 vs SDX 900 TC using BWF Widget etc--is that
true? Or you just relying on reports from Avid or FCP editors? Mostly
I've seen a consistent 4 frame offset w/ the SDX900, which we
attributed to picture signal processing delay in the camera.
Philip Perkins
Nick
Hi guys,
I have been experiencing this problem too. I am using an Ambient
Clock-it Controller to jam everyone (Lock-its, slates and the 744T) in
the morning. Initially we were jamming the 744T every time we jammed
the saltes, every 3 hours or so.
Post said we had sync drift. BWF widget pro is the easiest way to
examine and fix the error. Edit the metadata and change the speed to
029.97-ND, this will tell the DV-40/824 to playback at the correct
speed.
I tuned the whole system and now we jam the 744 only once in the
morning. This has reduced the occurances but has not eliminated them.
As to why this is happening, I do not know. I have two machines and
they are both doing it. I sent my first one to SD and the say they can
not replicate it. I check every file before it send it in and correct
it if needed. If 2.0 is writing directly to an external optical this
will not be an option.
I run a 10 second buffer, free run, 24/48k and am trying to replicate
it on a regular basis but have yet to.
All the best.
Nicholas Allen, C.A.S.
Soundcatcher
Hi Charles,
Yes I've encountered the same problem with the Varicam and my 744t. To
date it's only been a back-up recording so it has yet to be a big
problem.
I'd be a bit worried if a Varicam turned up on a drama shoot though!
Cheers,
Chris Sheedy
son...@cox.net
I'm seeing the same problem with my 744T - It's quite ugly.
For my last production my 744 was in rec run mode with the camera as
master at 29.9 NDF. While reviewing production sound with BWF Widget I
noticed that the files were sprinkled with Frame Rates of 29.9DF and
30ND. I would guess that about 20% - 25% of the files were incorrect -
Yuk! I could find no pattern in the files or my sound logs to account
for this incorrect metadata, but I was using a wireless link to send
timecode from a Panasonic SDX 900. Hmmmm?
I have a production beginning next week that will use the SDX900 again
so I'll try to do some experimenting with the timecode link and rec run
mode. I'll post what I find.
Meanwhile, consider this my 2 cents that yes, the bad frame rate issue
is a deal killer for rec run mode with the affected cameras (which
anecdotally seem to all be Panasonics). We need to get a definitive
determination of the cause and turn up the heat on the culprits.
Meanwhile if SD (or anyone else) has a work around it would sure be
great - anybody listening?... Anybody?... Bueller?...
Hope this is useful,
RM
Charles Tomaras
"S Lynam" <cndo...@cox.net> wrote in message
news:1158714712.1...@k70g2000cwa.googlegroups.com...
>
> I had the same problem with my 744t, but I was using a PD-4 as a
> master. All SD told me was that I had a bad cable. I was able to figure
> out that the 744 needs timecode at all times coming to it when it is in
> Ext TC/cont-Auto record. I'm assuming you're using a wireless set-up
> coming from the camera back to you. Also wondering if you are using a
> pre-record buffer? Somewhere between when the 744 starts recording and
> when it first sees timecode moving it has to make up code till it gets
> some and it seems to default to 30.00 NDF.
No Peter...I have this problem when hard wired and I have no problems with
Sony cameras of any flavor. You cannot use the preroll buffer in Ext. Time
Code Auto Record. It's definitely a Panasonic related issue.
Charles Tomaras
"Philip Perkins" <spam...@yahoo.com> wrote in message
news:1158725454.8...@i42g2000cwa.googlegroups.com...
Only going by what I "see" with BWF Widget as I have no equipment to compare
video with timecode.
johngooch
HI everybody,
This may be an redundant question has anybody checked to see what TC
mode the camera is set to. I think TC is available at the TC out port
in a couple of modes, GEN or PB/GEN. I always set to Gen that way PB
TC does not cause 744t to roll during a camera tech check. This menu
setting is described on page 98 of the sdx-900 manual. I wonder if
this has any bearing on mis-stamped frame rates.
john gooch
Ted Albalos
instruction manual in *.pdf format:
http://catalog2.panasonic.com/webapp/wcs/stores/servlet/ModelDetail?displayTab=R&storeId=11201&catalogId=13051&itemId=68651&catGroupId=14616&modelNo=AJ-SDX900&surfModel=AJ-SDX900
Ted Albalos
> Here's a link to the Panasonic AJ-SDX900 page with another link to the
> instruction manual in *.pdf format:
> http://catalog2.panasonic.com/webapp/wcs/stores/servlet/ModelDetail?displayTab=R&storeId=11201&catalogId=13051&itemId=68651&catGroupId=14616&modelNo=AJ-SDX900&surfModel=AJ-SDX900
It's hard to derive from the wording, but this particular setting, TCG
Set Hold (Default OFF), on the camera's internal TC/UB menu (7-8-7,
Page 98) may have some effect:
TCG Set Hold:"For selecting ON or OFF for the function that without
fail uses what was previously set as the TCG value for recording when
the TCG value had been set before the power was turned off and
recording was then performed after the power was turned back on again."
I'm not sure if that means the TCG resets to the value set prior to
shutting off the camera, or whether it means the TCG will continue
where the recording was stopped prior to shutting off the camera.
I'll have access to an SDX900 later this week.
Charles Tomaras
"johngooch" <jgooc...@mac.com> wrote in message
news:1158751426.7...@m73g2000cwd.googlegroups.com...
John...good thought but it has no bearing on the mis-stamped frame rates.
Philip Perkins
Panasonic issue? (Other than the Panasonic transmitting garbage TC
when it first rolls up in rec-run)? This was a problem w/ the Tascam
P2 for awhile, but I think they licked it, or at least the last batch
of SDX900 jobs I did seemed to sync ok. (Wireless TC, rec run.)
Philip Perkins
Charles Tomaras
> Just to be clear--you believe that this is a Sound Devices issue, not a
> Panasonic issue? (Other than the Panasonic transmitting garbage TC
> when it first rolls up in rec-run)? This was a problem w/ the Tascam
> P2 for awhile, but I think they licked it, or at least the last batch
> of SDX900 jobs I did seemed to sync ok. (Wireless TC, rec run.)
No, I'm pretty certain it's a Panasonic issue that Panasonic is not going to
look at or issue a fix for the cameras that are already in the field. I'm
wondering if users of other non-Sound Devices recorders are having similar
problems. I believe that SD can come up with some sort of software
workaround for working with Panasonic cameras that will solve the problem by
possibly buffering the input for a few seconds and then back stamping the
code after it has stabilized.
Nick
only a Clock-it Controller for it's once a day jam. The problem was
happening more when it was jammed multiple times during the day. I have
seen it 3 or 4 times since on 2 different 744T's. I am leaning towards
a procedural error in the 744 OS.
Nicholas Allen , C.A.S.