Magic Lantern Forum

Developing Magic Lantern => General Development => Topic started by: g3gg0 on August 19, 2013, 01:52:01 AM

Title: [Module/5D3] SMPTE experiment, not usable
Post by: g3gg0 on August 19, 2013, 01:52:01 AM
can someone with SMPTE equipment try this module?

SMPTE output module (http://upload.g3gg0.de/pub_files/fe67d8c0aa61cc796f5d5b620494d0d6/smpte.mo)

i developed it on 5D3, it is likely that other models that have audio support will work too.
as i dont have any equip and there are no free tools to read SMPTE, i cannot test what it produces.
Title: Re: [Module] SMPTE experiment
Post by: Greg on August 19, 2013, 02:10:28 AM
500D has problems with sound, so I can not check.  :(
ASSERT: FALSE
at SoundDevice\SoundDevice_CODEC.c:1080


Title: Re: [Module] SMPTE experiment
Post by: 1% on August 19, 2013, 02:47:55 AM
The audio MS and video ms frames don't match but its making noise.
Title: Re: [Module] SMPTE experiment
Post by: AnotherDave on August 19, 2013, 03:22:12 AM
Here is a link to a demo program that could help...

http://www.videotoolshed.com/product/26/auxtc-reader
Title: Re: [Module] SMPTE experiment
Post by: AnotherDave on August 19, 2013, 05:27:15 AM
I recorded a sample of the audio, but haven't been able to get any software to recognize TC on the track.

But this is off to a great start!

I know it is really in development, but I wanted to test to see how it effected RAW recording.  Unfortunately, it shuts off the instant RAW REC is initiated.

Output only works if the audio jack is plugged in after the module is started.

Pretty awesome stuff! :-D
Title: Re: [Module] SMPTE experiment
Post by: g3gg0 on August 19, 2013, 11:41:27 AM
thanks.
i am at work at the moment, so i cannot test it myself.
Title: Re: [Module] SMPTE experiment
Post by: g3gg0 on August 19, 2013, 08:19:36 PM
this (http://upload.g3gg0.de/pub_files/8d984fc3d9f549455e4fabd729de17cf/smpte.mo) one any better?
Title: Re: [Module] SMPTE experiment
Post by: AnotherDave on August 19, 2013, 08:43:48 PM
The sound output still shuts off when I start recording, but I'm assuming that isn't what the test was for...

It also locks the camera after you initial a raw recording with it on, and attempt to re-engage the module without a restart.

I will test the track now and see if it does it!

*Very exciting stuff!  It might not be a bad thing that the audio generation stops once you hit record if the proper software can be created to embed the TC information throughout the clip.  But I'm dying to find out if it effects the RAW_REC. 

Important side note, I'm using RAW_REC V1... I don't have a windows computer to be able to decode the .mlv files.
Title: Re: [Module] SMPTE experiment
Post by: AnotherDave on August 19, 2013, 08:58:52 PM
FCPauxTC definitely read some kind of TC information on the last pass, but I don't see it on the exported clip.  I also don't know the software that well...

I don't own a smart slate, which would make this super easy...  I might try that Movie Slate app for the iPhone.
Title: Re: [Module] SMPTE experiment
Post by: AnotherDave on August 19, 2013, 09:01:41 PM
There is also a free app called ClockIt that might work...
Title: Re: [Module] SMPTE experiment
Post by: g3gg0 on August 19, 2013, 10:01:42 PM
Quote from: AnotherDave on August 19, 2013, 09:01:41 PM
There is also a free app called ClockIt that might work...

ClockIt: iPhone app. dont have any iphone
auxtc-reader: can you explain how to make it read from sound card instead of quicktime files?
Title: Re: [Module] SMPTE experiment
Post by: AnotherDave on August 19, 2013, 10:25:40 PM
Quote from: g3gg0 on August 19, 2013, 10:01:42 PM
ClockIt: iPhone app. dont have any iphone
auxtc-reader: can you explain how to make it read from sound card instead of quicktime files?

I don't think it is capable of reading from the sound card.  It's just for reading a TC channel and turning it into a embedded TC track.

Trying the app now, but I can't find a 1/4" to 1/8" adapter to use my iRig (so I can input sound)....  :-/
Title: Re: [Module] SMPTE experiment
Post by: AnotherDave on August 19, 2013, 11:14:26 PM
I know you don't have an iOS device - which sucks cause that would make this super easy - but if anyone else is giving this a shot... try TC Toolbox.  It can also generate TC too.

*The information being generated seems far more complex, and MUCH louder.
Title: Re: [Module] SMPTE experiment
Post by: g3gg0 on August 19, 2013, 11:34:18 PM
btw, i dont care yet about anything related to recording.
its just about: can the signal be decoded.

it should count up frames, seconds, minutes and hours from zero.
Title: Re: [Module] SMPTE experiment
Post by: AnotherDave on August 19, 2013, 11:57:34 PM
Oh, ok.  That might be the issue right there.

Everything I know of is designed to read hours, minutes, seconds, frames...

Would it be possible to get it to output H:M:S:F based on the internal clock?  That's FREE RUN timecode, exactly what the TC app is doing.
Title: Re: [Module] SMPTE experiment
Post by: tonybeccar on August 20, 2013, 12:28:52 AM
I was fast reading this.. and wanted to add that there IS an android app, which I downloaded but I haven't tested which can generate timecode, it's called LTC Timecode Generator. Hope it helps.
Title: Re: [Module] SMPTE experiment
Post by: jonas18z on August 20, 2013, 12:47:17 AM
Maybe this is can take audio input from same company:

http://www.videotoolshed.com/product/8/ltc-reader

or:

http://ltcsmpte.sourceforge.net/

http://www.musicsensorsemotion.com/2010/09/21/smpte-matlab-decoder/

http://ardour.org/
Title: Re: [Module] SMPTE experiment
Post by: g3gg0 on August 20, 2013, 12:50:01 AM
Quote from: jonas18z on August 20, 2013, 12:47:17 AM
http://www.videotoolshed.com/product/8/ltc-reader
doesnt work, just sound dev open errors

Quote from: jonas18z on August 20, 2013, 12:47:17 AM
http://ltcsmpte.sourceforge.net/
http://www.musicsensorsemotion.com/2010/09/21/smpte-matlab-decoder/

first is a library, second a script for matlab.
Quote from: tonybeccar on August 20, 2013, 12:28:52 AM
I was fast reading this.. and wanted to add that there IS an android app, which I downloaded but I haven't tested which can generate timecode, it's called LTC Timecode Generator. Hope it helps.

we need a reader to read timecode...

Quote from: AnotherDave on August 19, 2013, 11:57:34 PM
Oh, ok.  That might be the issue right there.
Everything I know of is designed to read hours, minutes, seconds, frames...
huh? i am counting up them, so whats wrong with it?

Quote from: AnotherDave on August 19, 2013, 11:57:34 PM
Would it be possible to get it to output H:M:S:F based on the internal clock?  That's FREE RUN timecode, exactly what the TC app is doing.
right now it is counting up from zero, which shouldnt matter.
Title: Re: [Module] SMPTE experiment
Post by: jonas18z on August 20, 2013, 12:53:49 AM
Quote from: g3gg0 on August 20, 2013, 12:50:01 AM
doesnt work, just sound dev open errors



* Setup -> Set TC input soruce [Restart]


Don't have any camera ATM....
Title: Re: [Module] SMPTE experiment
Post by: g3gg0 on August 20, 2013, 12:57:19 AM
yeah did that.
any sound card i select causes this tool to fail open it.
no matter if XP compatibility, admin rights etc.
tried 4 sound cards, two internals and two usb chips.
Title: Re: [Module] SMPTE experiment
Post by: g3gg0 on August 20, 2013, 01:45:11 AM
here (http://upload.g3gg0.de/pub_files/c4c002526f3af2efaf56c3f991a9d958/smpte.mo) another version with volume control.

inversion is just in case i output with the wrong polarity - might help while testing.
Title: Re: [Module] SMPTE experiment
Post by: AnotherDave on August 20, 2013, 02:22:11 AM
Still nothing on the iOS apps I'm testing it with.
Title: Re: [Module] SMPTE experiment
Post by: g3gg0 on August 20, 2013, 12:48:59 PM
but you had sync once, right?
Title: Re: [Module] SMPTE experiment
Post by: AnotherDave on August 20, 2013, 02:44:58 PM
FCPauxTC was able to read something... but I'm not sure what.

Is it possible to have the TC signal from the camera be a read out of the time from the internal clock in HH:MM:SS:FF?

If so, you could jam sync it to an external recorder or slate on free run...  and probably wouldn't even have to leave the module running.

You're writing TC information into the new .mlv standard, right? 

Title: Re: [Module] SMPTE experiment
Post by: g3gg0 on August 20, 2013, 03:28:58 PM
uhm...
yet i am still trying to get a valid encoded signal.
how this would interact with MLV/raw_rec is another story, which will be written when it's time to.

and yes, it is writing the current time, but this is just a data filler.
it will be inaccurate and not reliable.
Title: Re: [Module] SMPTE experiment
Post by: AnotherDave on August 20, 2013, 04:52:03 PM
I still can't get any of the smart slate apps to read it.

I did read somewhere that you could put a time stamp in the header of the file, which could be read and interpreted into TC by the conversion program (mlv2dng).

Title: Re: [Module] SMPTE experiment
Post by: g3gg0 on August 20, 2013, 05:17:22 PM
even when inverted, no sync?
Title: Re: [Module] SMPTE experiment
Post by: AnotherDave on August 20, 2013, 07:34:06 PM
Still nothing showing up for me on the smartslate apps...

*Just a thought.  I know it would be more difficult to create a module that reads TC audio, but would it be possible?  If you could create one that read the signal, and sync the camera's internal clock with to it (it'd have to be free run tc) that would be even better as it would allow you to eliminate the need to output the signal (and whatever hardware you would use to do it).

That'd also have the added advantage of allowing people to sync multiple 5D3s with and iPhone running TC Toolbox.

Title: Re: [Module] SMPTE experiment
Post by: g3gg0 on August 20, 2013, 11:22:51 PM
another try (http://upload.g3gg0.de/pub_files/78598870f56e3c2f45ed7a6f3fb87034/smpte.mo)
Title: Re: [Module] SMPTE experiment
Post by: g3gg0 on August 20, 2013, 11:38:29 PM
Quote from: AnotherDave on August 20, 2013, 07:34:06 PM
Still nothing showing up for me on the smartslate apps...

*Just a thought.  I know it would be more difficult to create a module that reads TC audio, but would it be possible?  If you could create one that read the signal, and sync the camera's internal clock with to it (it'd have to be free run tc) that would be even better as it would allow you to eliminate the need to output the signal (and whatever hardware you would use to do it).

That'd also have the added advantage of allowing people to sync multiple 5D3s with and iPhone running TC Toolbox.

as said. i would prefer to first have the output working, then i want to integrate it.
and then we can talk about such stuff
Title: Re: [Module] SMPTE experiment
Post by: g3gg0 on August 21, 2013, 04:38:12 PM
had any time to test the new version yet?
Title: Re: [Module] SMPTE experiment
Post by: stevefal on August 21, 2013, 06:15:58 PM
I have a variety of LTC gear, but I'm getting no output from the module. 5D3.

[EDIT] Ah, movie mode :) I'll give it a try.
Title: Re: [Module] SMPTE experiment
Post by: stevefal on August 21, 2013, 07:25:08 PM
No lock at all. The LTC audio is not a clean square wave.
Title: Re: [Module] SMPTE experiment
Post by: AnotherDave on August 21, 2013, 07:27:08 PM
Sorry this update totally got past me.

Just tested it out with BAD, but GOOD results too!  It is outputting a signal the TC Toolbox can read... but... it's all garbled.  :-/

https://dl.dropboxusercontent.com/u/21985365/IMG_1426.MOV

Took a video of the iPad screen so you can see what it is doing.
Title: Re: [Module] SMPTE experiment
Post by: stevefal on August 21, 2013, 07:30:29 PM
(http://i.imgur.com/g0Dsi61.png)
Clean timecode

(http://i.imgur.com/enHmeAo.png)
Output from SMPTE module
Title: Re: [Module] SMPTE experiment
Post by: mageye on August 21, 2013, 09:27:35 PM
@stevefal

Looks like it's being LPF'd  :(
Title: Re: [Module] SMPTE experiment
Post by: stevefal on August 21, 2013, 10:02:25 PM
Quote from: mageye on August 21, 2013, 09:27:35 PM
Looks like it's being LPF'd  :(

Yep, but it's nothing I'm doing. I've double-checked by looking at the 5D3 output directly on a scope. Same thing.
Title: Re: [Module] SMPTE experiment
Post by: g3gg0 on August 21, 2013, 10:06:59 PM
thanks a lot, this maybe helps finding the problem.
stay tuned
Title: Re: [Module] SMPTE experiment
Post by: g3gg0 on August 21, 2013, 10:13:06 PM
this (http://upload.g3gg0.de/pub_files/7c0dd9362718bb13f2e2cfc816da2ba2/smpte.mo) one any better?
Title: Re: [Module] SMPTE experiment
Post by: AnotherDave on August 21, 2013, 10:33:16 PM
Nope.  Still coming through garbled for me... just the same as before.
Title: Re: [Module] SMPTE experiment
Post by: g3gg0 on August 21, 2013, 11:02:03 PM
you tried toggling the inversion options in the menu?
Title: Re: [Module] SMPTE experiment
Post by: AnotherDave on August 21, 2013, 11:04:15 PM
yep.  doesn't make a difference.  looks just like the video I posted earlier...
Title: Re: [Module] SMPTE experiment
Post by: tob on August 21, 2013, 11:37:17 PM
The waveform looks more like square, with the latest module.

(http://i.imgur.com/z2TDcJx.png?1)

I recorded 4 files with the module posted for 1 hour ago. The files are around 13s each, 44100khz, mono, 32-Bit depth. With all settings VSYNC <-> ASIF offset = 40, output volume = 127.

smpte_test_OFF_OFF.wav   Invert output [OFF], Invert parity [OFF]
smpte_test_OFF_ON.wav   Invert output [OFF], Invert parity [ON]
smpte_test_ON_OFF.wav   Invert output [ON], Invert parity [OFF]
smpte_test_ON_ON.wav   Invert output [ON], Invert parity [ON]

https://dl.dropboxusercontent.com/u/34148361/test/smtpe_test.zip


Title: Re: [Module] SMPTE experiment
Post by: stevefal on August 22, 2013, 01:03:53 AM
Same for me - the waveform is much closer but still no lock
Title: Re: [Module] SMPTE experiment
Post by: stevefal on August 22, 2013, 01:20:33 AM
Maybe useful if you're not already using it:

http://github.com/x42/libltc
http://github.com/x42/ltc-tools
http://github.com/x42/libtimecode
Title: Re: [Module] SMPTE experiment
Post by: g3gg0 on August 22, 2013, 01:51:14 AM
once again (http://upload.g3gg0.de/pub_files/a5e4088513d261bf66e6fed97b9c2a33/smpte.mo)
Title: Re: [Module] SMPTE experiment
Post by: AnotherDave on August 22, 2013, 04:12:12 AM
Same deal for me.... TC is all over the place.  Just like in the video, no change when flipping through settings.
Title: Re: [Module] SMPTE experiment
Post by: stevefal on August 22, 2013, 08:01:31 AM
I haven't tried to decode the datastream visually, but I can see that there are issues with the first few bits after the sync word. The issues seem to vary, but here's one example. The highlighted area starts at bit 76. You can see that bit 79, which should be a 1, transitions at its midpoint, but at its endpoint it does not transition. It continues on to the next bit at the same level. It also has invalid transitions in the next few bits.

(http://i.imgur.com/po1aOd0.png)

Here's another with the same issue, and another mix-up in the next few bits:

(http://i.imgur.com/i0TX1kS.png)

Title: Re: [Module] SMPTE experiment
Post by: stevefal on August 22, 2013, 08:07:42 AM
The signal envelope also pulses on a 15 frame interval. I suppose it shouldn't affect decoding, but maybe it's a clue:

(http://i.imgur.com/qNsRFv8.png)
Title: Re: [Module] SMPTE experiment
Post by: g3gg0 on August 22, 2013, 08:39:37 AM
Aaah damn... i know what is wrong.
Will fix tonight.
Thanks
Title: Re: [Module] SMPTE experiment
Post by: stevefal on August 22, 2013, 08:51:58 AM
Btw, I don't think inverting output will make-or-break decoding. A reader should be able to read it either way.
Title: Re: [Module] SMPTE experiment
Post by: g3gg0 on August 22, 2013, 11:58:45 AM
background:
when switching to a more "rectangular" waveform, i had to increase the sampling rate from 8000 Hz to 44100 Hz.
but with 25 fps and 44,1 kHz the number of samples per LTC bit is 44100 / 25 / 160 is 11.025 which is causing a small bit offset.
some problems may come from this, but i hoped its influence isnt that high.

plus i didnt store the last phase for the next frame which shouldnt matter if the parity would be correct (not the case if inversion is activated)
if anything goes wrong with parity, the next frame will start without any transition.

another thing is the frame rate.
for testing please switch to 25 fps and disable all inversion settings in the menu.
set the volume so high, that it doesnt overdrive your audio input.
the best would be 80% of max volume iirc.
Title: Re: [Module] SMPTE experiment
Post by: AnotherDave on August 22, 2013, 01:54:50 PM
Are these instructions for yesterday's build, or are you putting together a new one?
Title: Re: [Module] SMPTE experiment
Post by: g3gg0 on August 22, 2013, 03:00:43 PM
were meant for the yesterday build.
just to make sure it runs under optimal condition.

(it is just hacked together in order to check if it is possible at all. so it is hardcoded for 25fps)
Title: Re: [Module] SMPTE experiment
Post by: AnotherDave on August 22, 2013, 03:09:26 PM
It works!....  sorta!

I switched it to 25fps, and turned everything to off and I started to get a recognizable signal on TC Toolbox!  It was slightly garbled - maybe 2-3 times a second it would display random numbers... but this is definitely getting somewhere.

What can I do to give ya more information?
Title: Re: [Module] SMPTE experiment
Post by: Dannington on August 22, 2013, 03:31:31 PM
I'll give this a go on Media Composer later on.

Will let you guys know.
Title: Re: [Module] SMPTE experiment
Post by: stevefal on August 22, 2013, 03:47:08 PM
To be sure, in order to run exactly 25fps, I needed to switch my 5D3 to PAL, correct?

I did that and also got a few recognized frames per second. I've set my TC reader to 0 frames of freewheel, so it shows only actual frames read.

But at 25fps I still see missing or early/late transitions after the sync word.
Title: Re: [Module] SMPTE experiment
Post by: mageye on August 22, 2013, 03:51:11 PM
For anyone that is interested there is a FREE application for OS X that can read SMPTE. I have been searching online for this for days now and I finally found a link that works.

http://mac.softpedia.com/dyn-postdownload.php?p=45721&t=4&i=1 (http://mac.softpedia.com/dyn-postdownload.php?p=45721&t=4&i=1)

Hope it helps people :)
Title: Re: [Module] SMPTE experiment
Post by: AnotherDave on August 22, 2013, 04:06:10 PM
I've been looking for an application that can read a .wav SMPTE track, and embed the TC metadata to the other/corresponding audio tracks from the recorder... but I am not having any luck.

I personally own a Tascam DR-680.  It's no Sound Devices 788T, but the DR-680 usually all that I need for sound.  The downside is that it doesn't have embedded TC so I was planning on using 1 of the 6 audio tracks as the TC from the 5D3... but how to embed that TC to the other (up to) 5 tracks is the real question...
Title: Re: [Module] SMPTE experiment
Post by: stevefal on August 22, 2013, 05:22:53 PM
Quote from: AnotherDave on August 22, 2013, 04:06:10 PM
.. but how to embed that TC to the other (up to) 5 tracks is the real question...

I don't know of an actual embedded timecode for audio files beyond a BWF timestamp or an LTC track. Doesn't the DR680 support 6-channel BWF and WAV?

Why would you want to add timecode to each of the tracks? Can't you drop the 6-channel file into your editor and use your new TC track to sync with video? Of course reading LTC with popular video editors is a problem by itself.

Here are some utilities that might help: http://www.studiodaily.com/2009/07/guide-to-broadcast-wave-file-software-utilities/
Title: Re: [Module] SMPTE experiment
Post by: AnotherDave on August 22, 2013, 06:05:37 PM
Quote from: stevefal on August 22, 2013, 05:22:53 PM
I don't know of an actual embedded timecode for audio files beyond a BWF timestamp or an LTC track. Doesn't the DR680 support 6-channel BWF and WAV?

Why would you want to add timecode to each of the tracks? Can't you drop the 6-channel file into your editor and use your new TC track to sync with video? Of course reading LTC with popular video editors is a problem by itself.

Here are some utilities that might help: http://www.studiodaily.com/2009/07/guide-to-broadcast-wave-file-software-utilities/

The 680 does support 6-channel BWF! 

I have been doing all of my .dng conversion in Resolve, and really dig the TC syncing features in there.  Do you have a workflow for syncing a 6 channel BWF with a video track in resolve by any chance? :-)
Title: Re: [Module] SMPTE experiment
Post by: mageye on August 22, 2013, 06:14:15 PM
OK Just thought that I would mention that I have managed to get the SMPTE Reader application (mentioned and linked above) to syncronise to a pre-generated SMPTE signal rendered into a WAV file playing from the Sounder Recorder Playback feature from ML.

I have NOT got it to sync with the generated SMPTE Output from the module YET but it's nice to know that once the signal is in the correct shape it is possible.
Title: Re: [Module] SMPTE experiment
Post by: stevefal on August 22, 2013, 06:31:21 PM
Quote from: AnotherDave on August 22, 2013, 06:05:37 PM
Do you have a workflow for syncing a 6 channel BWF with a video track in resolve by any chance? :-)

I haven't done it but supposedly 9.0.3 supports syncing LTC from a video clip's audio track to LTC to/from a discreet audio track. So I assume that if you stripe your video and 6-channel audio files with the same TC during shooting, you should be able to use Resolve's new feature.

If this effort leads to ML video files with embedded LTC (after conversion), plus the LTC audio output during shooting, I'll be very happy.
Title: Re: [Module] SMPTE experiment
Post by: AnotherDave on August 22, 2013, 07:23:39 PM
Quote from: stevefal on August 22, 2013, 06:31:21 PM
If this effort leads to ML video files with embedded LTC (after conversion), plus the LTC audio output during shooting, I'll be very happy.

I second that! :-)
Title: Re: [Module] SMPTE experiment
Post by: stevefal on August 22, 2013, 07:39:22 PM
Actually I'm fuzzy on generating LTC alongside the video - unclear how valuable that would be. In need to understand RAW/DNG/CinemaDNG + second system workflow better.
Title: Re: [Module] SMPTE experiment
Post by: AnotherDave on August 22, 2013, 08:03:27 PM
Ah!  Resolve has a setting to adjust TC from LTC... but it only works for audio that is embedded on video!

On a side note, the 680 records free run TC to BWF files...  shame it can't be synced!

g3ggo has been working to develop the new standard for raw_rec, *.mlv with the hopes to include TC into the metadata. 
Title: Re: [Module] SMPTE experiment
Post by: AnotherDave on August 22, 2013, 08:08:25 PM
Apparently this will do the job!

http://www.videotoolshed.com/product/64/wavetobwf/3 (http://www.videotoolshed.com/product/64/wavetobwf/3)
Title: Re: [Module] SMPTE experiment
Post by: g3gg0 on August 23, 2013, 01:49:20 AM
this is more like an experiment.
here (http://upload.g3gg0.de/pub_files/ec5a6d3747a00dbe68f3d535652d430d/smpte.mo) i assume that the video and audio hardware clock lines are definitely in sync.
this time i dont guess where the audio hardware is currently reading from, as it is too jumpy.

either this is the best solution, or it is the worst. not sure.
even if it is working fine from what you see, it is possible that it is not usable as clocks will drift and you lose frames somewhen etc

Title: Re: [Module] SMPTE experiment
Post by: AnotherDave on August 23, 2013, 02:24:06 AM
With the only the 'Invert Parity' turned on, it counts to 10 seconds, and reset to zero...

Numbers seem fairly jumpy on the frames.
Title: Re: [Module] SMPTE experiment
Post by: g3gg0 on August 24, 2013, 01:12:38 AM
okay i reworked the bit banging code a bit.
here is the result (http://upload.g3gg0.de/pub_files/d63552c7af8f59644b856370ef1c55c4/smpte.mo). possible that it doesnt work at all, possible that it works perfect :)
Title: Re: [Module] SMPTE experiment
Post by: stevefal on August 24, 2013, 02:43:05 AM
Still no lock for me. I ran it at 25fps, and I don't get one frame recognized. Also it doesn't sound exactly like time code. I'd have to look closer to see what's different.

If you could get it to generate TC from a specific start time, I could generate some matching timecode on my end, and then overlay the waveforms in an image so you can see the differences.
Title: Re: [Module] SMPTE experiment
Post by: g3gg0 on August 24, 2013, 09:39:17 AM
can you generate a waveform that starts to count from 00:00:00.000 with 25 fps inm color mode?
no user fields (date etc) if possible.

thanks
Title: Re: [Module] SMPTE experiment
Post by: g3gg0 on August 24, 2013, 10:44:32 AM
i disabled color frame flag here (http://upload.g3gg0.de/pub_files/7cebec90f8ad6ba2e38995c10ab6ad9a/smpte.mo). the code just outputs time and the parity bit to guarantee the same phase on all frames.
maybe it is better?
Title: Re: [Module] SMPTE experiment
Post by: stevefal on August 24, 2013, 10:27:36 PM
Here you go. This starts at 23:59:59:24 and rolls to 0 after the first frame: http://popspring.com/mldrop/SMPTE_TC_25FPS_0-10S.wav (http://popspring.com/mldrop/SMPTE_TC_25FPS_0-10S.wav)

Title: Re: [Module] SMPTE experiment
Post by: stevefal on August 24, 2013, 10:57:10 PM
Quote from: g3gg0 on August 24, 2013, 10:44:32 AM
i disabled color frame flag here (http://upload.g3gg0.de/pub_files/7cebec90f8ad6ba2e38995c10ab6ad9a/smpte.mo). the code just outputs time and the parity bit to guarantee the same phase on all frames.
maybe it is better?

This was the first that I've been able to read at all. One of my readers can pick up a frame every second or two, and the other has been able to pick up only one frame so far.
Title: Re: [Module] SMPTE experiment
Post by: g3gg0 on August 24, 2013, 11:05:04 PM
i didnt understand - this one is generating codes that can be read without errors, or is it the one that generates at least a few readable frames?
Title: Re: [Module] SMPTE experiment
Post by: stevefal on August 24, 2013, 11:36:00 PM
With the last module you posted, I could read a few frames, every few seconds. That module is the only one that I have been able to read at all. All previous modules you posted were not recognized as valid timecode by my reader.
Title: Re: [Module] SMPTE experiment
Post by: g3gg0 on August 25, 2013, 12:20:40 AM
this (http://upload.g3gg0.de/pub_files/e93f768860c180e1e4f7f828766ee61e/smpte.mo) ojne outputs only zeroes.
and this (http://upload.g3gg0.de/pub_files/df0c2c9cfb5495ebd58bce18ebf6a5d4/smpte.mo) the current time.

i changed the bit filling code a bit.
Title: Re: [Module] SMPTE experiment
Post by: stevefal on August 25, 2013, 03:36:25 AM
I'm reading that one solid. You got it.

I'll have to do some experiments to see if it's as robust wrt signal level compared to my generators.
Title: Re: [Module] SMPTE experiment
Post by: AnotherDave on August 25, 2013, 03:59:19 AM
You got it?! :-D

I can't try it out until tomorrow.
Title: Re: [Module] SMPTE experiment
Post by: AnotherDave on August 25, 2013, 04:51:45 AM
Ok, I lied!  I had ten minutes so I tried it out, and BAMMM!!!

It is totally there!

Issues
1. It shuts off once you start recording.
2. If you start shooting with it on, then try to turn it back on again after you've stopped... it locks up the camera.

It doesn't really need to run while you're recording though.
Title: Re: [Module] SMPTE experiment
Post by: g3gg0 on August 25, 2013, 12:13:35 PM
these are no issues, as it is not designed to work with any video recording function yet.
Title: Re: [Module] SMPTE experiment
Post by: mageye on August 25, 2013, 02:09:10 PM
First of all thanks g3gg0 for all your work. It is very much appreciated :).

I have tested this repeatedly and my results are not so promising. :(

I am testing on the 5DMKII
I am using the latest nightly build (31302bbc6461 16th Aug.) (also a844c5e3a60e build) and have even 'restored ML defaults' (amongst other things).

To test it I am using the software SMPTE Reader on the Mac (OS X 10.8.4). I know this software is capable of reading the SMPTE signal because I have managed to read the signal (and synchronise) from a pre-striped WAV file playing from the camera.

To create the 'striped' WAV I used the MAX4Live object found here: http://cycling74.com/toolbox/smpte/ (http://cycling74.com/toolbox/smpte/)

Interestingly when I tried today's provided smpte.mo file(s) ('current time' build) I got something the first time I tested it?

It did indeed pick up the current time and ran for a short time :D :-\. After that, changing back and forth between Live View and 'normal' mode I was only getting occasional flashes on the SMPTE Reader application :-\. Most of the time I am getting nothing :(.

I have tried turning off the camera in between tries and trying it with FPS override ON/OFF. I set the Canon Movie rec. size to 1920x1080@25 I have tried changing the FPS from 25FPS (just to try it). Also I have been trying different volume level settings and VSYNC too. It seems that the results are intermittent at the very best :-\.

I have certainly not had it running reliably yet :(. It's a shame because it seems as though it's so close to working now :(.

I would like to know what settings are best likely to be able to create the syncronisation? I think I have tried many things and am willing to test further ;).

NOTE: Whilst testing I have been checking to see if the setup is capable of sending/receiving SMPTE by using my striped test WAV played back from the ML Sound Recorder 'Playback selected file' and that works every time and really doesn't have any problem synchronising at almost any volume level.

I would really like to see this thing working and I have a feeling that its getting close now.

Thanks again :)
Title: Re: [Module] SMPTE experiment
Post by: g3gg0 on August 25, 2013, 03:16:00 PM
@mageye:
the only thing the module was for, was testing to get audio sync.
neither stability nor features were in focus.
i just wanted to output a signal that is readable....

@all:
i added support to raw_rec and smpte to ouptut 100 smpte frames when recording starts.
here (http://upload.g3gg0.de/pub_files/9398269c85b80fb72f94cda58102633c/smpte.zip)

it still outputs one frame, then a bit of silence, then frames again.
there is for sure a offset in buffers etc that will cause frame dropping and so on.
so its still an experiment.
Title: Re: [Module/5D3] SMPTE experiment, not usable
Post by: stevefal on August 25, 2013, 05:04:47 PM
Another possibility that may have already been discussed is an electronic slate.

Instead of marking the head of the audio clip with SMPTE, mark it with spoken marker ID# and an electronic clap. The audio would be stitched together from short samples and triggered by a button (at any time) and optionally on record start:

  "Mark one three two .... BLIP"

The BLIP is a tone that lasts one frame and is synced with a synthesized marker frame in the video, that contains the text e.g. "Mark #132". Not sure how that could be implemented - pre-made RAW blocks?

I suggest mark numbers because time codes are longer and therefore less convenient. When the mark counter is reset, the numbers will be super short.

The video marker could include, say, 10 frames of blue and one frame of red corresponding to the BLIP. N frames makes it easier to find them when shuttling.

The audio fragments could be file-based for easy localization.

If this is interesting I'll offer to contribute professionally recorded audio samples in English, and testing. I could also contribute RAW source material for video markers if that was appropriate.
Title: Re: [Module/5D3] SMPTE experiment, not usable
Post by: stevefal on August 25, 2013, 05:20:13 PM
To be clear, the idea of the slate system is that the camera would output the audio slate, and you would record it on a spare channel of your external recorder. In post you would then manually align audio to video using the markers, and then link or nest them as appropriate to keep them together. Of course it's not true sync, but it would be really useful as a poor man's tool.
Title: Re: [Module/5D3] SMPTE experiment, not usable
Post by: mageye on August 25, 2013, 05:29:09 PM
@stevefal

The RAW record already makes a bleep sound when you record. I have already tested this. So far I have been using a real clapper board but then I decided to test the viability of just using the bleep and an external recorder. I found that if you align the blip one frame right of the beginning of the DNG sequence it synchronises. At least it did in the few tests that I have done. I am not sure how consistent (or accurate) the timing is for the bleep but it I did manage to get a pretty tight sync.

For my initial tests I recorded the clapper and aligned to the bleep to see how much offset there was (with the clapper). As I said, I found it to be about a frame to the right of the start of the video recording.
Title: Re: [Module/5D3] SMPTE experiment, not usable
Post by: stevefal on August 25, 2013, 06:01:05 PM
Yep, so that part works. The auto-slate idea adds automatic clip identification in order to match audio-video content.
Title: Re: [Module/5D3] SMPTE experiment, not usable
Post by: mageye on August 25, 2013, 06:19:27 PM
I am all for anything that makes sound synchronisation automatic or 'more automatic'. So I am not against your suggestions. Remember also that in the conventions for the MLV format there should/will be support for sound. It looks to me like, if what is proposed in the outline of the format comes to fruition, then full sound and synchronisation will be supported (to a high degree of accuracy too). I have faith. I look forward. ;D
Title: Re: [Module/5D3] SMPTE experiment, not usable
Post by: AnotherDave on August 25, 2013, 06:27:31 PM
Why can't we just Jam Sync the current time to an audio recorder?  This doesn't need to output during recording at all.  It just needs to provide a way to sync with the camera's time before you record...

I'm (hopefully) picking up a used Tascam HD-P2 today to test this out.

We would only need to be able to lock the TOD from the camera to the free run TC of the recorder... And this should be doing this already.

Shouldn't it?
Title: Re: [Module/5D3] SMPTE experiment, not usable
Post by: g3gg0 on August 25, 2013, 06:52:56 PM
this thread is about SMPTE...

forgot to add: disable audio in canon menu.
Title: Re: [Module/5D3] SMPTE experiment, not usable
Post by: stevefal on August 25, 2013, 07:44:48 PM
I have had Canon audio disabled in all my attempts.
Title: Re: [Module/5D3] SMPTE experiment, not usable
Post by: stevefal on August 25, 2013, 07:52:47 PM
Quote from: g3gg0 on August 25, 2013, 06:52:56 PM
this thread is about SMPTE...

Side chat in http://www.magiclantern.fm/forum/index.php?topic=7886
Title: Re: [Module/5D3] SMPTE experiment, not usable
Post by: g3gg0 on August 25, 2013, 11:49:43 PM
and does it work with raw_rec?
Title: Re: [Module/5D3] SMPTE experiment, not usable
Post by: stevefal on August 26, 2013, 12:40:56 AM
Quote from: g3gg0 on August 25, 2013, 11:49:43 PM
and does it work with raw_rec?

Not for me. When I start recording, LTC output stops even though the display output continues. When I stop recording and go in to toggle LTC output, the camera UI freezes and I have to pull the battery.
Title: Re: [Module/5D3] SMPTE experiment, not usable
Post by: g3gg0 on August 26, 2013, 12:55:05 AM
you tried the version posted here?
Quote from: g3gg0 on August 25, 2013, 03:16:00 PM
@all:
i added support to raw_rec and smpte to ouptut 100 smpte frames when recording starts.
here (http://upload.g3gg0.de/pub_files/9398269c85b80fb72f94cda58102633c/smpte.zip)

it still outputs one frame, then a bit of silence, then frames again.
there is for sure a offset in buffers etc that will cause frame dropping and so on.
so its still an experiment.
Title: Re: [Module/5D3] SMPTE experiment, not usable
Post by: stevefal on August 26, 2013, 01:12:46 AM
Whoops no, I didn't try that. My readers take 2+ seconds to lock on this TC, but I'll try anyway...
Title: Re: [Module/5D3] SMPTE experiment, not usable
Post by: stevefal on August 26, 2013, 01:30:09 AM
Neither module loads - "Linking failed"

5D3, Aug 21 build.

[EDIT] I tried my raw_rec build from Aug 21 instead of the one you provided in the zip, and the modules loaded.

It is working marginally, but I don't know what to expect. I set the number of frames to maximum, and once I get lock, my reader counts up as:

00:00:03:07
00:00:04:07
00:00:05:07
...

I get this exact sequence every time.
Title: Re: [Module/5D3] SMPTE experiment, not usable
Post by: AnotherDave on August 26, 2013, 11:23:54 PM
Finally got my HD-P2 to pair with my DR-680 - the P2 can jam sync and send TC to the 680!

Haven't been able to get a signal to work from the module yet though.  Seems to be a bit of an issue using the headphone jack...
Title: Re: [Module/5D3] SMPTE experiment, not usable
Post by: AnotherDave on August 27, 2013, 12:35:04 AM
Ok so there are a few weird issues I'm getting in relation to the headphone jack.

1. If it is plugged in on start-up, the module doesn't produce any sound.
2. If the jack is plugged in prior to starting the module, it will send it thru the speaker still.


I know this isn't a priority since this is all still experimental, just thought I'd mention...
Title: Re: [Module/5D3] SMPTE experiment, not usable
Post by: g3gg0 on August 27, 2013, 09:35:39 AM
i tried this module:
http://upload.g3gg0.de/pub_files/f31d34a7b7f7a7498e52d3eb4ca5c00c/raw_rec_mlv.zip
(it contains the latest 5D3 autoexec.bin and symbol file. 2 months ago we added a new symbol to 5D3 binary)

plugged in, started camera, went into audio menu, enabled SMPTE and pressed Q.
there is selected Test and i got a clean sound.
same when starting raw recording.

in both scenarios the module wrote 101 audio frames.
make sure you use a 25 fps video mode, but others could work too.


it just came into my mind that i probably have the fps counter wrong.
so the devices may not synchronize correctly
Title: Re: [Module/5D3] SMPTE experiment, not usable
Post by: AnotherDave on August 27, 2013, 08:28:44 PM
Well... I'm trying to get a sync with my "new" (used) Tascam HD-P2, and it isn't giving me a useable signal now...

Before, (using TC Toolbox) I was getting a readout that was TOD based free run... but now I get counting from 1 to 10 before the test shuts off.  Also, the frames are always reading :39??

so maybe I have something set wrong?  I'm set to 25fps, canon audio off...
Title: Re: [Module/5D3] SMPTE experiment, not usable
Post by: g3gg0 on August 27, 2013, 11:48:40 PM
this (http://upload.g3gg0.de/pub_files/6d574ff0bffe538dcd6f78d497a0d296/raw_rec_mlv.zip) one has the bug i said fixed
Title: Re: [Module/5D3] SMPTE experiment, not usable
Post by: AnotherDave on August 28, 2013, 12:53:24 AM
With this one, I'm not getting a reading from either my TC Toolbox on my iPad or the HD-P2...?
Title: Re: [Module/5D3] SMPTE experiment, not usable
Post by: g3gg0 on August 28, 2013, 01:23:45 AM
sigh...
Title: Re: [Module/5D3] SMPTE experiment, not usable
Post by: stevefal on August 28, 2013, 01:36:42 AM
@g3gg0: I'm not sure if any of your recent responses were directed to me. My latest results are as previously posted. Tell me if you want me to try anything else.
Title: Re: [Module/5D3] SMPTE experiment, not usable
Post by: stevefal on August 28, 2013, 01:39:28 AM
Quote from: AnotherDave on August 27, 2013, 08:28:44 PM
Before, (using TC Toolbox) I was getting a readout that was TOD based free run... but now I get counting from 1 to 10 before the test shuts off.  Also, the frames are always reading :39??

This sounds similar to my results with the rawrec-integrated experiment, except all mine read :07.
Title: Re: [Module/5D3] SMPTE experiment, not usable
Post by: AnotherDave on August 28, 2013, 04:49:30 AM
Quote from: g3gg0 on August 28, 2013, 01:23:45 AM
sigh...

Don't give up!  It'll get there...
Title: Re: [Module/5D3] SMPTE experiment, not usable
Post by: AnotherDave on September 06, 2013, 05:12:17 AM
So I guess this is just dead, eh? :-/
Title: Re: [Module/5D3] SMPTE experiment, not usable
Post by: g3gg0 on September 06, 2013, 09:40:39 AM
its hard to debug if i have to upload it, wait some hours and check the response in forum that says "nope".
it would help to have a smpte decoding device.
Title: Re: [Module/5D3] SMPTE experiment, not usable
Post by: 3pointedit on September 06, 2013, 01:46:16 PM
Freeware tc reader via audio input on PC?
http://www.al-ga.jp/PCTimecode_sc_en.html

http://www.youtube.com/watch?v=AQKZm3ypmvU&sns=em

Title: Re: [Module/5D3] SMPTE experiment, not usable
Post by: AnotherDave on September 06, 2013, 07:50:35 PM
Makes me wish I didn't give my nephew my old iPod touch.  Any iOS or Android device can be used as a TC reader.  Do you have access to anything like that?
Title: Re: [Module/5D3] SMPTE experiment, not usable
Post by: g3gg0 on September 07, 2013, 03:11:25 PM
thanks, this tool is working fine.
didnt have to change *anything* to my module to make it work.

i just changed some things back, so it is now showing the RTC time again.

uploaded a video:
Title: Re: [Module/5D3] SMPTE experiment, not usable
Post by: 3pointedit on September 08, 2013, 02:16:01 AM
Omg so we could jam tc to an external audio recorder?! ;D where do you derive first value? Can we jam a free run sync tc value in there somewhere? To sync multiple cameras, also  is this available for h264 via audio channel?
Title: Re: [Module/5D3] SMPTE experiment, not usable
Post by: stevefal on September 09, 2013, 06:18:36 AM
Quote from: g3gg0 on September 07, 2013, 03:11:25 PM
i just changed some things back, so it is now showing the RTC time again.

That's great. Let me know if I can help.
Title: Re: [Module/5D3] SMPTE experiment, not usable
Post by: oddname on September 10, 2013, 03:49:12 PM
As a newbie in some areas of filmmaking, what does one use TC for?
Is it to sync audio and video?
Title: Re: [Module/5D3] SMPTE experiment, not usable
Post by: Dannington on September 10, 2013, 10:16:42 PM
What is TC for?

If you use pro audio gear, or even just a simple external recorder, it's a massive time saver to have a master timecode clock.

For example - although ML has greatly improved the existing audio capabilities of canon cameras, it's still not that great.  A step up is to use an external audio recorder - an ok one will give you decent mixing control, xlr inputs with phantom power etc meaning you can use boom mics, radio mics etc.  You can also have huge multi channel setups where you might have up to 16 radio mics plugged in to a hard disk recorder.  This is all very good but without a means of synchronising this audio with the video it all gets very time consuming when it comes to the edit.  You might also have several cameras which all need to use the same timecode clock but that's another story.

Timecode can be encoded into an audio-compatible track and recorded on any device which records audio.  A pro camera usually has a socket marked LTC out and whichever timecode the camera is using, be it a preset timecode or 'time-of-day' timecode is generated and 'played' through this device.  You plug this into your audio recorder on a spare channel and then you've got a rock solid frame accurate sync track for use in editing.

I use avid and if theres an LTC track on any of my audio feeds I can just click 'read audio timecode' and auxiliary timecode tracking info is made available.  Meaning if I jump to 13:21:11:03 on the video track, I can jump to the same place in the audio and instead of using 2 ropey audio tracks I can choose from 16 radio mics, boom mics and whatever else they might have plugged in.

This saves time because otherwise you have to line up the audio to the video by ear - easier if you shot using clapper boards but still pretty time consuming.  I shot something a few months ago using a Roland recorder stuck on the top of my 5Diii.  I experimented with an iphone app which produced TC audio through the iphone's speaker (I waved it in front of my boom mic and the canon's built in mic whenever i started recording).  It was a bit rubbish and I got bored of doing it.  The following week I spent a good day synching up my audio with my video before even starting my edit.  Something else i noticed is the camera's internal clock wavers quite a bit throughout the day.  I was recording audio in hour or two chunks but recording video in 1 to 5 minute chunks and the offset between the audio and video wavered by up to a 2 seconds over an hour.

So, this particular implementation of timecode would involve you plugging a line from the headphone jack of the camera into a spare channel of your audio recorder and enjoying painless editing.

Anyway - TC is really handy depending on what you're shooting.
Title: Re: [Module/5D3] SMPTE experiment, not usable
Post by: Midphase on September 11, 2013, 12:08:31 AM
Or you can use Pluraleyes or Premiere Pro CC/   :P
Title: Re: [Module/5D3] SMPTE experiment, not usable
Post by: AnotherDave on September 17, 2013, 04:08:22 AM
I've been out of the loop for a little while.

It's working?  Is there a new module, or did I have something set wrong?

Will there be a version that outputs 24p smpte?

Thanks!
Title: Re: [Module/5D3] SMPTE experiment, not usable
Post by: 3pointedit on September 17, 2013, 05:24:21 AM
Midphase , I'm not sure how Pluraleyes would go with RAW footage that has no scratch sound to sync up ;) The point of TC is to provide another point of reference for both audio and video sources.
Title: Re: [Module/5D3] SMPTE experiment, not usable
Post by: Midphase on September 17, 2013, 09:32:49 AM
That's my point....I think it'd be best to see if we can get built-in audio to work again.

Title: Re: [Module/5D3] SMPTE experiment, not usable
Post by: stevefal on September 20, 2013, 08:48:56 PM
Also interested in 24fps. Is the source code available?
Title: Re: [Module/5D3] SMPTE experiment, not usable
Post by: g3gg0 on September 21, 2013, 04:19:56 PM
it is already in repository, see:
https://bitbucket.org/g3gg0/magic-lantern/src/tip/modules/smpte?at=unified

24 fps could work also, just after some seconds there may be a glitch, as the rate is not decimal
Title: Re: [Module/5D3] SMPTE experiment, not usable
Post by: stevefal on September 21, 2013, 04:46:17 PM
Thanks.

Not sure I understand. Are you saying that 25fps works without glitches, but 24 can't? Or are you referring to 23.976?

Is your vision that this module would sync with time written to MLV frames, leading to timecode in converted cinemaDNG? Are there  concerns with it working?
Title: Re: [Module/5D3] SMPTE experiment, not usable
Post by: stevefal on September 21, 2013, 04:50:28 PM
Is it correct that the smpte module requires the raw_rec module from the same repo?
Title: Re: [Module/5D3] SMPTE experiment, not usable
Post by: g3gg0 on September 21, 2013, 05:12:24 PM
23.976 is not integer, so it most likely wont work with continuous output.
if you only output 10 audio frames to jamsync, it should do the job.

yes, you need the mlv version of raw_rec, how else would you sync the raw video to audio.

this module outputs that timecode, that is being written into the MLV container file.
so you can exactly sync audio frames to video frames if you recorded the smpte output along with your scene audio.
(on the 3rd channel)
Title: Re: [Module/5D3] SMPTE experiment, not usable
Post by: stevefal on September 21, 2013, 05:47:11 PM
Quoteyes, you need the mlv version of raw_rec, how else would you sync the raw video to audio.

I wasn't sure if that integration was done, or if there was just an experimental non-mlv raw_rec that you had modified just to get vsync working.

I get it. Thanks again.
Title: Re: [Module/5D3] SMPTE experiment, not usable
Post by: AnotherDave on October 03, 2013, 12:01:59 AM
Been out-of-the-loop.... where is the latest and greatest version to try out?

How are things working?
Title: Re: [Module/5D3] SMPTE experiment, not usable
Post by: g3gg0 on October 03, 2013, 01:25:07 AM
updated the main post with the latest build.
didnt change anything for a while.

the build should work as expected and output the SMPTE time.
anything missing?
Title: Re: [Module/5D3] SMPTE experiment, not usable
Post by: stevefal on October 03, 2013, 02:58:34 AM
I assume 23.976 fps still missing...
Title: Re: [Module/5D3] SMPTE experiment, not usable
Post by: g3gg0 on October 03, 2013, 10:12:02 AM
Uh no it is implemented. But as said, continuous output might cause trouble.
this was said to be not necessary. A few seconds are enough.

i cant test it because i dont have the chance to test.
Title: Re: [Module/5D3] SMPTE experiment, not usable
Post by: stevefal on October 03, 2013, 06:04:18 PM
I think it's a pretty big compromise. If a track is not fully striped, it means you're relying on two clocks being perfectly timed in order for things to stay in sync over a long take. One should be able to sync two clips from the middle. You should also be able to cut a clip, process it externally, e.g. noise reduction, and re-sync it without having to work with the whole take. Also it's unclear how every app will work when the audio LTC doesn't match the framerate that you're syncing to. It may not work at all in some NLEs/graders/apps. Continuous LTC is standard.

[EDIT] I realize this is billed as 'not usable'. I just want to help make sure normal LTC use is understood.
Title: Re: [Module/5D3] SMPTE experiment, not usable
Post by: AnotherDave on October 03, 2013, 06:16:03 PM
Where is the latest version of mlv_rec.mo to test?  Any ideas?  Looking all over for it... :-/
Title: Re: [Module/5D3] SMPTE experiment, not usable
Post by: g3gg0 on October 03, 2013, 06:49:21 PM
ok in 23.976 fps mode, you might see one frame offset after a few thousand frames.
will this hurt?

iirc in this thread it was said free run mode is just fine.
i thought a few seconds LTC audio *is* free run mode, am i wrong?
Title: Re: [Module/5D3] SMPTE experiment, not usable
Post by: g3gg0 on October 03, 2013, 06:56:34 PM
i am using 44.1kHz sampling rate.
with 23.976 fps, the buffer for one LTC frame should be 1840.3393 samples.
but i am using 1840, so we are 0.3393 samples per frame too short.

after 5422 frames (226 seconds) the audio is one frame ahead and exactly one frame out of sync.

is that a problem?
Title: Re: [Module/5D3] SMPTE experiment, not usable
Post by: AnotherDave on October 03, 2013, 07:13:43 PM
48khz is usually the standard we record in on our external recorders.

Will it be 1 frame off for every 5422 seconds?  If so, that could be a problem.

If you can point me in the direction of the latest compiled build for this, I'd be happy to do some testing over the weekend.
Title: Re: [Module/5D3] SMPTE experiment, not usable
Post by: g3gg0 on October 03, 2013, 07:24:46 PM
i wrote 226 seconds / 5422 frames.
so you continuously record raw video clips with about 4 minutes length where you need perfect sync?
thats a problem then.

i didnt change anything to smpte since the last build i posted.

if the generated audio has 44.1kHz or 48kHz doesnt matter as you have an analog audio cable.
Title: Re: [Module/5D3] SMPTE experiment, not usable
Post by: stevefal on October 03, 2013, 09:51:04 PM
This relates to the TC going into the MLV video. Is it dropframe? Is 24fps rawrec video 24fps or 23.967?

http://www.youtube.com/watch?v=ykjyNeuQROU
Title: Re: [Module/5D3] SMPTE experiment, not usable
Post by: g3gg0 on October 03, 2013, 10:22:13 PM
ah thanks for the video.
forgot to say that i dont handle drop frames either.
will watch the video and maybe i can add that feature.

i just dont know how to verify that it works
Title: Re: [Module/5D3] SMPTE experiment, not usable
Post by: AnotherDave on October 03, 2013, 10:47:06 PM
Could that be the source of the sync issue?  Since it is consistent?

Also, I am having a super hard time location the latest compile and latest mlv_rec.mo...  It is starting to make me feel stupid.  :-/

Title: Re: [Module/5D3] SMPTE experiment, not usable
Post by: g3gg0 on October 03, 2013, 10:57:05 PM
Quote from: AnotherDave on October 03, 2013, 10:47:06 PM
Could that be the source of the sync issue?  Since it is consistent?

which sync issue do you mean?
Title: Re: [Module/5D3] SMPTE experiment, not usable
Post by: stevefal on October 03, 2013, 11:05:00 PM
Quotei just dont know how to verify that it works

We could shoot a TC generator as reference, and then analyze the video and audio/TC clips to see if nothing slips during a long run.

Important to remember that timecode counts time, not frames. Subtracting starttime from endtime should give actual duration when played at correct speed.
Title: Re: [Module/5D3] SMPTE experiment, not usable
Post by: g3gg0 on October 04, 2013, 12:04:09 AM
Quote from: AnotherDave on October 03, 2013, 10:47:06 PM
Also, I am having a super hard time location the latest compile and latest mlv_rec.mo...  It is starting to make me feel stupid.  :-/

see main post in mlv thread.
Title: Re: [Module/5D3] SMPTE experiment, not usable
Post by: AnotherDave on October 04, 2013, 05:53:28 AM
Quote from: g3gg0 on October 03, 2013, 10:57:05 PM
which sync issue do you mean?

You said it is off by 1 frame every 226 seconds, and that pattern continues every 226 frames...

That sounds like a drop frame vs. non-drop frame issue...   Drop frame drops frames every so many seconds to account for a sync issue that was discovered when color tv first started broadcasting...  or something like that.

Dave
Title: Re: [Module/5D3] SMPTE experiment, not usable
Post by: g3gg0 on October 04, 2013, 12:24:34 PM
no, this is the reason:

Quote from: g3gg0 on October 03, 2013, 06:56:34 PM
i am using 44.1kHz sampling rate.
with 23.976 fps, the buffer for one LTC frame should be 1840.3393 samples.
but i am using 1840, so we are 0.3393 samples per frame too short.

after 5422 frames (226 seconds) the audio is one frame ahead and exactly one frame out of sync.

is that a problem?
Title: Re: [Module/5D3] SMPTE experiment, not usable
Post by: stevefal on October 04, 2013, 03:03:12 PM
Maybe a silly idea but could it occasionally alternate to a buffer that is 1841 samples?
Title: Re: [Module/5D3] SMPTE experiment, not usable
Post by: g3gg0 on October 04, 2013, 04:40:42 PM
i already implemented the correction routine yesterday, just didnt test it.


        uint32_t correction_needed = (smpte_out_calls * smpte_out_buffer_remainder) / smpte_current_fpsx1000;
       
        if(correction_needed > smpte_out_corrected)
        {
            trace_write(trace_ctx, "smpte_asif_out_cbr: applying length correction #%d", correction_needed);
            corr = 1;
            smpte_out_corrected++;
        }

        SetNextASIFDACBuffer(smpte_out_buffers[smpte_out_buffer], smpte_out_buffer_size + corr);

Title: Re: [Module/5D3] SMPTE experiment, not usable
Post by: applewide on May 11, 2014, 04:50:13 PM
hi

can somebody give smpte module for 1.2.3 canon the night built please, appreciate you guys very much to take a look
Title: Re: [Module/5D3] SMPTE experiment, not usable
Post by: dpjpandone on August 16, 2014, 06:09:05 AM
I wanted to try this, but I get the following error when I restart the camera with this module loaded:

raw_rec_cbr_stopping defined twice  (from mlv snd and smpte)
also same message for _skip_frame, _cbr_stopping, _mlv_block

and undefined symbol 'module card drive'

failed to link modules.

I know it says "5D3" in the title.... and I tried it on 7D anyways......

maybe we can work on some of this timecode stuff this fall when u have time, I am still REALLY interested in this, I want to build an arduino-based smart slate that could use a canon DSLR as master and vice-versa!
Title: Re: [Module/5D3] SMPTE experiment, not usable
Post by: mario1000 on March 20, 2015, 02:45:51 PM
Dear g3gg0

I wanted to give your experimental SMPTE module on a 5D3.113 (latest nightly build) a try based on this video:

.

After I copied the module from your first post into the module folder and switched the camera back on all I get is a lot of weird error messsages and no module was loaded. After removing the module everthing worked fine again. Does a new version of your module exists working together with the latest nightly builds?