Broadcast WAV with embedded Timecode weirdness

Has anyone had any problems with BWF timecode stamps in Cubase6?

Just delivered some stems and all the TC stamps are off by weird amounts. i can’t fully investigate it just yet but was wondering if anyone else had noticed it?

thanks!

Ok I’ve checked the project now. I’m exporting a Broadcast WAV at 48/24, timecode start point is 0.03.31.00 - 24fps. If i reimport it into the same project, it says in the audio pool that the origin timecode is 00.07.02.01.

I think this is a bug. I’ve never had issues with BWF and the timecodes before.

Anyone else seen this?

cubase 6, OS 10.6.6.

Thanks

reported for further investigation (28230)

Any developments on this at all?

thanks.

I just tried again in a new project just in case it may have stopped occurring but unfortunately it’s still happening.

I mixed down a broadcast wave file with a starting point timecode of 03044819 and using BWAVreader it says the embedded timecode of the mixed down audio file is 01322928. This project starts at 03000000 as it’s reel 3 of a feature. so it doesn’t make sense.

This kind of is actually a big problem for me. But i seem to be alone?

Setting up a Pro Tools session with prelays and clicks from Cubase just a moment ago, I couldn’t figure out a way to get the timestamps to work since my Cubase synth session is in 44k and the PT session needs to be in 48k. Since the timestamps are basically sample counters, any change in sample rate will throw them completely off the map. I’m not converting the Cubase session to 48k, so basically I was out of luck. If you’re keeping within the same sample rate though, not sure what’s happening.

In any case, I ended up doing an OMF export for the prelays which seemed to sync fine. As long as you don’t try to use stereo tracks, that is; PT won’t even do its typical interleaved->split operation, it just creates mono tracks with missing regions… Timestamps have always been a headache, no matter between which programs I try to move stuff between, so I try to avoid them as long as possible. Frame sync is obviously not enough for recording though, so gladly the OMF solution does the trick.

Just out of curiousity, is there a reason you wouldn’t simply batch export your tracks to be used in another DAW?
( other than the stereo problem, I suppose)

Hey,

I was exporting from 96kHz to 48kHz. But I’ve just tested exporting from 48 to 48. Here’s the result:

actual origin time is 00002618. the resulting wav file’s origin time is 00001311. Which is kind of half-ish, which is odd.

Exporting the same file, but from a 96 project to a 48 wav file, the origin time goes from 00002618 to 00002622.

Maybe I should just ditch trying to make TC embedded WAVs with cubase.

I am also having problems with this. I tried fixing with a display offset, but the amount it moves the timpestamp by seem to fluxuate or in some cases is comepletely random, which makes it impossible to correct with an offset. I have had some luck by doing to following:

-Set your main transport time base to timecode as opposed to bars and beats.

-Select the audio in the edit page (make sure it is placed at the correct timecode, obviously)

-Bounce replace the file.

-Delete and remove from your pool. (Do not erase. Also, before you remove from your session- be sure to give it a unique name, or place an “_” at the front of the file name so you don’t have to search for "Audio 01_03 in a folder full of Audio 01-whatever files. Big time waster.)

-In the pool, select the “import” option

-Locate the audio you have just bounced in your sessions audio folder and import back into your session (are we having fun yet???)

-Test your “move to origin” function. With your sequence still set to “timecode” as your main transport time base, tell cubase to insert into project at origin (by right clicking the file in the pool and going to the “Insert into Project” tab.

-Your file should NOW spot correctly to timecode.


I think if you either record or bounce a file in Cubase, it is somehow referencing the active timebase in your session to stamp the resulting file, and when that time base is not set to “timecode”…it freaks out, or it is triing to determine the timecode based off of a predetermined BPM setting (like 60 or 120bpm). Either way, you should not have to go through all of this crap in order to do something that is so basic…and for composers or anyone else working to picture-so essential. It seems like it should be a pretty simple fix, but they have not tackled this one yet.
Unless someone out there knows why this is happening, I have not ruled out user error by any means. Anyone know what the deal is with this? Has it been reported to Steinberg yet? Thanks…

Hey De La,

nice one finding a work around, but you’re right - it’s too time consuming. You may have 25 cues consisting of say an average of 6 stems each!

In February, Chris Beuermann has said it’s been reported for further investigation. I’m surprised actually that this isn’t more of an urgent issue for Steinberg, and it makes me think that actually, not many people do use cubase for film music/sound.

This is a new bug for Cubase 6 i’m afraid. C5 and earlier was ok.

So now, if you have many audio files to process, we’ll have to use third party software to embed the TC…

Cheers.

Hopefully they will address this in 6.0.4 (which I am guessing will be out sooner than later since it is buggy as hell).

Still doesn’t work for me… Anyone else get embedded TCs working?

Hey there kihi,
I’m not sure if you’ve solved it yet, but i’ve been exporting cues with timecode embedded and i have no problems automatically lining them up to picture in another DAW (in my case, it’s DP). I ensured that they were really at the correct spot by doing a bunch of tests, using random files, etc.

I am using 6.0.5 though.
What I realized made a big difference for me, (and forgive me for saying this if you have already done this) was, ensuring that the transport had frames/timecode displayed as the main unit of ‘measure’.

This is so that when you open the Broadcast wave settings, and when you get to the little box at the bottom, the unit displayed is Frames, and not Measure numbers, which can, in some instances, look very similar.

That is probably why it ended up in some random place, because, when you keyed in what you thought was time-code, Cubase accepted it as Measure numbers and bounced it out in measures. I have done this before when i first tried exporting broadcast Wavs.


It’s definitely not something that was fixed in 6.0.5, I just re-read the changelog.
Hope I was of some help, I’ve definitely heard of this issue before from other people.

Thanks,

Hi Jon,

Thanks for this. yeah, i have TV as the main unit of measure. Still not fixed and I’ve given up expecting it to work. I think it may be because i work at 96 kHz. When i deliver to the dub i just create one big bit of audio with all the cues tracklaid in the correct place rather than individual audio cues so as to not need the embedded TCs.

I’d love to know how you feel about using DP but maybe we can’t discuss that on this forum!

thanks,

Chris



Any progress on this? I’m curious how a protools mixer actually imports a folder full of files and gets them to line up based on the iXML chunk timecode stamp. If its a manual hassle for him to line up all the files im better off using OMF

Bump. Did this ever get fixed?