Dear Friends,

Billy, Peter and Adam, I appreciate your assistance.

If the consensus is that this applies to HD and "Production" would be a worthwhile change, then we will, of course, consider the change.

I hope everyone understands that we have to be conservative. We can cause a lot of problems for ourselves and others if we make a change and it causes unexpected problems.

I will bring this up with our engineers.

I also want everyone to know that this, at this time, seems like a safe change.
After all, this is used by the Sony EX cameras, and I have not heard of any problem with it.

While in an ideal world we could have an option for everything, having lots of options adds to the complexity of the system, and it intimidates new users. For every new option, there are many that do not understand the option and it creates confusion and uncertainty.

Thus, it would be my choice to investigate this change the make it. After all, this "Aperture" function is not widely known, nor intuitive even to experts.

Dear Adam,

Others have suggested that we use "Production".

Is this your recommendation as well?

Yes, I would go with Production since that is what you are actually saving into the files.

Dan,

If you want to play it most conservatively, you might want to test if changing to Production makes any difference to those users who are having problems. That can pretty easily be done by changing the Aperture setting in Quicktime Pro and saving the file. Here's a step-by-step:

Open the file in QT Pro, choose Window, Show Movie Properties and click on the Presentation tab. There is check box called "Conform aperture to:" and next to it is a pulldown menu with the four different Aperture Mode choices. Choose "Production Aperture" and save the file. That should do the same thing as changing the Aperture Mode that the nano writes.

This way those users can test to see if the Aperture setting change makes any difference. But of course if you think it really isn't necessary to test this way, then I would imagine that a change to Production would not cause any problems.

What I do find odd is that Aperture Mode is causing a mismatch between the EX and nano files. B/c square pixel files (which XDCAM 422 uses) should display the same using Classic or Production, AFAIK. (That's b/c Production does not crop the edges, it only adjusts for pixel aspect ratios that are not 1:1.)

Best of luck with all this :)

Dear Adam and Peter,

We will investigate this.

Right now, based on the document that I read, for HD, I am guessing that changing to Production will not make any difference.

But, we need to run some tests.

We welcome others insterested in this to run their own tests, using the procedure provided above and report their results. Our employee who would normally run this test is out sick, so we will have a delay before we can test it.

Dear Dan, Peter, Rafael and Billy,

I'm of course following your posts on the Aperture setting in QT files with great interest, but - having no access to Mac/full QT player / FCP, and only working with MXF - I cannot help much. Has anyone found any information about using a similar setting in MXF files?

That said, I still believe the differences in scopes I posted are mainly due to the 420 vs. 422 color subsampling.

Cheers

Piotr

As one of those who changed the subject of this thread, I'd like to repeat my kind request to Chris to move the posts, related to the Aperture subject, into a new thread of its own.

Coming back to the current Beta discussion, I'd like to say that - to my very positive surprise - I have discovered that my Transcend 400X, 64GB cards now work with 280 Mbps bitrate!

Dan, if CD has improvement on the nanoFlash performance again - then all I can say is WOW, thank you :)

Piotr

PS. Please answer my question about the slight audio lag, though....

Dear Piotr,

Please be careful in testing for 280 Mbps.

Please record a test until the card completely fills up.

We have a huge buffer in the nanoFlash. A slower card will appear to work at a higher speed due to this buffer, but, over-time, our buffer will fill up, and we will have to down-shift to a slower bit-rate.

(And most any card will work at 280 Mbps if one is doing a time-lapse sequence.)


For the audio delay, could you run a test for us?


Record internally, and record to the nanoFlash.

Have a clapper or other similar device, very close to the lens and microphone.

Test, in post if the audio and video are aligned.

Test using Sony Vegas Pro 10.

Then check the footage in Sony Clip View 2.30.

Then test the nanoFlash clips.

I am will say that it would be possible for the nanoFlash to be 0.004 seconds off..

Before we run the audio alignment tests, I will need to know the details when you noticed that they were 0.004 seconds off. What Frame Rate, Embedded or Analog Audio Input, specific camera, how far the sound was from the Mike, etc.?

Dear Dan and all,

APERTURE:
I've been playing with the "Aperture" on different NANO's and SxS clips(1920x1080 and 1280x720).
I can't say more than: The more I play, the most confused I get.
I don't know if I'm making something wrong or QT Player is behaving in an erratic and unexpected way.
In short: Applying the same aperture to the same clip, not always shows the same picture. Changing modes, some times the picture shows four different "aspects". Some times I shift modes and I get only two "aspects". Some times, no change.
it seems that the 4 modes shows the same. Then, I have to close the picture and open again to make functional the "Aperture" control.
So, sorry, but nothing clear.
So two options:
- Let things as they are.
- Change mode. In this case I think the best option I think should be "Encoded Pixels".
As the Apple says:
"Encoded Pixels: Neither crops nor scales the video. A DV NTSC (4:3 or 16:9) track appears as 720 x 480.
With HDTV formats, we have nothing to correct. We know that we have 1920x1080 or 1280x720 Square pixels.
Thats exactly what we have to display: FULL/PLAIN HD.

PIOTR's Test
SxS and NANO picture compared on the Vegas VideoScope;
The same difference that shows Vegas, is shown by FC.
But I do not consider the differences on the Waveform neither on the Vectorscope. I think that the differences on Waveform and Vectorscope is understandable and is due to the 422 vs 420 compression.
The difference to consider is on the Histogram.
For me here is the problem.
What is what should show a Histogram?
The Waveform shows Luma and the measure unity are IRE.
The Vectorscope shows the phase of the Color Components, and the resulting Chroma Vector.
But, what should show the Histogram?
What measures make?
Which unities uses?
Well, the Histogram doesn't really measure nothing.
Is an spatial representation of the Luma values of the whole picture (some systems/software have also RGB Histograma).
The Histogram try to give a visual idea of the main "luma bands' (?) on the picture.
You need accuracy on a Waveform and on a Vectorscope because otherwise you are at risk of going "illegal", but YOU REALLY DON'T NEED MUCH ACCURACY ON A HISTOGRAM.
Those little differences doesn't change nothing for the Video Editor/Colorist.
So I think that the differences may be due to the no much exigent design of the filter.

So take the Histogram for what is intended: A rough visual representation.

Make a test:
Transcode your SxS and your NANO clip to any 8b and 10b Uncompress format and compare their Histograms.
You will find that the 6 clips shows 6 different Histograms.
No much concern about that anyway.
Cheers,
rafael

We have a huge buffer in the nanoFlash. A slower card will appear to work at a higher speed due to this buffer, but, over-time, our buffer will fill up, and we will have to down-shift to a slower bit-rate.


Dear Dan,

I'm aware of the buffer, but with previous firmware, it filled up and the nano down-shifted pretty quick when recording 1080/25p I-Fo at 280 Mbps.

Now, of course I didn't have time or patience to fill up entire card, but I recorded more than 5 mins video is several files. It never down-shifted!

As to the audio lag, the picture below shows waveforms of the nano (upper) and native (bottom) clips, recorded simultaneously on the EX1, with the nano fed from SDI. They have been aligned on Vegas timeline using single video frame accuracy. The ruler is scaled in seconds. I really don't know what else I can say.

Thanks,

Piotr

Dear Piotr,

To prove that the 280 Mbps will actually work for you, for long takes, you will need to fill up the card.

You can also use one of our new features to "see inside" the nanoFlash.

We now have a FIFO level display. FIFO is the First In, First Out buffer.

The lower the percent of the FIFO that we are using the better.

If the FIFO creeps up and then goes back down, then this is normal.

If it jumps up then stays up, the the card is too slow for the Bit-Rate in use.

The following is from our latest manual 1.6.226.

Fifo Meter Display:

Displays the CF card's ability to keep up with the data rate of the video.

From the main menu, press and hold the left arrow key, and then press record button to initiate
a record session.

If Fifo meter rises over time towards 100%, the CF card is too slow to
handle the data rate. (Small spikes in the meter will appear during file transitions.)


As far as the audio, I see that the audio is different by 4 ms.

Which one is closest to being in-sync with the video?

How far away from the mic is the sound source?

In dry air at 20 °C (68 °F), the speed of sound is 343.2 metres per second (1126 ft/s). (Wikipedia)

Thus 0.004 seconds is about 4.5 feet away or 1.372 meters. (Dan)

Dear Piotr,

We have a huge buffer in the nanoFlash. A slower card will appear to work at a higher speed due to this buffer, but, over-time, our buffer will fill up, and we will have to down-shift to a slower bit-rate.


Dear Dan,
Just for curiosity, how big is the buffer?
rafael

...
As far as the audio, I see that the audio is different by 4 ms.

Which one is closest to being in-sync with the video?

How far away from the mic is the sound source?

In dry air at 20 °C (68 °F), the speed of sound is 343.2 metres per second (1126 ft/s). (Wikipedia)

Thus 0.004 seconds is about 4.5 feet away or 1.372 meters. (Dan)

Sorry to jump into this, but I had mentioned mic distance to Piotr, and he responded that:

1) The EX and nano were recording sound simultaneously from the same mic, so any delay caused by distance should be the same for both.

2) He never experienced this delay until this new firmware upgrade.

(I hope I characterized his responses correctly.)

Okay, I'll leave ya'll alone now :).


-Peter

Dear Peter,

Thank you.

1. Yes, that makes perfect sense, same distance for both.

I did the calculations to show how critical the distance is, even a short distance, for getting the audio and video synced.

2. That may be true also, but did Piotr run these tests earlier?

Of course we want to get the audio/video sync dead on.

But, a lot goes into this. A lot also goes into the camera to get the audio and video syned up also.

We do not know, for a fact, if the audio and video are perfectly lined up in the internal recording, and if this exactly matches the HD-SDI out. It may be, and I would expect it to be, but we have to consider this possibility.


Also, I am attempting to envison a reason, if one is recording to an EX camera, and to the nanoFlash simultaneously, why one needs to intercut footage from the EX with the nanoFlash footage.

But, as I said, I want to get this audio / video sync as close as possible.

Right now, .004 seconds, or 1/250th of a second is pretty close, but not perfect.

The Vegas Timeline Piotr has posted has been zoomed in greatly to show this offset.

Also, I am attempting to envison a reason, if one is recording to an EX camera, and to the nanoFlash simultaneously, why one needs to intercut footage from the EX with the nanoFlash footage.

Dear Dan,

In the type of recording I mentioned earlier in this thread, I usually shoot the live classical music performances with 3 cameras (EX1's). In the ideal world, they all should be recording to nanoFlashes - but unfortunately, I only have one. So I'm using it with the main camera, and the nanoFlash files get intercut with the native XDCAM EX from the other two (I know it's not a good scenario, but at least I have some material of the highest quality possible).

So, as you can realize, it's of paramount importance that for multi-camera edits, I can be sure all images are in the same position in time in relation to the sound (which is BTW recorded separately, the on-camera sound being only used for reference during editing).

You could say now that the offset can be greater due to the cameras being located in different distances from where the microphones are, and you'll be right - but the human brain is very smart, and when watching a musician from some distance, it allows for slight delay in sound. On the other hand, no delay whatsoever is tolerated for close-ups - and when I show them from 2 or 3 different angles, I must do this tedious sound slipping by milliseconds, in order to get it right....

Piotr

Dear Dan,
Just for curiosity, how big is the buffer?
rafael

I second this question, Dan - right now recording at 280 Mbps on my Transcend 400X card, and the buffer only filled up to some 30% at the beginning, but now is at no more than 10%...

So, could it be true that with the new firmware, the Transcend cards are fully capable of 280 Mbps?

Piotr

PS. Still recording at 280, and the buffer bar is barely above 0%!

Call me stupid, but looking at Piotr's Vegas timeline, the larger increments on his scale are 0.002 seconds and the smaller divisions are 0.0002 seconds. So it looks to me that any delay might be in the order of 0.0001 seconds because, to me, that's all the shift between the waveforms appears to be.

Put another way, that's about 100 microseconds. I can't believe it is even being considered a problem, unless it is cumulative. If it is constant then who cares? I defy anyone to hear that delay in a real-world application.

Cheers

Russ

Call me stupid, but looking at Piotr's Vegas timeline, the larger increments on his scale are 0.002 seconds and the smaller divisions are 0.0002 seconds. So it looks to me that any delay might be in the order of 0.0001 seconds because, to me, that's all the shift between the waveforms appears to be.

Put another way, that's about 100 microseconds. I can't believe it is even being considered a problem, unless it is cumulative. If it is constant then who cares? I defy anyone to hear that delay in a real-world application.

Cheers

Russ

Russ,

It's exactly 0.004 sec - please compare the length of the selection bar with the distance on the ruler, between the 22,370 and 22,374 stops...

Dear Dan,
Just for curiosity, how big is the buffer?
rafael

Dear Rafael and Piotr,

It is very large, but I consider the size to be a trade secret.


Dear Rafael,

Our recommended bit-rates have to be conservative.

Not all cards, of a certain brand/type perform exactly the same.

And cards get busy, at times.

If 280 Mbps, with your Transcend 400x 64 GB cards works, then great.

And I have no problem with others testing their cards.

Just remember, I recommend taking the time to record until the card is full during the test.

As everyone should be aware, we have a program to constantly refine the firmware in the nanoFlash.

Our recommended bit-rates have to be conservative.


Dear Dan,

While I understand the above statement, just a technical question: if the buffer shows less than 10% after some 5 mins recording, and stays this way - is there still a chance it would overflow? If so, what could ever cause it?

Of course, if I ever use my cards at 280 Mbps in production, is my own responsibility.

Piotr

Dear Piotr,

When we fill up one file, we start another, and then while we are writing the video and audio to the new file, we go back to write the large index to the old file.

If the card is not fast enough to keep up with this double writing, then the level of the FIFO will increase.

If the FIFO buffer level then goes down before before the second file is finished, then you are ok.


Please understand that you need to perform a recording, to your card under test, until the card is full.

Dear Dan,

In the type of recording I mentioned earlier in this thread, I usually shoot the live classical music performances with 3 cameras (EX1's). In the ideal world, they all should be recording to nanoFlashes - but unfortunately, I only have one. So I'm using it with the main camera, and the nanoFlash files get intercut with the native XDCAM EX from the other two (I know it's not a good scenario, but at least I have some material of the highest quality possible).

So, as you can realize, it's of paramount importance that for multi-camera edits, I can be sure all images are in the same position in time in relation to the sound (which is BTW recorded separately, the on-camera sound being only used for reference during editing).

You could say now that the offset can be greater due to the cameras being located in different distances from where the microphones are, and you'll be right - but the human brain is very smart, and when watching a musician from some distance, it allows for slight delay in sound. On the other hand, no delay whatsoever is tolerated for close-ups - and when I show them from 2 or 3 different angles, I must do this tedious sound slipping by milliseconds, in order to get it right....

Piotr

But has this issue always been there or is it something new with this build?

Peter,

You misunderstood one of my previous posts on this - the audio drift used to be even longer with previous firmware releases (I don't know about the 1.6.29, though - as I skipped that).

So if I mention the 4 milliseconds now is because I appreciate it's improving, but still not quite there yet:)

Piotr

Piotr,

You are obviously very technically adept and clearly you strive for excellence in your productions - as we all should. I come from a telecommunications and telemetry background and from all the training I have done, the 4 ms delay you are worried about would be absolutely imperceptible to the average punter.

You know its there because you have the means to test it. The viewer, on the other hand, probably hasn't a clue. I have copied and pasted a paragraph (below) from a paper about the subject (which as you will know is commonly just referred to as lip-synch problems).

Quote:

From time to time, standards committees in various countries have addressed the problem
of audio to video timing errors, and have set standards or guidelines for the maximum
allowable amounts of these errors. For the most part, these standards or guidelines are in
agreement that lip sync errors start to become noticeable if the audio leads the video by 25
ms to 35 ms, or if the audio lags the video by 80 ms to 90 ms."

End quote

The paper was authored by:

J. Carl Cooper
Mirko Vojnovic
Chris Smith

and can be viewed here:

http://www.pixelinstruments.com/pdf/Articles/A%20Short%20Tutorial%20on%20Lip%20Sync%20Errors.pdf

Honestly, whilst I think it is admirable that you are striving for perfection in everything that you do, I think Dan probably has a lot more to worry about than trying to correct things that simply don't matter to the end-user of the recordings.

Cheers

Russ

Thanks Russ for your comments, and the link to some interesting reading.

I'm not ranting - to the contrary; the delay used to be almost half a second when I first got my nanoFlash, and now it has been greatly reduced. But still - and I'm sure Dan understands me well - the matter is two-fold:

1. From purely technical viewpoint, I don't see a reason for any discrepancies between nano and native recordings. Of course, there is some latency to any type of connection, including SDI - so I have no problem with the fact that the nano clips start a couple of frames later than the native ones. But, inside the SDI stream, the picture is spot-on with the TC - why not the audio?

2. As to what is noticeable and what's not - I can assure you that if a guitarist's fingernail, pulling a string, is more than 5 ms off in relation to the sound, it will be noticeable (especially on 50+ inch screen's closeups). So, 4 ms is just barely tolerable (I agree that for the lip-synch, even 25 ms may be OK; also some other instruments might pose much lesser demands in this regard than the guitar does).

Cheers

Piotr

PS. I've just noticed you're located in Australia - if you are in touch with Bob Grant, you might ask him about the amount of effort I put into editing that particular guitar recital; he also is in possession of the DVD I produced....

G'day Piotr,

sorry if you got the impression that I thought that you were ranting, because I certainly didn't intend for you to interpret it that way. I think that the point about the audio/video being out of synch is being laboured a bit, not ranted about.

Anyway, hopefully the team at CD have got their teeth into the problem by now, although there will be a limit to how much they will be able to achieve. As you pointed out yourself, there are latency issues, and many other issues that are not even the nano's fault, so I don't think that perfection will be achieved. Time will tell.

I do correspond with Bob, and although we live on opposite sides of the country, I hope to catch up with him next year when I go to Sydney, even if it's just for a coffee (or beer.)

Cheers

Russ

Just curious, at what stage of the beta firmware does CD recommend downloading the new firmware?

Thanks

Dear Anthony,

1.6.226 is a Public Beta. Thus, we encourage our users to download and load this version on their nanoFlashes so that they can test it.

After they have finished their testing, then we recommend re-installing 1.6.29 for production work.

And, of course, if you have any quetions or problems with the firmware, please contact us.

We have had very few reported problems with 1.6.226, thus I would expect that we will issue Production Level firmware fairly soon.

We have had very few reported problems with 1.6.226, thus I would expect that we will issue Production Level firmware fairly soon.

Looking good then Dan.

Thanks.

I can confirm that the newest Beta is the best nanoFlash firmware ever - no doubts about it. A real milestone, and very stable, too.

Piotr

I can confirm that the newest Beta is the best nanoFlash firmware ever - no doubts about it. A real milestone, and very stable, too.

Piotr

Thank you Piotr, I think I will download it and try it.

Thanks.

I personally would never do a job with Beta FW.

Try it, help debug it. But if you have an important job go with the latest official version.

I think that is what CD wants you to do. You don't want to find a bug while on a job. Just my opinion.

Try it, help debug it. But if you have an important job go with the latest official version.
I think that is what CD wants you to do. You don't want to find a bug while on a job. Just my opinion.

Thanks Olof.

Hi all,

We've been testing the audio sync when recording lower bitrate MPG recordings (as viewing copies).
used to be 4 frames out, but now seems to be dead on and a lot more stable.

Still testing, but looking good for that improvement.

Thanks guys.

Regards

Dave

Dear Olof,

Exactly, thank you for making that clear.

Our Public Betas are to allow others to test the upcoming release.

While our testing is very exhaustive, we may miss something, and we do not have every camera in our lab.

And others may use the nanoFlash or Flash XDR differently than we do.

After testing the nanoFlash, for production we recommend going back to the Production Level releases.

Our next step is to release Production Level releases.

Dear Dave,

Thank you for the good news.

We greatly appreciate the feedback.

Only thing I have noticed with the beta version is when I press the camera record button (TC) the light on the remote control cable stayed red for about 90sec then started flashing then another time it could take maybe 15mins (or more) before it flashed.

Why the variation in time?

Thanks.

Dear Anthony,

When the Tally Lights flash, your media is nearly full.

It starts to flash when you have less than 5 minutes left.

Then it flashes faster when you have less than 2 minutes left.

Dear Anthony,

When the Tally Lights flash, your media is nearly full.



Hi Dan,

I have 106 mins of SDHC card left and 48 mins of CF card remaining and its still flashing.
Perhaps its a setting on the NF, thinking I'm almost out of media.

I don't mind the flashing, I'm glad to see it, I know the NF is recording, its just, why the difference in time before it begins to flash.

With the 1.6.29 firmware the remote cable button stayed red all the time while I was recording, now with the beta firmware it flashes, thats fine, no problem with that, it was when it stayed on full red then decided to flash, its that I was curious about, thats all.

Dear Anthony,

If you are using1.6.29 (Production Level) or 1.6.226 (Public Beta) firmware, both should stay on full, until the card get low.

Much earlier firmware flashed all of the time.

The nanoFlash can not determine the level of your in-camera media, such as SDHC cards.

Have you formatted the CompactFlash cards in the nanoFlash?

Maybe we have a problem with the Public Beta, we can check.

Is anyone else seeing the Remote Tally light or the Status Light on the side of the nanoFlash flash while there is still over 5 minutes of recording time left?

The nanoFlash can not determine the level of your in-camera media, such as SDHC cards.
Have you formatted the CompactFlash cards in the nanoFlash?
Maybe we have a problem with the Public Beta, we can check.


Hi Dan, I will try SxS cards and see what happens.

Yes, I formated the CF in the NF.

Thanks.

Dear Anthony,

The nanoFlash records separately from the camera.

And the nanoFlash does not know the level of the media in the camera, they are completely separate.

I hope this helps.

The nanoFlash can not determine the level of your in-camera media, such as SDHC cards.



Hi Dan I thought you meant it applied to SDHC cards only,... thats why I said I would try SxS,

NF set at TC and also set for Remote record and the tally light on the remote cable is flashing at both settings :) (status light on the side of the NF flashing too btw)

So are you saying it shouldn't flash at all, even with this beta version that is, until the cards get low.

Dear Anthony,

If you have more than 5 minutes of Record Time left,
and you are using 1.6.29 or later,
the Tally Light on the wired remote control should not flash.

At the bottom right of the screen is a number. This is the number of minutes of recording time left.

What does your nanoFlash display for the number of minutes left?

If you format your cards in the nanoFlash, does this number change?

While you are recording, does this number decrement for each minute you record?

What do the Card Space Used indicators, at the top of the screen show?

What firmware are you using, this is in System|About?

Hi Dan,

69 mins left
Formated Card it now says 116 mins
Yes, decending and after recording it now says 112 mins
Card space plenty, just the start of a line going from L to R
Firmware 1.6.226
MP2 Codec: 01.02.06

Thanks.

UPDATE. Flashing with 78min remaining on CF card.

Dear Anthony,

Thanks.

By Flashing I am assuming you mean the Tally Light at the end of the wired remote control, in other words, the LED in the remote control switch is flashing.

And I am assuming that you do not mean the LED on the side of the nanoFlash that flashes Red when the nanoFlash is recording.

Are my assumptions correct?

In any case, we will attempt to duplicate this in our lab.

Hi Dan,

Yes, the LED tally light on the remote control cable is flashing.


I do not mean the LED on the side of the nanoFlash. (although this does flash when recording too btw)

Thanks again.

Dear Anthony,

Thank you for the confirmation.

We will duplicate the problem in our labs and then fix it.

Hi Dan thanks.

It would be me :)

I have no problem with the tally light on the remote cable flashing, I was just curious why it took anything from 90 sec to 15mins, or more, before it started to flash, thats the only reason.

I don't have a lot of experience with the NF having only just bought it but what I really like about this beta firmware is the ability to hotswap the CF cards and the power saving option. All very useful when recording weddings.

So thanks CD and to you Dan. I would highly recommend a NF to anyone thinking of buying.