Broadcast Wave Files...Timestamping Bug??

Cubase
1

Not sure if anyone knows the status of this one, but it’s huge. Cubase does not properly timestamp .bwf files. So if you print audio in Cubase to place in a film…it will spot incorrectly. Usually by a second. Heres how I tested:

  • Open empty session.

Setup as follows:
Session start 01.00.00.00
Length at 30 min
fps 29.97
sample - 44.1
res. 24 bit
recording file type - Broadcast wave file

Set main transport time base to “timecode” rather than “bars and beats”

tempo 120

Create 2 audio tracks

postiion cursor at 01.01.00.00

record 5 seconds of empty audio

remove from your edit page, and find the file in your pool (it may have moved to the trash when you deleted it from your edit window. Just grab it back out and put it back in the audio folder).

Highlight, right click, and insert into project at origin. locate the file start time, and it is now 01.00.59.00-not 01.01.00.00.

I have seen cues spot even further out of sync when imported into Pro Tools instead of cubase…sometimes before the session start time, other times over an hour late. One work around that I have had some luck with, and if you have Pro Tools HD, PLEASE HELP ME TEST THIS.

  • Open session, follow steps above.

After you have recorded the audio, do not delete it. Instead bounce it and replace it.

Now remove it, reimport it to your pool, and insert into project at origin, and it spots correctly.

One thing I noticed that I found a bit odd was that the tempo of the audio file as identified in the pool was 120 (which is correct, but led to the audio being improperly spotted). When I bounce the audio and reimport into the pool…the tempo reads 155.71 (which is 35.771 bpm over what it was recorded and bounced at…but results in the file being spotted correctly.)

It seems like Cubase is either stamping or reading .bwf file start times by using some code or algorithm that is tempo based. This is a very BIG PROBLEM. Many cubase users rely on timestamped files to put their music to picture. 1 second might seem like a small amount of time, but when you are writing a piece of music that hits 8 or 9 points in a scene, 1 second is an enormous amount of time.

Please address this soon. Not only is bouncing every piece of audio that is printed in Cubase a massive waste of time, it is doubling the amount of hard drive space required to store all of the worthless audio Cubase is generating every time I press record.

Supposedly reported for further investigation (28230) in February 2011. Any progress? Thanks…

DeLa

2

Right??? Fix Please.

3

I get the start time difference after a record, but when I insert at origin, it syncs up with the original (record something useful, not silence.) The extra second on the front comes from the ‘Audio Pre-Record Seconds’ in Preferences, which you can turn down to 0 if that is undesireable.

One thing to note is how Broadcast Wave timecode actually works. In the original broadcast wave spec, there isn’t an actual timecode stamp; rather it’s expressed as “the number of samples since midnight.” Converting the number of samples into SMTPE timecode depends on what frames per second you choose to do the math in, and the FPS is not tagged in the wave. So you’ll get a different code depending on what your project FPS is set to; it’s a relative thing.

That said Broadcast Wave has subsequently been extended to include an “iXML” chunk which can be tagged with tons of other information, including a proper rate reference. Cubase 6 seems to write a little iXML chunk with some data (mostly the iXML version of everything in the normal broadcast wave chunk) but not the rate. I’m not sure if it understands the rate given a file tagged with one from some other app, and to address your point specifically, if ProTools even writes iXML with it either. You can look a sample file in a text editor, the iXML chunk is basically ASCII and you can scroll through the file and spot it pretty easily.

4

There’s a post here Broadcast WAV with embedded Timecode weirdness - Cubase - Steinberg Forums discussing the same issue. It’s a new bug that came with version 6 as it was fine in 5 and earlier. All my TC stamps are out by random amounts!

You need to use 3rd party software to embed the TC stamps now…

5

One thing to note is how Broadcast Wave timecode actually works. In the original broadcast wave spec, there isn’t an actual timecode stamp; rather it’s expressed as “the number of samples since midnight.”

…Interesting. What is “midnight”. I am guessing that is whenever the TC cycles back to :00. The TC being relative to the timecode of your session makes sense, totally. But I am reimporting these files back in to the exact same session, with no changes. and it still doesn’t explain the odd BPM reading in the pool.
I changed the Audio Pre Record setting, and this did fix the incorrect origin time, however. I figured it was a pref. somewhere that I had just not found. The real question will be wether or not my .bwf files will spot into Pro Tools now.
Thank you so much for your help. I will keep posting my findings.

N

6

Well, midnight is 12:00am or 00:00 in 24-hour time, or 00:00:00:00 in SMPTE timecode.

If the samplerate of the file is 48kHz and the timestamp in the broadcast wave is 96000, the SMTPE timecode equivalent is 2 seconds. It’s when we need to calculate the number of frames where it gets “interpretive”, because as I mentioned the FPS isn’t (normally) stored in the file and you HAVE to know this in order to convert the number of samples back into timecode correctly… if you don’t know how long “a frame” is, you don’t know how many samples make up a frame. This can throw your timecodes off drastically if for instance you were working at 30fps when you should have been at 29.97, and someone tries to import your export assuming it’s 29.97 when it’s not.

As for the BPM, unless you tick the 'Insert iXML Chunk’ AND ‘Insert Tempo Definition’ in the export dialog, the BPM isn’t stored in the file either – so probably something similar is happening where it’s doing some arbitrary math and making up a BPM… but the BPM has nothing to do with the timecode regardless.

One bug I DO see however, is that when you export a mixdown from Cubase selecting a different samplerate than your project, Cubase doesn’t calculate the correct samples-since-midnight timestamp based on the samplerate you’re actually exporting at; It always uses the project’s samplerate. So if you are in a 96kHz project but run a mixdown and set it to 48kHz in the dialog, the samples-since-midnight will still be calculated at 96kHz and the the ‘timecode’ of the file will actually be twice the value it should be.

7

Oh, by the way… I actually just looked at some exported mixdowns from Cubase 6.0.3 anyway, and if you write the iXML chunk it does indeed tag it with the framerate. So anyone else reading the file who understands the iXML extensions should be able to get the correct code back out of it.

That said, just recording or Bouncing files in Cubase with the record format set to Broadcast Wave does NOT appear to create an extended iXML chunk that includes the framerate or tempo it was recorded at, so the ‘interpretive timecode math’ I explained would still apply… IE if you import the file into a project with a different framerate it will come up with a different timecode and a wacky BPM. This seems to be another design flaw/bug.