Re: Why are my RADAR Bwavs out of time in Cubase SX

[Rail Jon Rogut]

For every DAW the time stamp is sample accurate.. the RADAR is SMPTE based
and I've read and heard of issues in their SMPTE to samples conversion with
drop frame code.

The actual time stamp in a bext chunk is saved as a sample value.

Rail
--
Recording Engineer/Software Developer
Rail Jon Rogut Software
http://www.railjonrogut.com


"Bryson" > wrote in message
link.net...
> How accurate is time stamping? Sub frames, samples?
>
> Mondoslug1 wrote:
> > Martin wrote:
> >
> >
> >>So I've been noticing that when I transfer my stuff from RADAR to Cubase
> >>using the FTP link across a network cable and import them into an
> >>arrangement, their slightly ahead of time. I've mostly noticed this
because
> >>I'm running a project on Cubase SX that has a lot of loops and we
tracked a
> >>real kit on the RADAR.
> >>
> >>When I transferred the files into Cubase for further editing I
immediately
> >>noticed that they were slightly ahead of time.
> >
> >
> > Does Cubase have "move to origin"? Nuendo does. They're time stamped -
Radar
> > exported BCWs lined right up for me.
> >
> > The only way I could get them
> >
> >>to sound relaxed was to slide them to the right a 1/4 frame and a couple
of
> >>subframes. Zooming in on the waveforms I can see that they are several
> >>miliseconds behind the bar. Its hard to be precise about it as their
real
> >>drums but its definitely there as I've done the same thing on 11 other
songs
> >>on this album.
> >>
> >>The RADAR should be writing broadcast wavs, so why isn't Cubase putting
them
> >>exactly where they should be?
> >>
> >>Is it something got to do with the syncing of Cubase to the RADAR via
MTC?
> >>When cubase slaves is it running a little behind, so that when I
transfer
> >>the RADAR files over they are being put a little forward as the machine
> >>doesn't have to follow sync any more? I have no option currently of
driving
> >>the PC with SMPTE as my Frontier Dakota/Montana doesn't allow it. MTC
with
> >>it seems to be very tight though!
> >>
> >>Martin
> >>
> >>
> >>
> >>
> >>
> >>
> >>
> >>
> >
> >
> >
> >
> >
> >
> > Me at:
> > http://www.soundclick.com/bands/5/andymostmusic.htm
> >
> >
> >
> >
> >
> >
> >
>

[Mike Rivers]

In article > writes:

> The RADAR should be writing broadcast wavs, so why isn't Cubase putting them
> exactly where they should be?

Could it be that there are latency issues?

> Is it something got to do with the syncing of Cubase to the RADAR via MTC?

It could. MTC is good for a 1/4 frame accuracy.


--
I'm really Mike Rivers )
However, until the spam goes away or Hell freezes over,
lots of IP addresses are blocked from this system. If
you e-mail me and it bounces, use your secret decoder ring
and reach me here: double-m-eleven-double-zero at yahoo

[Bob Olhsson]

"Mike Rivers" > wrote in message
news:znr1092191680k@trad...
> It could. MTC is good for a 1/4 frame accuracy.

People keep repeating this misinformation in manuals and magazines but it is
dead wrong. Accuracy is determined by frame rollover accuracy. The 1/4 frame
business only affects how quickly a time code reader can acquire sync.

It's talking about how many sprockets are used per frame rather than about
how accurately the sprockets are aligned to each frame. MTC is POTENTIALLY
every bit as accurate as any other kind of time code. Sh!tty implementations
happen everywhere but there is nothing remotely wrong with MIDI time code as
a format.

--
Bob Olhsson Audio Mastery, Nashville TN
Mastering, Audio for Picture, Mix Evaluation and Quality Control
Over 40 years making people sound better than they ever imagined!
615.385.8051 http://www.hyperback.com

[Mike Rivers]

In article > writes:

> > It could. MTC is good for a 1/4 frame accuracy.
>
> People keep repeating this misinformation in manuals and magazines but it is
> dead wrong. Accuracy is determined by frame rollover accuracy. The 1/4 frame
> business only affects how quickly a time code reader can acquire sync.

It's a matter of resolution. What happens between the numbers is a
function of how stable the hardware is.

> It's talking about how many sprockets are used per frame rather than about
> how accurately the sprockets are aligned to each frame.

That's true when you have real frames, but we're talking time code
(DATA) frames here, not film frames. There are four MTC numbers that
fall within the time of one film or video frame, hence the notion of
1/4 frame accuracy. It's better to say 'resolution' but nobody who
doesn't know how to solve a time code problem would know what it
means.

> MTC is POTENTIALLY
> every bit as accurate as any other kind of time code. Sh!tty implementations
> happen everywhere but there is nothing remotely wrong with MIDI time code as
> a format.

Agreed. It actually has better resolution that SMPTE time code, but
the hardware implementation isn't as stable in most instances because
things that talk MIDI are usually busy doing other things.


--
I'm really Mike Rivers )
However, until the spam goes away or Hell freezes over,
lots of IP addresses are blocked from this system. If
you e-mail me and it bounces, use your secret decoder ring
and reach me here: double-m-eleven-double-zero at yahoo