The new version history states:
“R-12724 EXPORT AUDIO:BWF timecode information is now included correctly when a batch export is performed using cycle markers.”
For which versions does that NOT work? I delivered files recently and the delivery specification requires that information to be correct. I would be beyond upset if this didn’t work correctly.
I’m guessing that 6.5 was doing the error, whilst 6.1 was not. I found issues importing BWAVs into FCPx, with N6.5, but I have not tested 6.53. And I am guessing - I didn’t do anything mission critical with N6 as yet.
I had thought FCPx was the problem: my batch export all shared the same TC metadata of the first file exported. So of a batch of 5 files, the first was correct but the rest were showing the TC of the first file.
If you’re really worried (and I would be) can you find a way to test the files you delivered?
Scary.
There’s a 6.1?
Not to resurrect a dead thread here… but we have been getting an issue where FCP will display timecodes that differ from what Nuendo claims the origin time is. It’s distressing because some people expect things to just work. When the timecode doesn’t line up correctly they panic and use the music instead of the two pop, and a whole slew of confusion comes afterward as to sync.
For whatever reason the TC start is also read differently in the Sound Devices Wave Agent program. I have been trying to get the bottom of why the TC would be off and haven’t had any luck figuring out the source of the issue.
Thanks,
Josh
What version were you on?
I am on multiple systems. Was there a fix for this in version 6.5?
N6.0.7
Windows7 64, Gigabyte MB i5 4gb RAM
As Lydiot said in his first post, there is a fix in 6.5.
http://support.steinberg.de/downloads_software/Nuendo_6/6.5.30/Nuendo_6.5.30_VersionHistory.pdf
Fredo
jvamos,
Are you exporting at the same sample rate of your initial project?
I see some weird things.
First of all, exporting files from Nuendo, and re-importing them “at origin” works perfect.
However, importing these files into Wave Agent …
Exporting (batch or normal export) at the same sample rate as the project shows a discrepancy of 3 frames.
Exporting at another sample rate shows an even bigger Timecode shift.
To be able to identify the problem, we will need to run a series of tests with files generated from another application than Nuendo and another Timecode verification application than Wave Agent.
Can you please run some tests too that expose your problem?
(Please use the latest 6.5)
Fredo
For what I can tell for the moment.
Record file in Nuendo and import file into Groove Agent.
There is no difference between a recorded file, a “normaly” exported file and a batch exported file.
(There is a difference if you have a pre-record time dialed in)
I do however see a couple of frames difference reading in Wave Agent.
I still need to find out if that difference also manifests itself in another application than Wave Agent.
And how files recorded in another application (for example a Sound Devices) show there results in Wave Agent vs Nuendo. And how they import into Nuendo.
Fredo
I’ve been working like a dog and haven’t had the time to trouble shoot this, but the very brief testing I did showed that in Pro Tools the file would lay in at the correct timecode assuming correct frame rate, but not if frame rate was different. So a bwav with a start time at 01:00:00:00 should lay in at that point regardless of frame rate (since drops aren’t on the hour for example) but it only did when frame rate was matching.
Have you experimented with this as well? I’m not sure if that’s normal behavior for a bwav file.
I’ll try to find time to test today. But as I said; if this isn’t working properly I’m guessing I’m not the only one who may have delivered files supposed to have been time-stamped that’ll be in potential trouble. I really hope this is not the case.
There are a couple different flavors of Broadcast WAV. The specs don’t really contain a SMPTE timecode, it contains a timestamp expressed as “the number of samples since midnight” – but it doesn’t contain the framerate, so it will be different depending on what fps you do the calculation at. That can explain why the timecode shows up wrong in some apps - Media Composter for instance will ask you on import at what framerate you want to interpret the timecode as being.
Here’s the output from a little app I wrote years ago to look at BWAV headers, and you can see how the timecodes differ depending on what fps you assume the sample count to be:
Found chunk: [bext] - Broadcast Wave
Description :
Originator : TASCAM PCM Recoder DR-07MK2
Originator Ref :
Origination Date : 2014-05-24
Origination Time : 14:19:59
Samples/Midnight : 2476174848
Found chunk: [fmt ] - WAVE Format
Format Tag : 0x0001 (PCM)
Channels : 2
Sample Rate : 48000
Data Rate : 192000 bytes/sec
Found chunk: [data] - Audio sample data (Length 2359296)
Based on the samplerate of this file,
starting timecodes could be:
29.97fps (NDF) : 14:18:55:13 - 1546063 frames
29.97fps (DF) : 14:19:46:29 - 1547609 frames
25fps : 14:19:46:24 - 1289674 frames
24fps : 14:19:46:23 - 1238087 frames
23.98fps : 14:18:55:10 - 1236850 frames
There is an extension, the “iXML chunk” which you can add on export that DOES include the framerate and would allow the reading app to correctly calculate the timecode, but it’s not necessarily widely supported by all audio-handling apps.
Thanks man(chicken).
It makes me wonder though just what problem was fixed in this latest release, and in which versions that problem was present. It’s quite frustrating that Steinberg can’t answer such a simple question.
Well I think this thread has diverged into two separate problems; The original post being about batch exports where the resulting files all got the same timecode of the first file in the batch, and that’s what was fixed in 6.5.30 based on the release notes; then your issue where the timecode of any export seems to not be quite right in other apps, which probably is not a bug of Nuendo based on the nature of Broadcast WAVs as I pointed out above (but could be a bug if it’s actually writing the wrong ‘samples since midnight’ value to begin with.)
For what it’s worth, if you would like to look at some of your files in Windows with my little app, download it from http://clients.idolum.com/get/d432f71253eb and then run it from a Command Prompt, like:
C:\Peepshow.exe D:\MyInputFile.wav
assuming you throw the EXE on the root of your C: drive; tweak as appropriate.
Now, having said all that, I just exported a little test file from Cubase 7.5.30 at 01:00:00:00 at 23.98fps; Both Cubase and Nuendo 6.0.7 demo (all I’ve got at home) will show the same Origin Time as my app does, depending on how I set the project frame rate in Cubase. So even though I wrote the iXML in the export, which shows the rate correctly as 24000/1001, Cubase/Nuendo don’t seem to actually pay attention to it and assumes the frame rate of all your files is the frame rate of your project.
Thanks, this is half of the info that I was looking for. So just to be super-clear (and since I haven’t found this information anywhere else yet):
does this mean that if I batch-export a show’s 6 segments individually, all of them will get 01:00:00:00 as the start time code despite them starting at different locations?
And then to Steinberg - AGAIN: WHICH VERSIONS HAD THIS ERROR???
(sorry for yelling)
And double-thanks to you ManChicken for being so helpful!
does this mean that if I batch-export a show’s 6 segments individually, all of them will get 01:00:00:00 as the start time code despite them starting at different locations?
Yes – or in my case it took the code from the last cycle marker in the list, not the first as the OP reported.
And then to Steinberg - AGAIN: WHICH VERSIONS HAD THIS ERROR???
I just tried it in 6.0.7 and it seems to work (unless it was an intermittent bug) but in 6.5.20 it is broken. So it seems like it was probably a 6.5 release bug, fixed by 6.5.30.
Thanks a million.
Bug confirmed.
BWF timecode written upon export is incorrect. (a few frames)
Fredo
On which version Fredo, and under what conditions?
Export in 6.5.3
Fredo
So you’re saying it’s broken in 6.5.3 despite Steinberg saying that it’s fixed?