Go Back   Cockos Incorporated Forums > Projects > Deprecated REAPER issue tracker > Closed Issue

BWAV Timecode incorrect if timeline project is not 30FPS Issue Tools
issueid=4213 06-27-2012 09:05 AM
Human being with feelings
BWAV Timecode incorrect if timeline project is not 30FPS
The BWAV timecode doesn't correspond to the timeline TC

When rendering regions, the timecode embedded in the files is NOT correct unless the project framerate is set to 30. This turn useless any render for video projects which require accurate TC metadata in the audio clips for sync.

Steps to reproduce
1-Set your project to 29.97NDF and the timeline showing hours:Minutes:seconds:frames
2-record or import any audio
3-create a region and render that audio using "project region" in render bounds on the render window
4-check the metadata of your file(TC start) using Wave Agent (Sound Devices) or BWAV Reader, or ProTools or Final Cut
5-The Start TC is wrong. It doesn't match what is written in the timeline
6-set the timecode to 30
7-repeat steps 2, 3 and 4 and check the metadata again.

The Metadata is right ONLY using 30fps as timecode framerate.
If you need screen-captures or additional info please let me know where to send them.

This is a sensitive feature I would like to solve in order to use Reaper in a massive AAA game recently introduced in E3.

Thank you so much

Eduardo
Issue Details
Issue Type Closed Issue
Project Deprecated REAPER issue tracker
Category Audio recording and playback
Status Not a Reaper Bug
Priority 2
Affected Version 4.22
Closed Version (none)
Yes votes 1
No votes 0
Assigned Users (none)
Tags (none)

06-27-2012 10:50 AM
Administrator
 
The timecode in BWF is stored in samples, not in HMSF... So I'm not sure how this could be. REAPER's timecode setting should not affect BWF writing in any way. Is it possible you have a project time offset set which is offsetting the expected value? If you could post sample projects and expected outcomes, that would be helpful.
Reply
06-27-2012 11:21 AM
Human being with feelings
 
Hi Justin, thanks for your fast reply.
Yes I understand that, but somehow the interpolation between samples and timecodes that are not 30fps burn incorrect information in the bwav file.
I attached a project with one item and the file I exported from the timeline, as you can see the region starts at 08:01:21:25, however the metadata in the file is 08:01:21:27
Also I attached a screen-grab from Wave Agent, the free sound Devices software to read metadata (very helpful to have in a toolkit as well)showing the metadata info.
Thanks again
Reply
06-27-2012 11:29 AM
Human being with feelings
 
Sorry, I'm at the studio and for security reasons I can't upload anything through the network, will do later from home.
Cheers,
Eduardo
Reply
06-27-2012 03:20 PM
Administrator
 
From your description it sounds like the difference is 2 frames, and it may be a difference in frame calculation between REAPER and the others. Are they all configured in 29.97 non-drop?
Reply
06-27-2012 04:07 PM
Human being with feelings
 
The difference is incremental that's why I think is an interpolation problem, move the item 4 hours later in the timeline and you'll get a greater difference.
The project was configured at 29.97 and also every other software I mentioned here.
There are no offsets or timecode shifts applied at any part of the chain.
Reply
06-27-2012 04:43 PM
Human being with feelings
 
I just tried to verify with a 48kHz, 29.97ndf project.

I created markers at each hour from one to eight. No session offset.

BWAV Reader listed the resulting timecodes as follows :
Code:
01:00:03:18 (108 frames)
02:00:07:06 (216 frames)
03:00:10:24 (324 frames)
04:00:14:12 (432 frames)
05:00:18:00 (540 frames)
06:00:21:18 (648 frames)
07:00:25:06 (756 frames)
08:00:28:24 (864 frames)
That's a delta added to each hour of 155.520.000 samples or 3.6 seconds.

The full session plus render results are here (all sine waves, so very compressible):
https://stash.reaper.fm/13151/4-23-pr...97-renders.zip (315 kB)
Reply
06-27-2012 05:26 PM
Human being with feelings
 
Thanks for contributing to the discussion Airon.
So we have an incremental shift.
The delta is 3.6 seconds since the diference between 30fps and 29.97 is a slow down of 0.1% but I can't get why the timecode that we see in the timeline is not reflected in the bwav file.
Is like not matter what I do the timeline "acts" as is it were 30fps
Other test: set your start time at 08:00:00.000 and framerate ad 29.97ND, the timeline starts at 07:59:31:06 not at the time we set. I'll attach screen-capture of this as well
Reply
06-27-2012 05:44 PM
Human being with feelings
 
I uploaded a screenshot corroborating Airon exports in WaveAgent, notice that the amount of samples from midnight in the first region (supposedly 01:00:00:00) is 172972799 when it should be 172800000 samples (at 48Khz of course)
Reply
06-28-2012 08:47 AM
Human being with feelings
 
It seems that Reaper is simply not in fact running its sample counter at 29.97 fps speeds, but at the 30fps. It's the only explanation I can think of.

The 30 fps grid in 29.97 sessions actually runs that 0.1% slower, but it isn't here.

Would I be correct in this assumption ?
Reply
06-28-2012 10:08 AM
Human being with feelings
 
You're correct the sample counter and the correspondent matching frame only work for 30fps.
The amount of samples per frame should change when we set another framerate for the project and that's not happening.
According to Reaper, 1 hour at 30fps is 172800000 samples while 1 hour at 29.97 is 172972883. Let's be clear that 1 hour is ALWAYS 1 hour no matter the framerate.
Therefore, instead of changing the amount of samples per frame, Reaper moves the timeline but underneath is always acting like 30fps no matter where you position your files.
Hence, for framerates different than 30 the timeline is just cosmetics, the amount of samples since midnight corresponding to that frame will be incorrect in the file when you export.
Oh man, I wish the developers can fix this one and start using REAPER to record in the motion/performance capture sessions of the game and kick ProTools out of the stage ;)

Thanks for the support!
Reply
06-28-2012 10:40 AM
Human being with feelings
 
Oh dear. The exact same fun happens with 23.976 sessions.

Wave Agent reveals the same discrepancies :



The session and resulting files(now in space-saving mono :P ):
https://stash.reaper.fm/13157/4-23-pr...76-renders.zip (71kB)
Reply
07-02-2012 06:13 AM
Human being with feelings
 
gonna add my 2c worth to this one as well.

I'm doing a playback session for a video shoot which is being shot at 23.98fps NDF.

I need to position a clip at a known timecode value. I am doing this by editing the item properties and setting the timecode value in the item properties. Problem is that the resulting position in the timeline/ruler is different from the one I am putting into the properties dialog.

I am able to reposition the clip if I drag it to the correct place in the timeline, but not otherwise.

This may be an issue with pull-down timecode formats (such as 23.98)

Big round of applause for actually supporting 23.98 timelines in Reaper. I also use Sequoia and it doesn't.

But what would be _really_ good is if the timecode generator would also generate 23.98 fps timecode. It does support 24fps but not 23.98.

I am working around this by creating a 24fps timecode WAV at 48048 and then hacking the RIFF header to stamp it with 48000 sampling rate. This allows me to dump it into the timeline and it plays back at 23.98fps.

Would love to use the in-built timecode generator for this if possible.

cheers,

Mark.
Reply
07-02-2012 06:19 AM
Human being with feelings
 
Quote:
Originally Posted by Edufighter
According to Reaper, 1 hour at 30fps is 172800000 samples while 1 hour at 29.97 is 172972883. Let's be clear that 1 hour is ALWAYS 1 hour no matter the framerate.
Actually, I think I might need to respectfully disagree with this statement. Pull-Down timecode formats such as 23.98 and 29.97 run at a slower time speed than their "non-pull-down" equivalents... This is because of the NTSC timebase discrepancy of 1000/1001.

So in reality, 23.98 is actually 24fps but running at a 0.1% slower timebase. Same with 29.97 (30fps running at 0.1% slower timebase).

Drop Frame timecode modes exist to correct the timebase. (there isn't a DF mode for 23.98fps)

There is an off-board post which explains it very well...

http://www.motunation.com/forum/view...=39678#p331143

but this means that with pull-down formats, an hour isn't actually an hour. If you are expecting it to be then you will find your audio doesn't sync up.

m
Reply
07-02-2012 07:08 PM
Administrator
 
Right, in 29.97ND, the video timecode is running at a rate that will drift from the actual audio time.

Also, BWF encodes timestamps in audio time (_NOT_ in a framerate+timecode format, at least not that we support -- if there is a standard extension for this, we would look at it), and REAPER sets that timestamp to the audio time...

Is it safe to say that this is not a bug then?
Reply
07-02-2012 08:20 PM
Human being with feelings
 
Hi Justin.

I'd have to say that I think there is something not quite right with the way that the timelines, the item timebase and positioning work when on 23.98fps

If the ruler is running at 23.98fps and I relocate an "item" I think that an expectation that it will appear at exactly that timecode setting with respect to the ruler - is a reasonable one.

To recreate

1. create empty project with project timebase of 23.98fps
2. create a new track and an empty item.
3. Select the item and change the properties.
4. set the "position" in time to 00:08.000

Note the position on the timeline is to the left of 00:00:08:00

5. Disable snapping
6. Drag the item to 00:00:08:00 on the timeline ruler. (this will be indicated also in the item tooltip)
7. Inspect the properties dialog for the item

Note the position indicated in the item properties will be 00:08.008

BUT - if I change the framerate to 25fps then everything works as to be expected - Item position properties matches the timeline.

cheers,

mark.
Reply
07-03-2012 12:48 AM
Human being with feelings
 
Hi,

I think that this bug is connected to this other:

http://forum.cockos.com/project.php?issueid=4207

Bye!
Reply
07-03-2012 06:07 AM
Human being with feelings
 
Confirmed your issue as well Cabal.

If I had the power I'd erase NTSC on the spot.

Some facts to check :

1)
23.976 is a 24 fps timecode that runs 0.1%(exactly!) slower. Thus 23.976 timecode does not actually reflect real time but just frames counted.

There is no dropframe compensation in the timecode to correct for this SMPTE-frame-counting-timecode versus real-actual-time-elapsed-in-mmss disparity. Because of this, 23.976 can be said to be a non-drop-frame timecode.


2)
The same applies to 29.97 and 30 fps timecode. If you want to know how much real time the material is long, you have to keep a minutes&seconds timeruler handy.

Here however, there is a Drop Frame variant that compensates for this SMPTE-frame-counting-timecode versus real-actual-time-elapsed-in-mmss disparity. However, even the Drop Frame variant of the 29.97 timecode is not identical to the normal clock time, except where the compensation is made.


The details can actually be read about here:
http://en.wikipedia.org/wiki/SMPTE_t...frame_timecode


Some things to change are what you display in the item properties.

The timecode shown should use the time ruler by default. It always shows clock time in hours, minutes, seconds and milliseconds right now. The time-ruler however is what people actually refer to. When people spot things to a specific timecode, you're effectively shutting off the method of entering that timecode in the item properties by only displaying and allowing clock-time in the position field.

It may be necessary at some point to define a "primary time ruler", because sooner or later people who compose to picture will require more than one time ruler to be shown at the same time anyway. B&B and timecode.


Then, the sample count you place in the timecode field in the BWF chunk depends heavily on the SMPTE timecode used in the session the file emanates from. The real time that Reaper counts with its double-float counters has to be translated in to legal timecode and then back again to the sample-count value that reflects that time-code. It's not REAL TIME for 23.976, 29.97DF and 29.97NDF. Weird^10, but there you go.

I do not envy you Justin, or the folks in NTSC land.
Reply
07-03-2012 06:40 AM
Human being with feelings
 
While we're at it, can I add a feature request for us film post-production types... when "spotting" effects and cues, it is often very important to be able to specify locations by timecode.

I may be wrong, but the "time" option available in the "item properties" seems to be h:m:s.ms rather than hh:mm:ss:ff - the latter of which would be much more useful in an audio post context.

Any chance of having this option?

m
Reply
07-03-2012 07:26 AM
Human being with feelings
 
-edit-

In Wave Agent there is a check box that allows the user to "Preserve Start TC". If that is checked, the results are what you see below.

If it is unchecked before import, and you then pick the frame rate 23.976nfd (actual entry name is 23.97nd), you get a 00:12:00:00 timecode.

Just wonderful.

I'm reluctant to do so, but I'll install Protools 9.05 and see what its thinks about these files.

We need to re-review all our other tests to see if this boils down to user error or not.

In any case, the timecode display in the item properties is not usable for SMPTE timecode entry, so that defintely needs to be improved to prevent incidents as the ones described. For Grud's sake I hate timecode trouble.

===============
Might have something.

48kHz, 23.976 fps, 00:08:00:00 (8 minutes) session offset.
  • Jumped to 00:12:00:00 and created a marker and an empty item of about 8 seconds length.

  • Glued the item, renamed it to "00 12 00 00 tc23976 sessionoffset00080000.wav".

  • Copied the item to a track below and glued it, renaming it "00 12 00 00 tc23976 sessionoffset00080000.wav glued.wav"

  • Ran the command "Item: Move to source preferred position" on both files and they remained stationary.

  • I make a copy of the second file and name it "00 12 00 00 tc23976 sessionoffset00080000.wav_glued_NewSetTimecode.wav ". I intend to edit its timecode in Wave Agent and see what Reaper makes of it.

  • Threw the second file in to Wave Agent (v1.16).

    It shows the timecode 00:12:00:21. However, the frame rate field was empty. I pick 23.976ndf which is the only 23.976 timecode there is, and write back the changes.

  • I toss the copy of the second file ("00 12 00 00 tc23976 sessionoffset00080000.wav_glued_NewSetTimecode.wav ") in to Wave Agent.

    Edit the timecode to 00:12:00:00 and set the frame rate to 23.976ndf. Write back the changes.

  • Then ran the command "Item: Move to source preferred position" on all items.

    First item stayed where it was. The second item was moved to 00:12:00:21. The third item remained where it was.

The session with the items and some documentation in the form of empty items.
https://stash.reaper.fm/13220/4-23-pre18-23976-tests.zip (7 kB)


The result apparently is that Reaper for one does not write a frame rate to the BWF chunk, if that is possible.

Wave Agent wrote back a chunk that apparently sends the Reaper stuff back by 64 bytes. Interesting.

Reaper does however place a moved item back in to the proper position, so it can read its own timecode just fine.

Reaper also places items whose timecode was written with Wave Agent at the proper position on the time ruler, so it can interpret timecodes just fine as well.

The problem is that the timecode Reaper writes, only Reaper can interpret correctly. I'll conduct some more tests. Perhaps Reaper simply needs to write the frame rate in to the BWF chunk as well for others to interpret the timecode correctly.

Wave Agent is available here: http://www.sounddevices.com/products/waveagent.htm
Reply
07-03-2012 08:37 AM
Human being with feelings
 
Some followups that all point to user error regarding the handling of timecode produced by Reaper.

BWAV Reader 1.0b interprets all timecodes seemingly without a frame rate reference. I can't set a frame rate anywhere, so essentially it's almost worthless for checking these things.

What it did reveal is that the files that Wave Agent wrote back to, and for which I had set a frame rate in Wave Agent, actually writes back the frame rate in the DESCRIPTION field of the "bext" chunk in the form of this string :

sSPEED=023.976-ND

Which is an interesting method. Wave Agent also writes a new iXML chunk that contains all manner of data. This iXML chunk is standardized, so Reaper might do well to start writing that as well.

iXML has been around for a few years now. Quite a few DAWs, software recorders and hardware support it. Protools (since v7.2), Pyramix, SADIE, Nuendo and Final Cut Pro can all use these chunks.

Some information at Wikipedia and the iXML site itself. An apparently good writeup of what iXML is and why it exists (PDF).

Supporting that standard as well might help avoid any timecode messes. It's well worth a test, and hopefully not a huge deal to support. It can contains a lot of information that Reaper produces, such as take information, recording speed and so on. That way functions could be written to correct the playback rate of recordings made with varipitch recording or revert back to its original rate for example, since all the needed information can now be recalled from the iXML chunk of the WAV file.

Most importantly, it can contain the actual timecode rate and has a specific flag for designating Non-Drop and Drop-Frame rates.

What a load of fucking trouble, eh.
Reply
07-03-2012 01:52 PM
Human being with feelings
 
Thank you very much edwar64896 and Airon, lot of research was done here I while I was distracted working ;)
The translation from sample count to timecode data readable by other software (ProTools and FinalCut mainly) would be a great improvement and it should solve this issue where the timeline position doesn't reflect the information inside the item.
I'll compare files I have in a ProTools session against files I have in Reaper with the same timecode start in the timeline, to see what else differs in the metadata.
Keep you posted.
Cheers,
Reply
07-09-2012 08:43 PM
Human being with feelings
 
Hi again,
So here's another chapter in this timecode labyrinth that throw partially all my assumptions through the window...
I tried to compare how ProTools deal with positionalinfo and Bwav data and did a quick test:
1- Created a ProTools 9.0.1 session 29.97ND - Project StartTime 08:00:00:00
2- Created a clip with the signal generator exactly at 08:01:30:00
3- Exported that clip
4- Creater a Reaper 4.22 session at29.97 - Project Start Time 08:00:00.000
5- Imported the exported PT clip and looked in the Media ItemProperties... (see attachment)
6- Copy the Start offset info in the position cell and TA-DA! dead spotted in 08:01:30:00 (even when the start offset was 8:01:58.890)
7- Created a region and exported the region, then reimported it in the same REAPER project, went to the files properties and... SAME START OFFSET! copy the number in the position info and perfect aligned with the ProTools-created file at 08:01:30:00
8- compared both files in WaveAgent and both files showed the same TC Start 08:01:58:26, and NOT the 08:01:30:00 where they were created. (See atttach)

MOST IMPORTANT THING:
When in ProTools using SPOT to position the reaper-created clip, the original timecode showed 08:01:30:00
Imported then the same clip in FinalCut Pro and it recognized the start time at 08:01:30:00
That means it worked for my purposes.
So apparently the BWAV info is CORRECT and this is not technically a bug, what is still deceiving is the information showed in the properties that doesn't interpolate to the correct timecode as ProTools or Final Cut do.

to be continued...
Reply
07-11-2012 07:20 PM
Human being with feelings
 
Try disabling the "Preserve Start TC" checkbox in Wave Agent before importing the files for checking.

After import in to Wave Agent set the frame rate to 29.97nd. The correct timecode should show up.
Reply
Reply

Issue Tools
Subscribe to this issue

All times are GMT -7. The time now is 01:51 AM.


Powered by vBulletin® Version 3.8.11
Copyright ©2000 - 2020, vBulletin Solutions Inc.