Gints,

Thanks for your comments. I don't think there is need for me to further tests, and post pictures here. I agree with your observations of the phenomena in both scene versions - the problem is that in order to see the nanoFlash format virtues, one needs to zoom into the pictures (or view them on a really large display). The excessive gran, on the other hand, can be seen without magnification, and on even a computer monitor. What's worse, in case of moving video it's shimmering, thus being even more annoying - and that's at just 100 Mbps! At 180 Mbps l-GoP, it's even worse.

Okay, but I was able to easily get the nano picture to look as smooth as the native EX-1 picture by simply adding a very light blur in post. Also, in post you can apply a matte to "de-noise" only those parts of the image you feel need correction. The EX1 smooths everything.

Peter, almost everything is possible in post...However, that's not the point of this thread.

:)

Buried within my clips, I have just come across something I didn't even intentionally record, but this raises my doubts again:(

In another thread on this forum (http://www.dvinfo.net/forum/convergent-design-nanoflash/137284-real-codec-torture-test-35mbps-vs-100mbps.html), it has been stressed how great the 100 Mbps Long-GoP is with motion, when compared to native EX1. I don't know how Jim Arthurs' samples were prepared, but I'm posting comparison of a single frame with a lot of motion blur. Please don't pay attention to the content - I know it's rubbish; I didn't shoot it carefully - just randomly moving the camera between two proper shots. Also, these are enlarged crops again. Nevertheless, it's the difference between native EX1 (left) and nanoFlash at 100 Mbps Long-GoP (right) that matters.

The nano clip is so pixelated it almost looks like falling apart!

Please comment.

I'm starting to think there is something wrong with your nano! You should probably send to it CD for them to fix it.

I'm starting to think there is something wrong with your nano! You should probably send to it CD for them to fix it.

Several posts above, Dan stated:

"I currently see no reason to suspect that your nanoFlash is malfunctioning."

I really don't know what to think now!

Piotr,

If you want to compare pics from the SxS with LGOPs from the Nano, you must compare an "I" frame from both.

If you are comparing an "I" frame from the SxS with a "B" or "P" frame of the Nano, the test is not fair.

This may be the reason why you find no problems with the Intraframe: All are "I" frames.

I really don't see possible that the Nano introduces any noise over the HD/SD-SDI.

Rafael

Piotr,

If you want to compare pics from the SxS with LGOPs from the Nano, you must compare an "I" frame from both.

If you are comparing an "I" frame from the SxS with a "B" or "P" frame of the Nano, the test is not fair.

This may be the reason why you find no problems with the Intraframe: All are "I" frames.

I really don't see possible that the Nano introduces any noise over the HD/SD-SDI.

Rafael

A very good point, Rafael - thanks!

At last, some technical interpretation... I'll try and analyse my comparisons so far, keeping in mind what you said.

Nevertheless, what matters is the video on the big screen, right? And watching it, you don't analyze whether the current frame is an I, B, or P frame - what counts is the perceived quality. And that is poor - the shimmering noise is simply more visible in the nano clips :(

Thanks anyway.
Piotr

Dear Piotr,

In post 103, on the left side of the image are what appears to be a vertical wall, made out of red, rough wood. At least the texture looks rough.

What does it look like in real life?

Is the wood rough?

Does the 35 Mbps image represent reality (smooth wood with little detail) or does the 100 Mbps image represent reality (rough wood with lots of detail).

How did you create this image?

Was the camera on a stable tripod?

Was someone or the wind shaking the tree?

Or was someone shaking the camera?

What were the camera details? Frame Rate, Shutter, Aperature, gain, picture profile?

Specifically, what is your F Stop? With a 1/2" sensor it should not be greater than F8.

In previous examples, you did not always show the exact same frame. Are these the same frame?

If you want to test if the nanoFlash is working or not, I suggest you set it to 35 Mbps, Long-GOP, 1920 x 1080 mode, and compare the exact same frames. But, as Rafael pointed out, one may be a B or P frame and one may be an I-Frame making it hard.

I know of no way to ensure that the nanoFlash and EX1, on the same frame, will both be on an I-Frame.

If you want to show the effect of "smoothing" due to a low frame rate, record a properly exposed image, with lots of details at 220 Mbps versus 100 Mbps, both using I-Frame Only.

The Codec used in the nanoFlash, as you are probably well aware, is the one used in the Sony PDW-F800 camera. And, all of the compression work is done in this Sony Codec. It is highly unlikely that the Sony codec is failing you.

Just to be clear, you may, of course, send us your nanoFlash and we will be happy to check it out for you. But, we have never had a Sony Codec module fail, or even be suspect, as far as I know.

I really don't know what to think now!

Dan would know better than me.

By the way, are you shooting straight with the EX-1, or are you using a 35 mm adapter? Because if the latter, the ground glass of the adapter may be causing similar issues.

A very good point, Rafael - thanks!

At last, some technical interpretation... I'll try and analyse my comparisons so far, keeping in mind what you said.

Nevertheless, what matters is the video on the big screen, right? And watching it, you don't analyze whether the current frame is an I, B, or P frame - what counts is the perceived quality. And that is poor - the shimmering noise is simply more visible in the nano clips :(

Thanks anyway.
Piotr
I agree with you that what it counts is the video in the big scree, but if we compare stills we must to take in to account the issue of the "I" frames.
Piotr, I really appreciate what you are doing to try to put some light on this matter.
Tomorrow I will try to make few test recording in the SxS, Nano and in Prores with the ioHD.
The suggestion of Dan about recording 35Mbps in the Nano is also to consider.
rafael

Dan would know better than me.

By the way, are you shooting straight with the EX-1, or are you using a 35 mm adapter? Because if the latter, the ground glass of the adapter may be causing similar issues.

No Adam - I'm not using the adapter in these tests. But thanks - a good point.

I've been making some tests that may be not the most scientistic, but I thing they point what is going on.
I have used NeatVideo.
The advantage of NeatVideo is that it works independently in the Luma and in the Chroma channels.
This allow to see what kind of noise prevails in the picture.
The pictures from the Nano (I used the Piotrs pics of the house), shows much more Chroma noise than the SxS picture.
That is not to surprise because the Nano pictures have double Chroma info than the SxS pictures.
About the noise in the Luma chanel, I see a bit more of noise in the Nano picture too, but the SxS picture is much more blurry.
For the one that have no NeatVideo, I propose a simple test: Drop any Color Correction filter and bring the Chroma all the way down, then compare the pictures.
As you can see, the SxS recording gets rid of a lot of the noise, but smudge the picture absolutely.
rafael
PS: since I bought my EX-1 I de-noise everything. Before I used VideoPurifier, now NeatVideo.

Dear Piotr,

In post 103, on the left side of the image are what appears to be a vertical wall, made out of red, rough wood. At least the texture looks rough.

What does it look like in real life?

Is the wood rough?

Does the 35 Mbps image represent reality (smooth wood with little detail) or does the 100 Mbps image represent reality (rough wood with lots of detail).

Dear Dan,

The wood is rather smooth. Of course there is some texture on it, but certainly not containing any other color than various shades of brown - while the grain I'm complaining about consists of dots in all possible colors.



How did you create this image?

Was the camera on a stable tripod?

Was someone or the wind shaking the tree?

Or was someone shaking the camera?

This particular frame comes from a hand-held shoot (I wanted to check camera whip pans and shake), so it's quite different to the previous ones which were shot from the tripod.

What were the camera details? Frame Rate, Shutter, Aperture, gain, picture profile?

Specifically, what is your F Stop? With a 1/2" sensor it should not be greater than F8.

The settings were: 1080/25p, 1/50th, aperture never outside the 2.8 - 5.6 range

In previous examples, you did not always show the exact same frame. Are these the same frame?

As you know, it's almost impossible to align an EX1 native clip with its nanoFlash counterpart on two Vegas tracks - even if you switch Quantize to Frames Off.



If you want to test if the nanoFlash is working or not, I suggest you set it to 35 Mbps, Long-GOP, 1920 x 1080 mode, and compare the exact same frames. But, as Rafael pointed out, one may be a B or P frame and one may be an I-Frame making it hard.

I know of no way to ensure that the nanoFlash and EX1, on the same frame, will both be on an I-Frame.

Yes - with nanoFlash bitrates of 35 or even 50 Mbps, the noise problem is not existing.

If you want to show the effect of "smoothing" due to a low frame rate, record a properly exposed image, with lots of details at 220 Mbps versus 100 Mbps, both using I-Frame Only.

Dan, in real life, in most images you will find both bright and dark areas (otherwise those images would represent a very narrow dynamic range). The dark areas tend to be noisy in the EX-series cameras, and this noise is augmented by the nanoFlash at higher bitrates.

The Codec used in the nanoFlash, as you are probably well aware, is the one used in the Sony PDW-F800 camera. And, all of the compression work is done in this Sony Codec. It is highly unlikely that the Sony codec is failing you.

Dan, I'm not saying it has failed on me - I'm asking why everybody is raving on how much cleaner the nanoFlash images are when they aren't. That is to say, they tent to amplify the source shortcomings (the noise) in a very nasty fashion. My problem is that while i often need to zoom into a nano frame in order to see its virtues (like less mosquito noise, and better color resolution - I created a separate thread on that, too), the shimmering noise I can see in the normal scale image, on all less-than-bright surfaces of more or less uniform color.

Just to be clear, you may, of course, send us your nanoFlash and we will be happy to check it out for you. But, we have never had a Sony Codec module fail, or even be suspect, as far as I know.

Thanks for this option; let me treat it as the last resort. For now, I'll appreciate technical explanations (with examples) much more. I hope they would prove your previous point that nothing is wrong with my nanoFlash...

Cheers

Piotr

I've been making some tests that may be not the most scientistic, but I thing they point what is going on.
I have used NeatVideo.
The advantage of NeatVideo is that it works independently in the Luma and in the Chroma channels.
This allow to see what kind of noise prevails in the picture.
The pictures from the Nano (I used the Piotrs pics of the house), shows much more Chroma noise than the SxS picture.
That is not to surprise because the Nano pictures have double Chroma info than the SxS pictures.
About the noise in the Luma chanel, I see a bit more of noise in the Nano picture too, but the SxS picture is much more blurry.
For the one that have no NeatVideo, I propose a simple test: Drop any Color Correction filter and bring the Chroma all the way down, then compare the pictures.
As you can see, the SxS recording gets rid of a lot of the noise, but smudge the picture absolutely.
rafael
PS: since I bought my EX-1 I de-noise everything. Before I used VideoPurifier, now NeatVideo.

Dear Rafael,

If you could try similar tests with your EX1/nanoFlash to confirm mine are working to specs, I'd be very grateful indeed. Just a single test of the native EX1 vs. nanoFlash in 180 Mbps L-GoP will suffice.

Then, with regained confidence in my equipment, I'll probably start using some de-noiser as well (and since I work with Vegas Pro, it'll most probably be NeatVideo).

Thanks again,

Piotr

Dear Piotr,

Thank you very much for the extra information.

I helps us understand.

If I may add my .02, it seems that the real issue is the difference between how clean Long-GOP vs I-Frame recording is.

If the nano is just recording noise as extra detail, then you would think the I-Frame recording would do the same. But that doesn't seem to be the case, if I've understood this thread correctly (which is not an easy thing, LOL).

IIUC, at the same and higher data rates, the I-Frame recording is significantly cleaner than the Long-GOP. This doesn't sound like a defect in the nano, but rather a subtlety w/ how the Sony chip and MPEG-2 encode Long-GOP vs. I-Frame. And it seems possible that this difference may have gone unnoticed or unmentioned until now.

I would humbly suggest doing a test of Long-GOP vs I-Frame at various data rates of a scene that includes shadows. If there is no "noise" difference between the two recording methods, than it seems that Piotr's nano is defective. But if the test shows extra shadow "noise" in the Long-GOP recording, then Piotr's nano is behaving normally and this behavior is a function of how the Sony chip encodes.

In the best case, Sony can shed some light on this. In the worse case, it's information users can keep in mind when balancing data rate, quality and scene composition.

Hope that makes sense :).

I would humbly suggest doing a test of Long-GOP vs I-Frame at various data rates of a scene that includes shadows. If there is no "noise: difference between the two recording methods, than it seems that Piotr's nano is defective. But if the test shows extra shadow "noise" in the Long-GOP recording, then Piotr's nano is behaving normally and this behavior is a function of how the Sony chip encodes.

In the best case, Sony can shed some light on this. In the worse case, it's information users can keep in mind when balancing data rate, quality and scene composition.

Hope that makes sense :).

This makes perfect sense, Peter - and it's this type of output result I've been counting on when creating this thread (and NOT ranting, or bashing anybody).

:)

Piotr

Dear Piotr,

Thank you very much for the extra information.

I helps us understand.

Dear Dan,

I'm glad I made myself more clear now. I'd like to stress it again that my intention in this thread is only to better understand things, and get confidence my hardware is not malfunctioning (not necessarily the nanoFlash, but also my EX1 and the HD-SDI ports and cable). Therefore, I'd really appreciate some technical follow-up to my points from the Convergent Design engineers, which would help achieve the above goals. I'm sure other EX/nanoFlash users will benefit, as well.

At the moment, just two additional qusetions, if you will:

1. Here is what Mike wrote in another thread:

Hi Per Johan-
I have been absolutely amazed at the quality from this Sony CODEC. This is their 7th generation part and they truly did a stunning job designing this part. It has very low-power (around 3W in 4:2:2 mode), small size and superb video quality. It's the same CODEC as inside the PDW-700 camera, we just cranked up the bit-rate from 50 to 100 Mbps.

Now, is there a possibility that something could have gone wrong in this "cranking up" of the Sony codec chip?

2. On yet another subject:

We have both agreed it's very difficult to synchronize the picture from EX1 and the nano perfectly when on separate tracks, one above the other, in an NLE. I do a lot of multicamera projects, and when only using material from several EX cameras, I'm able to synchronize them with frame accuracy using spikes in the audio waveforms. This method doesn't work with an EX1 and nanoFlash files, recorded simultaneously - could you please explain why, in technical terms?

Thanks and Kind Regards

Piotr

Dear Dan,
.......
2. On yet another subject:

We have both agreed it's very difficult to synchronize the picture from EX1 and the nano perfectly when on separate tracks, one above the other, in an NLE. I do a lot of multicamera projects, and when only using material from several EX cameras, I'm able to synchronize them with frame accuracy using spikes in the audio waveforms. This method doesn't work with an EX1 and nanoFlash files, recorded simultaneously - could you please explain why, in technical terms?

Thanks and Kind Regards

Piotr
I second that!! I use PluralEyes and FCP does not permit multiclip with different codec (EX1 35Mbps and nanoFlash 50mbps) It is a huge hassle....

Dear Piotr and Luben,

I wonder if all of the souces were the same, or if using the Sony SxS 35 Mbps recordings and the nanoFlashes 35 Mbps recordings, would match up find in PuralEyes.

I can easily speculate that PuralEyes was not designed to work with different codecs or bit-rates, but I really do not have any actual knowledge on this subject.

Dear Dan and Luben,

I used to have the trial version of PluralEyes that expired now, but can tell you I am usually able to synchronize manually (using waveforms) as precisely as PluralEyes can - yet in the case of EX1 35 Mbps (native) vs. nanoFlash 35 Mbps, this i s still impossible...It's close, but still the frame match is not quite spot on.

Dan, I wonder: how many frames long is the nanoFlash GoP in case of PAL (or 50 Hz Area) files, like my 1080/25p? It should be 12 frames (vs. 15 frames for NTSC) - but perhaps it isn't? If CD doesn't differentiate between PAL and NTSC GoP length, this could be one reason for the lack of frame synchronization with the EX1 native clips.

Also interesting would be to know what the number of B frames is, how the mpg2 non-linear quantization is performed, etc, etc...

BTW, it's a pity that a common utilities like MediaInfo cannot display all the CD codec info (it only displays bitrate of the video stream). No other data of the video stream can be read; MediaInfo doesn't recognize the audio streams, either.

Now I'm getting worried, not about the noise but why you cannot align frames.
Surely you can just line two clips up using the source timecode?

Surely you can just line two clips up using the source timecode?

Bob, you're a genius, and I'm an idiot.

I just tried the Multicamera tools in Vegas and managed to perfectly align a native EX1 clip with the simultaneously recorded, 35 Mbps nano clip, using "Lay out tracks using media timecode".

So, provided nanoFlash is using embedded timecode from the camera's SDI, it IS possible - at least with both clips being the same bit rate.

PS. It's also possible with different bitrates - so, looks like we have this problem (which branched off a little OT in this "noise thread") solved.

I was so focused on the noise issue that I never thought of this obvious method of alignment. Probably also due to the fact that in my multi-EX1 projects so far, I never relied on this tool in Vegas as the timecode tended to be a little off between the individual cameras, making it a must to manually synchronize using sound waveforms...


Thanks, Bob!

OK, I have revised my test material, and think I owe you all some very important update/conclusion.

Thanks to:

a) Rafael and Dan, who pointed out the importance of comparing I-frames for any conclusion about the noise to be valid,


b) Bob, who reminded me how to properly align two clips with frame accuracy, using internal timecode (shame on me !!!),

- I can more precisely conclude now that:

1. With the "shimmering" nature of the chroma noise (whose intensity and form changes from frame to frame in any Long-GoP file), some of my previous comparisons were invalid in that they didn't compare the same, precisely aligned frames of the EX1-native vs. nanoFlash clips. After having them aligned properly using internal TC (thanks Bob again), the highest bitrate nanoclips (like those at 180 Mbps) do show considerable chroma noise, but I'm now more prone to say - with a high level of certainty - that it's not so much the nanoFlash augmenting chroma noise, but the EX1's native codec hiding it (along with detail), due to its much coarser compression which smooths out the picture

2. Properly aligned comparison of the nanoFlash high bitrate L-GoP frames vs. EX1-native frames, does NOT show more chroma noise increase than I-Frame Only clips comparison with EX1-native frames - unlike I wrongly concluded earlier.

3. While apologizing for even more ugly pictures, I'm attaching one more pair of blown-up frames - this time, the EX1 native (left) vs. nanoFlash I-Fo at 220 Mbps. While the higher level of chroma noise in the latter is evident, so is the much lesser macroblocking - especially around the high-contrast shadow patches on the roof, or around the metal nail heads in the level board.

Dear Piotr,

I will look into the 12 versus 15 GOP question you raise.

In reference to "MediaInfo":

We have to label certain of our higher bit-rates as 50 Mbps, otherwise many NLE's would not recognise our files.

Of course, you get the actual benefit of the bit-rate you choose.

I do not know why the audio info does not show up in MediaInfo".

Dear Dan,

Actually, the newest MediaInfo version DOES recognize and display the bitrate correctly. It doesn't report other details (like the GoP structure and length), or any audio info at all - please see attached screen for a nanoFlash 180 Mbps L-GoP clip.

We have both agreed it's very difficult to synchronize the picture from EX1 and the nano perfectly when on separate tracks, one above the other, in an NLE. I do a lot of multicamera projects, and when only using material from several EX cameras, I'm able to synchronize them with frame accuracy using spikes in the audio waveforms.
piotr,
The problem is not to match the SxS picture with the Nano picture.
The problem is that the same frame in both devices are not necessarily the same kind of frame (I, B,P).
The camera processor and the Nano start to record in different moments.
The GOPs are not the same in both devices.
What is an I frame in the SxS file, may be a P or B frame in the Nano file.
rafael

Okay, I just want to say that this thread really shows how wonderful the nano is, and how excellent the guys at CD are. They patiently answered the ?'s posed here and came up w/ meaningful suggestions and good explanations.

And Piotr, thanks for all the images. This may have been a little bit of a chase down a rabbit hole, but I know I learned a lot reading through this.

Thanks again everyone and for letting me stick my nose into this. As much as the middle of this thread got a little muddy, the last two frames posted by Piotr are ringing endorsement for the nano.

Wow,

Those last two posted pictures form Piotr really are a huge endorsement for the nanoFlash. Even though I think the picture from the EX is one of the best for any sub $10K camera out there. But add in the nanoFlash and you end up with one incredible system. Very much worth the extra money and time of setting up equipment.

Garrett

I'm pleased everything in the garden is now rosy. I spent the weekend testing out my just arrived nanoflash and am very satisfied with the results to say the least.

piotr,
The problem is not to match the SxS picture with the Nano picture.
The problem is that the same frame in both devices are not necessarily the same kind of frame (I, B,P).
The camera processor and the Nano start to record in different moments.
The GOPs are not the same in both devices.
What is an I frame in the SxS file, may be a P or B frame in the Nano file.
rafael

Dear Rafael,

I fully understand your point - there are ways in Vegas to place the cursor on the I-frame exactly. The problem had been that I couldn't find a cursor position that would be at the corresponding I-frames for BOTH clips; once synchronized though, the frame comparison is now fair.

And the results are as I described above - predictable. In both nanoFlash formats, there is more detail and more noise than in the native EX1 clip; the higher the bitrate used, the more visible the noise.

Being aware of this, one must just decide on his optimum settings (of the scene, camera settings, and nanoFlash bit rate) which may vary depending on the intended destination of the video, CF/HDD storage space available, delivery format, extent of post-processing, using or not color correction in post, using or not noise reduction in post, etc.

There is just one issue left that still requires shedding some more light at, and I'm counting on some technical suggestions from Dan: the whip pan example, where the movement blur was evidently accompanied with not just excessive noise, but also heavy pixelation of the nanoFlash frame.

I'd like to thank everyone participating in this little "investigation" of mine for their friendly advice, and their patience with me :)

Piotr

Dear Piotr,

I do not like to speak beyond my level of expertise and I like to defer to others when evaluating images.
(I actually learn quite a lot by reading the posts of true experts.)

This, of course, does not mean that I do not have an opinion.

I will offer my analysis of the two images in Post 103, but only since you have specifically requested it.

You were doing a whip pan, according to another post in this thread.

When you record at 35 Mbps 4:2:0 in the nanoFlash or Sony EX camera you will see less detail, the image will have a smoothing effect.

With a fast whip pan, you can present more detail than the 35 Mbps can handle, thus it can appear smooth.

With a 100 Mbps codec, the signal presented by the camera will be recorded more accurately.
(This is not just marketing speak, this is based on a very thorough analysis by Mr. Richard Wolnowski who tested our 100 Mbps codec for 6-weeks, throwing excessive detail and excessive motion to the Flash XDR. Richard's testing was with the Thomson Viper and not the Sony EX, but the principle stays the same.)

In Post 103, I do not see pixelation, but this is one of the reasons that I do not like to analyze images. Others may call it pixelation, and they may be 100% correct.

Also, I do not know how this image plays back at normal speeds.

I assume that this was shot at very low light levels; you have provided much of the camera detail about this shot in a previous post.

May I suggest that you try some whip pans, if you are going to include them in your work, under more normal lighting conditions.

Also, since I do not present myself as an expert at image analysis, I welcome others to join in, in analyzing the images in Post 103.

I hope this helps.

Dear Dan,

Thanks for the clarification of your standpoint on this. Like you, I'm inviting everyone to discuss this issue. Myself, I'll repeat the "whip pan" experiment in a more controllable fashion.

In the meantime, however, I'd like to draw you attention to, and ask your opinion on, the following observation that is a little off-topic in this thread, but has surfaced as a side-result of my investigation described herein. As I mentioned in previous posts, I did have some difficulties in perfectly aligning simultaneously recorded clips from the EX1 and the nanoFlash. The method I've always used before with EX1 clips was based on the audio waveforms, and it doesn't work when one of the clip is a native EX1 clip, and the other comes from the nanoFlash: after aligning the waveforms precisely, the picture frames are slightly off.

At some point, Bob grant has reminded me about the obvious method based on the clips' internal timecode; using it it's now possible to align the video frames perfectly, but I'm seeing the following now:

1. The nanoFlash clip offset is some 9 frames, i.e. after precise video alignment, the nano-recorded clip starts 9 frames later in time than the EX1 "original". Some SDI latency is normal, I suppose.

2. What surprises me though is that with such a perfect picture frame alignment, the nanoFlash-recorded audio is further offset by an additional 1 frame (so the total audio offset between the nano clip and the EX1 original is some 10 frames). It would also explain why I couldn't get frame-accurate video alignment when using the audio waveforms!

The above numbers I can see with a 100 Mbps, Long-GoP clip. I haven't checked whether the offsets are the same with other formats/bitrates.

Could you please shed some light on it?

Piotr

Dear Piotr,

I am assuming that you are triggering the nanoFlash on Incrementing Timecode.

Yes, there is a slight delay in recording, a few frames. Of course, if these few frames are important, then you could use our pre-record buffer.

Generally, I recommend against using the pre-record buffer unless there is an actual need for it. It is easier to edit, in my opinion, if the extra seconds at the beginning of each take (the pre-recod buffer footage) is not there.

Is you nanoFlash in an idle mode (not playing back) when you trigger the camera to record?

If you nanoFlash is playing back, it takes longer to switch the nanoFlash (actually the Sony Codec), into record mode. We have to switch the Sony Codec from Playback Mode to Record Mode.

What firmware version are you using? This has significance in your audio/video sync issue.

Dear Dan,

Of your questions, the only one relevant to the audio/video delay difference is the firmware version I'm using - and this is the current 1.5.126.

I don't care about the overall delay - as I said, this seems normal to me.

Thanks,

Piotr

Piotr,

Are you saying that the TC is 9/10 frames off in clips recorded on SxS and NF. When NF is set to use TC from the EX?

I know that the NF lags in starting up, but the TC for the individual frames match in my setup. I will recheck to make sure, if this is what you mean.

Dear Olaf,

I believe that Piotr is saying that the file started 9 frames after the SxS file started.

The timecode on the frames will match exactly, as you have reported.

Piotr also said that the audio is one frame off, with firmware 1.5.126 under his test conditions.

Olof,

Let us clarify: after TC alignment in Vegas, both clips' video is perfectly synchronized with a single frame precision and TC matched exactly. BUT:

I just aligned other 2 clips by TC, and now the nanoFlash clip (100/L-GoP) starts 23 frames later than its EX1 "original", and its audio is still 1 frame behind (i.e. lags by 24 frames behind the original - take a close look a the waveform peaks, e.g. right to where I placed the cursor).

Dear Olaf,

I believe that Piotr is saying that the file started 9 frames after the SxS file started.

The timecode on the frames will match exactly, as you have reported.

Piotr also said that the audio is one frame off, with firmware 1.5.126 under his test conditions.

Dear Dan,

Should we start another thread on this? This one is already very long, and complicated enough :)

Dear Piotr,

Just as a camera with a tape deck, it takes time to start recording.

Your EX camera may also take time to start recording. I do not know if this is true or not, but you could test it by recording a clock with a sweep second hand.

When starting the nanoFlash via incrementing timecode, it takes us time to start recording.

It does appear, that in 1.5.126, the audio is off by one frame.

It is not appropriate to say that we our audio is out of sync by 24 frames.

Dear Piotr,

Just as a camera with a tape deck, it takes time to start recording.

Your EX camera may also take time to start recording. I do not know if this is true or not, but you could test it by recording a clock with a sweep second hand.

When starting the nanoFlash via incrementing timecode, it takes us time to start recording.

Dan - I said it's natural to me.

It does appear, that in 1.5.126, the audio is off by one frame..

Am I to understand you confirm this officially? So, it's not just my unit - right?

It is not appropriate to say that we our audio is out of sync by 24 frames.

I never said this - I only explained to Olof that while the NF video can lag as long as 23 frames behind the camera source, the audio seems to still be one more frame behind the video...

Dear Piotr,

I am assuming that you meant to say "Frames" and not "Seconds".

I do not think that your nanoFlash is experiencing difficulties.

We put great effort into attempting to achieve perfect Audio/Video sync.
Surprising as it may seem, we have to ensure that it is right, for every mode/option, for every release that we build.

Based on your comments, it appears that we are off by one frame for your specific conditions.
We will work on this.

You are using 1.5.126. Our latest firmware that we sent out, a Public Beta, is 1.5.249.
We will be releasing new firmware soon. It will be 1.6.xxx.

Dear Dan,

Sure thing - I meant frames, not seconds (correcting now).

Thanks for the information

Piotr

Dear Piotr,

In our upcoming release, and (I believe) in the Public Beta 1.5.249, you will find that the delay before we start record has been drasticly reduced.

Also, the Audio/Video sync has been improved in our latest releases.

Our latest release 1.6.6 is in test. We will release it as soon was we finish testing it.

Thanks Dan! That's great. A question to you please. My NF some how did slowdown after I upgraded to the new beta firmware. The slowdown is quite visible when booting and going through the menu. Going back to the Production firmware does not fix that problem. I am sure that this has happened.
Would you please comment on this.
Thank you
Luben

Dear Dan,

Thanks for the information. I must admit that - having spent almost 2 months to make the previous Beta work with my specific CF cards - I didn't even load the current public Beta at all, after learning the Record Indicator doesn't work as expected :)

But of course I'm eagerly looking forward to the 1.6.6 version. By saying "the delay before we start record has been drastically reduced", you got me very interested to know:

- is the delay constant now?

The reason I'm asking this is that - as you have probably noticed - with the current firmware I've been getting delays varying considerably (like 9 - 23 frames); is it going to be more consistent now? Of course, we're still talking "Incrementing TC" trigger mode....

Thanks and Regards,

Piotr

Dear Piotr,

There are three main components in the nanoFlash.

1. The Sony Module, which performs the codec work, compression and decompression.

2. The FPGA (Field Programmable Gate Array). This is an extremely fast device and does almost all of the work in the nanoFlash.

3. The Microprocessor. This is a relatively slow device, which does housekeeping, other tasks, and the human interface.

Previously, the Microprocessor was used to setup the nanoFlash for recording.

Now, the FPGA performs this task and it is much faster.

When the new release comes out, I suggest that you run your own tests, but I feel that it will be very consistent.

Dear Piotr,
Now, the FPGA performs this task and it is much faster.


Wow - this sounds like a serious progress, Dan.

Thanks!

Piotr

Dear Piotr,

Yes, this is a serious improvement.

Dear Dan,
I posted a question for you here and in Beta Firmware Thread. Would you please care to comment on it here or there please. Thank you