Hi Friends,

Had a chance to shoot some really interesting footage. When this happens we break out the HDCAM. Lately we have been using the XDR as a backup on theses shoots. So it is from the camera, to the Miranda, then into the XDR as QT files.

This gig we tried the 160Mb I Frame only. On site it looked great. Played back from the XDR to the monitor looked pretty good. Back in the studio, we try to bring the files into FCP and all we get is a green screen and the occasional scrambled image.

Someone please tell me this is a codec issue in FCP with a simple setting change.

David Schmerin
Speaking for the minority one

David:

With the HDCam, why aren't you coming right out of the HD-SDI port and straight into the XDR?

I was considering the XDR strongly as a way to be able to use my HDCam with the home AVID system, without needing a deck. Is there a problem that requires the Miranda?

Hi David-

Are you using one of the Fast Compact Flash cards: 1) Transcend 300X 16GB or 2) Sandisk Extreme III 32GB? The 160 Mbps absolutely requires a fast CF card. Also are you copying the files to your hard-drive for playback or trying to play directly off the CF card? If you have a FW-800 reader, this may be OK, but I doubt a USB reader will provide sufficient bandwidth.

We can playback 160Mbps I-Frame only footage on our FCP system without any issues whatsoever.

Best-

The cards in the XDR are Transcend 32GB 133x cards. And as I said, the files played back from the unit to the monitor with no problems. Back in the studio, we copied the files to hard drive.

Also, as a last resort, we tried to convert the files to .mxf The converter converted the files with no errors reported. When we try to open the files on a PC (also first copying the files to hard drive) the Sony utils can open the files, they just can not play them.

Thanks

David Schmerin
Speaking for the minority of one

Dear David,

What are the settings for your timeline in Final Cut Pro?

Our experience is that the Transcend 32 GB 133x is not fast enough for recording I-Frame Only at 160 Mbps.

This card works up to and including 100 Mbps, but not at 160 Mbps.

If you wish, we will be happy to examine the files on your card. We will attempt to play them on a variety of NLE's. If we find the files are good, or portions are good, we could transfer them to another card, or render them to another format that will work on a Transcend 32 GB 133x card.

What function does the Miranda box serve?

Doesn't your HDCAM have an HD-SDI port?

Hi Friends,

First, no our F-900 does not have an SDI out. Only certain models have this feature. The rest of us use a Miranda DVC-802 Full Quality Downconverter and DV Encoder for Sony HDCAM and Panasonic Varicam - Miranda Technologies (http://www.miranda.com/product.php?l=1&i=226) in a wired configuration.

And, while the Transcend 133 cards are said not to be fast enough, it does not explain:

1) Why the video played back just fine to an on set monitor from the XDR box.

I will without prejudice assume that FCP could read the source files and the .mov to .mxf converter converted the files with no issues because the file formats were correct only the data within corrupt.

While I thank you for your offer to examine my files, these files are not mission critical as we shot to tape. Nor do I have the time or the inclination to send out customer materials. In that we also have just about every NLE to work with not much point sending materials in just we be told the files are corrupt.

Fortunately, the XDR was only used as a Backup and we have original Tape Source to work with.

David Schmerin
Speaking for a minority of one

PS: I downloaded the PDF manual to the XDR unit from the Convergent Designs web site and I personally feel (just my opinion) that it is need of serious rewriting by perhaps a professional technical writer.

Hi David-

I ran the same test this morning, using the Transcend 133X cards at 160Mbps. I did find that most of the footage would play OK on the Flash XDR, but after a minute or so, the video would jump for a second or two and then re-sync with proper playback. Playback on the PC was marginal with jumpy images and green screens.

I suspect the hardware CODEC inside the Flash XDR is simply more tolerant of errors in the bit-stream as compared to software CODECs. So while playback on the MAC/PC may choke and stop, the hardware CODEC has error resiliency and can reset and continue playing.

We are quite specific in all our documentation that the 160Mbps does require the faster CF cards. Yes, we do agree that the owner's manual needs a professional rewrite; that effort is underway now.

In a future release we may in fact be able to squeeze more performance (higher bit-rates) out of the 133X Transcend cards, but this requires more testing and evaluation.

Best-

Hi Mike,

Always a pleasure to hear from you.

Now first things first...

The first thing you have to remember about me is that I am not the brightest bulb in the box. Also, I am more then prepared to say that the issues we faced were clearly of our own doing.

With that said, there is always a however. In this case the "howevers" are:

1) Being the simple guy that I am, the first thing I did was download the PDF manual from your web site.

2) I then searched the PDF for any reference to I-Frame and found no reference to minimum requirements for the CF cards or CF cards at all. I never thought to try to search the PDF for 160. I am sure if I had I would have found Section 3.6.

And so with a basic knowledge of the workings of the unit and no reason (again my fault entirely) to think the CF cards would not be fast enough, we sallied forth on our shoot.

Now we have to go back to the very first notion that I am a simple person and as a simple person I have a few simple observations:

Even after searching your manual again (after reading your post) for 160, except for section 3.6, I did not see anything there or anywhere else (again to me the simple person) suggesting the 32G 133x would not work. I am also prepared to say if I was too stupid to find it, I should not be doing my job.

If the Transcend 32G 133x cards do not work as we can now both clearly agree on, then the superiority of your XDR units playback ability might lead other simple people like me into believing in a false sense of security. For certainly we watched playback on set from the XDR a whole lot more then 2-3 minutes had no reason to doubt the quality of the files.

Also, I am also left wondering why the XDR unit itself gave no indication during the record that we were trying to feed it too much data too fast for it to properly write to clearly inadequate storage media.

I guess really what I am saying is to me, if the cards would not work, the whole of the system should have had issues from record to playback from the XDR unit and I should have known right away and on set. Instead I found myself back in the studio going WTF to the editor and saying thank goodness we had tape rolling.

David Schmerin
Speaking for a minority of one

Hi David-

I agree with your observations. We do need to update (actually rewrite) the manual and we need to auto-detect the CF card and display a message on the LCD screen, such as "Slow Card", if the card does not meet the minimum speed requirements.

We'll get both of these issues corrected in the coming weeks.

Thanks for the feedback and recommendations.

Best-

David what setting are you using in Final Cut to edit 160Mbp/s I Frame?

David:
It has been repeatedly noted on DVInfo that the 160 I-frame requires the faster 300X cards.

Beyond that, the Release Notes (very quick read) that came with the first firmware release of the 160 I-frame capability very clearly also stated the need for the faster 300X cards. The warning was the 3rd item in the Release Notes. Quote from the Release Notes is below.

********************************

"Version 0.0.245 ( 6-Feb-09 )-

o I-Frame only recording option, 100 mbit or 160 mbit (160 mbit requires faster CF cards such as Transcend 300x cards)."

********************************

And every set of firmware Release Notes thereafter also contained this same notation of the faster card requirement.

If you are going to install the firmware upgrades, you might want to read the Release Notes that come with each firmware upgrade. Important info about the new capabilities and changes made with the firmware update are contained in the Release Notes.

I sincerely hope you are not suggesting that C-D withhold releasing new capabilites and fixes until they have a technical report writer rewrite the entire manual before they release the new firmware!

The method C-D is using of supplying brief pertinent Firmware Release Notes is far superior. I think most of us would hate to wait weeks or months for a new capacity or bug fix and then spend the time parsing through a 60 page manual to learn about the changes that apply to the new firmware.

David what setting are you using in Final Cut to edit 160Mbp/s I Frame?

Assuming I am understanding the question....

The timeline was set to use the XDCAM HD422 1080i60 (50Mb/s)

Our thought was if this was the wrong codec to be using, the timeline would have asked to correct itself to match the video format when we tried to place the video.

David Schmerin
Speaking for a minority of one

Thanks David that is what I thought. So really there is no way to edit 160Mbp/s I Frame in Final Cut.

David:
It has been repeatedly noted on DVInfo that the 160 I-frame requires the faster 300X cards.

Beyond that, the Release Notes (very quick read) that came with the first firmware release of the 160 I-frame capability very clearly also stated the need for the faster 300X cards. The warning was the 3rd item in the Release Notes. Quote from the Release Notes is below.

********************************

"Version 0.0.245 ( 6-Feb-09 )-

o I-Frame only recording option, 100 mbit or 160 mbit (160 mbit requires faster CF cards such as Transcend 300x cards)."

********************************

And every set of firmware Release Notes thereafter also contained this same notation of the faster card requirement.

If you are going to install the firmware upgrades, you might want to read the Release Notes that come with each firmware upgrade. Important info about the new capabilities and changes made with the firmware update are contained in the Release Notes.

I sincerely hope you are not suggesting that C-D withhold releasing new capabilites and fixes until they have a technical report writer rewrite the entire manual before they release the new firmware!

The method C-D is using of supplying brief pertinent Firmware Release Notes is far superior. I think most of us would hate to wait weeks or months for a new capacity or bug fix and then spend the time parsing through a 60 page manual to learn about the changes that apply to the new firmware.

Hi John,

Clearly you must have me mistaken for someone who owns the product which I am not. I am a renter. And as a renter I do not upgrade units. I do not get release notes. And most importantly when I rent equipment I look to the manufacture and their documentation for support not 3rd party independent discussions boards. Clearly my mistake in thinking.

I feel independent sites as this are fine and fun but should not be the primary means of distribution for product information. I am sure on the C-D web site the Release Notes exist somewhere and I blame myself for having not seen them.

As for the manual, my comments were more general comments as to the overall level of quality of the manual on a whole and not to related to any specific issue. However, I would say that had C-D waited until the XDR unit was truly a market ready product, then the constant updates to the firmware etc would be far fewer and then the adding of an addendum or "release notes" would be a much easier task.

If nothing else, given that the only manual I ever see is a PDF downloaded from their site and not a printed manual, then yes I do think the very least a company can do is keep their electronic manual properly up to date

Speaking for the minority of one
David Schmerin

Thanks David that is what I thought. So really there is no way to edit 160Mbp/s I Frame in Final Cut.

Paul,

Absolutely editing 160MB/s I Frame only should be no problem in FCP. The problem is I was unknowingly using CF cards that were actually too slow but gave every indication all was good. I have every confidence that had we used 300x 16G cards, everything would have worked out just fine.

Speaking for a minority of one
David Schmerin

David,

How is XDCAM 50Mbp/s 422 timeline setting going to let you edit 160Mbp/s I Frame? I do not see a setting in FC that will let you edit this setting. Unless there is a options in uncompressed? What am I missing?

Paul,

Whilst there is no setting specifically labelled "160Mbps I-FRAME" in Final Cut Pro, the 160Mbps I-Frame files work fine with an XDCAM HD422 1080i50 (50Mb/s) timeline (or 1080i60, depending on your frame rate).

Final Cut Pro will actually prompt you to change your timeline settings to this if they're set to something else.

David's files did not work with Final Cut Pro as they were corrupted due to not using a card fast enough to record at the 160Mbps bitrate without errors.
Using a Transcend 300x speed card at 160Mbps you will not experience the same problems, the footage will work with FCP.

Paul I understand the card speed problem.

How can a long GOP time line handle I Frame? Does not make sense to me. Same thing with a 1080i timeline?

Dear Paul,

Long GOP has three types of frames, I-Frame and two other types.

When we create I-Frame Only, all of the Frames are I-Frames, we just never create the other two types of frames.

Long GOP handles this fine, it does not miss the other types.

Thanks Dan that straightens it out for me. Learn something daily.

Just out of curiousity, if the "bad" cards still playback inthe XDR, any reason the footage couldn't be captured from the SDI out? In this case it was a backup, but if it had been the only copy, this may be a solution in the future.

Dear Mike,

Yes, that is a good idea. When a user has any problem with a file, we attempt to find a way to recover the data.

If it does play in the Flash XDR, we could easily connect a second Flash XDR to record the signal. In this case, all we actually need is the card since we have two Flash XDR's.

Of course, we do try to let everyone know that the 133x card is not fast enough for the 160 Mbps mode.

We are going to offer a 140 Mbps (or so) mode that will work with the 133x cards. This was Mike Schell's idea and it makes sense to me.

We will also need to lock out the 160 Mbps mode for the slower cards.

Dan that is going to be a nice option at 140 Mbps.

Dear Mike,

Yes, that is a good idea. When a user has any problem with a file, we attempt to find a way to recover the data.

If it does play in the Flash XDR, we could easily connect a second Flash XDR to record the signal. In this case, all we actually need is the card since we have two Flash XDR's.

Of course, we do try to let everyone know that the 133x card is not fast enough for the 160 Mbps mode.

We are going to offer a 140 Mbps (or so) mode that will work with the 133x cards. This was Mike Schell's idea and it makes sense to me.

We will also need to lock out the 160 Mbps mode for the slower cards.

Hi Mike,

Quite agree here in that had we not had tape source, we would have fed the data out the XDR SDI into the Kona card. Because we had the tape source it was better to work from this.

Mike Schell pointed out that in his tests the XDR played back his test material but the XDR had to re-sync every couple of minutes, so who know how much data would be lost.

I think I agree with Dan when he says slower cards should simply be locked out. This would keep slower people like me from even being able to try to use the slower cards.

To the positive for C-D, Dan Keaton, and Mike Schell is that their ability to respond to issues and implement changes is beyond compare in the industry. Clearly you guys listen to feedback and respond; this alone deserves praise. By the time the XDR is actually finished, it will be one solid product.

Speaking for a minority of one
David Schmerin

David:

I like your admission in your signature tag line ("Speaking for a minority of one") because as one of many owners of an XDR, I could not disagree more with your proposal

"However, I would say that had C-D waited until the XDR unit was truly a market ready product, then the constant updates to the firmware etc would be far fewer and then the adding of an addendum or "release notes" would be a much easier task."

Thankfully C-D did not follow this path for 2 major reasons:
1. All of us many users would still be waiting on this marvelous recording solution. We all have been able to use our cameras whose highly compressed recording components severely limited our final output. Thanks to the XDR we have all been recording at a format just under the big daddy HDCAM SR !!! And we've been able to supply 24bit audio without having a separate Fostex FR2 or similar audio unit to record double instead of the 16bit that most cameras record in.

2. The business method C-D has followed has made the XDR a better product than ever envisioned. By having the foresight and investment fortitude to build in and agressively pursue firmware upgrades, we have all been able to appreciate the ability to accomodate all the users' "I wish the XDR had feature XXXXX". Well all these firmware upgrades have been giving us XXXX ! And we have gotten all the added features at no extra cost - but it costs C-D investment in making it happen.

It's the same development model that the acclaimed Red Camera has followed. Both the XDR and the Red have had numerous firmware upgrades since released. But much of the XDR firmware releases were about adding features that incorporated requests by owners as well as some bug fixes. I think one would be hard pressed to find any XDR owner who would complain about the release method of the XDR. I also think the vast majority of XDR owners have long considered it ready for the market. We have been using the XDR to make money and product for many, many months as have others.

The mismatch of 166X Cards to the intended use of the 160 I Frame format would appear to be a miscommunication with the entity rented from. I would hazard a bet that any owner of the XDR that had installed the recent firmware upgrade adding the 160 Iframe format would have this info regarding the need for the 300X cards.

Convergent Design - don't change a thing; keep those added feature firmware upgrades coming.

Oh...

I almost forgot a big cost savings the XDR has provided a long time ago...

To capture and edit the XDCAM HD422 footage that the XDR records, we don't have the enormous cost of purchasing a deck for this format or the cost and hassle of rental of same.

We could use the USB reader that came with the XDR (built into the cost of the XDR), or we could buy a sub $200 Lexar 800 Firewire Reader.

Oh...

And I almost forgot the huge savings in media and the various sources that Compact Flash cards are available.

The XDR IS ready for market. In fact it beats anything on the market at this time and for a long time.

John,

Thank you for your explanation. You pose some very good points. And, if I were an owner I would most assuredly feel as you do. At least I think I would but we seem to have some how strayed off topic. The two key points of 1) The documentation for the unit on the C-D web site needs to be redone and updated, and 2) The system should lock out cards insufficient for the requested application have both been agreed to and accepted by both Mike Schell and Dan Keaton so I figure we are pretty much past that by now.

If you want to try to suggest that the problem with the speed of the cards was a communication issue with the rental house, OK. I still say this does not mitigate a manufacture from keeping their documentation up to date for they (IMHO) should be the leader in providing accurate and up to date product information.

As to the question of "Market Ready" products... I again can well understand your position. I think back to a few months before last year's NAB and remember that the XDR was originally marketed as a .mxf recorder capable of recording up to 160MB/s I-Frame only from an SDI source.

When the Flash XDR began shipping, I think this and many other features were in fact missing from the product despite all the original marketing hype. The subsequent firmware revisions (while exceedingly necessary) from what I can tell are primarily (please note I said primarily and fully accept that new features have been added) give you more of the functions originally promised. So as an owner with product in hand I to would be very excited that every week another feature gets turned on and I get one step closer to a finished product and everything I paid for.

So perhaps this type of marketing works for smaller companies with limited product lines like RED and C-D. I would say that I personally think even C-D sees this product release as a testing environment with an eye for everyone who is now sitting on the side line deciding if they should jump on board for this or the mini version.

And I will say again that C-D's ability to receive and deal with issues shows the true power of the small business in that it is easier to see, understand, and change very quickly based directly on customer and market demands is to praised.

Its good you use the product and its better that you make money with it. It is good you can turn your $6k camera into a much better unit. The thing is that the total number of XDR units sold compared to the number of EX1/3 or VX200 level cameras in the market is miniscule meaning C-D has yet to begin to reach their potential market penetration. This is why I think the product was rushed to market. This is also why C-D needs to be so responsive to their current user base.

When version 2 of the XDR unit comes about and the mini version is finished for C-D to be able to say the units are now all fully functional, field tested and suitable for network use is the prize they have their eye on and can take them from 500 units to early adopters to moving 10,000 of these units.

What I am curious about is this...

As an owner of the product, do you consider things like locking out cards that are too slow or adding a remote trigger to be new features or fixing design flaws? How about adding QT support? Or how about finally adding the .mxf support, new feature or finally getting what you paid for?

Speaking for a minority of one and happy to keep you amused,
David Schmerin

John,

I feel obligated to step in here. We have found, even recently, that the XDR is still not 100% reliable. Recently, using firmware 265 before 275 came out we had several problems with recording and files which would not play back properly. As always we discussed this with CD and were told they were aware of a sync problem. All of our units now have 275 installed.

I am not sure who your clients are, but I know mine are not satisfied with a device which is reliable 99% of the time. I know that David's approach by testing and backing up the XDR with tape is the right way to go for critical, non-repeatable projects at this time.

So far in the last 2 months we have had enough problems with the XDR that on 2 shoots we felt we were not able to charge for the project overall. That has directly resulted in thousands of dollars of loss for our company.

I have had a XDR here from the beginning and now own 8 of them. We developed both the Portabrace case for the XDR as well as a custom laser cut Pelican case. I also am a big fan of how CD has involved the users in developing the XDR. Mike and Tommy have been tremendous resources every time I have called. People who know our company know we often adopt and design cutting edge technology. We commonly bring equipment to the biggest sporting events in the world which is hours old. I am used to equipment which isn't 100%.

I will not quibble with the rollout of features of the XDR. I feel that allowed me to suggest several features which have been adopted in unit. My only concern is it's reliability. And it isn't 100%.

That being said, I think I think the XDR is worth buying and renting at this time. It is one major element of the end of tape as a recording medium and a exciting new addition to our rental inventory.

Jeff

In answer to your questions to me David:
"What I am curious about is this...

As an owner of the product, do you consider things like locking out cards that are too slow or adding a remote trigger to be new features or fixing design flaws? How about adding QT support? Or how about finally adding the .mxf support, new feature or finally getting what you paid for?"

re: locking out cards that are too slow - "new feature" that was never promised; but based upon your experience of using the wrong cards, C-D is able to add that safety feature for you and others as a benefit. Could it possibly introduce a bug - of course. Importance to me - not important. Importance to a renter, first time or occasional user; important.

re: remote trigger addition - new feature made better than originally envisioned because of the C-D method of firmware upgrades to beta units in use - originally when planned, the XDR keyboard was not locked out when setup for remote trigger; beta XDR use found that if the keyboard was not locked during remote triggering, the active keyboard could mistakenly allow a key to change functions while bouncing around in a backpack or on a belt. Could this introduce a bug; of course.

Re: QT support and MXF support - C-D called personally and advised before my purchase and advised that the very first beta XDR units recorded in their proprietary CDV file format and would require something like an AJA or Blackmagic capture card with HD-SDI inputs to edit in an NLE. QT and MXF would come later thru firmware upgrades. I had the choice of accepting this portable compact flash card XDCAM HD422 workflow solution, or stick with HDV compression, or be tethered to a disk drive array/computer/capture card, or spend a hell of lot more to rent or purchase Codex, Stwo, Wafian solutions. Chose the XDR portable solution and haven't regreted for a second. As promised, the QT and MXF formats were added via firmware.

Which brings us back to the inference that C-D promised something that they haven't delivered. From the first day they offered to ship beta units they were very specific about exactly what the XDR could and could not do; what the future feature set would be; and how those features would be added over time. They have been one of the most responsive manufacturers I've ever worked with.

During my usage of the XDR, I have experienced 2 problems - both of which were on my end 1) using a cheapo SDI cable with a defective BNC to coax providing intermittant source signal that corrupted a few files (XDR firmware has even fixed this). 2nd problem - could not get the XDR to find the source from one of our cameras - found camera was last used for live Std Def feed to a switcher and was not changed back over to HD in the camera's menu.

Of course, with Silverman's use of 8 XDR's, he is a great resource for both reliability and feature request info and will defer to his broader usage experience. But the fact that some of his input on feature requests have been incorporated by firmware updates has benefited us all and made the XDR better than originally promised is further evidence of the value of C-D's method of having released the XDR as they have. And again, what would Silverman's choices have been had he not had access to the XDR's? what would his costs have been to get the XDCAM HD422 format?

John,

Don't get me wrong, I am very pleased about being involved with the XDR from the "beginning." I knew what I was getting into, I realized there would be growing pains, and I told the CD people I was ready for the challenge. I believe that almost everyone realizes the same about the XDR.

There is no doubt that the state of the XDR today is that of a very useful product. From a capability standpoint there are few alternatives. The FFV box has not been updated in any sort of a way similar to the XDR.

A good way to describe my caution with the unit is this. Recently we provided a pile of cameras to NBC Heads Up Poker Championship. There were 17 camera sources in NEP's Denali Summit remote truck which each needed to be iso recorded for 3 long days. If I believed that the XDR was ready, the producers from NBC Sports would have trusted my judgment and used 17 XDR's to record the whole show (which I would have rented to them). It would have been a huge advantage for them since all those DVCpro HD tapes will now need to be digitized. (They do a line cut but re-edit the whole thing). I could not recommend that option -- yet, even though I think we're extremely close. We did do a previous show where we generated about 4 terabytes of XDR files and had about 4 terminal CF card corruption failures, about 99% reliability.

I still have a headache from that 1%.

Jeff

Gotcha Jeff.

What a massive undertaking.

Thank you for all your feedback to the guys at C-D. All the rest of us really benefit from your large scale implementation.

There are a lot of us reading who appreciate both of your post.

Jeff:

How are you mounting the XDR to the camera/tripod?

There is a new updated XDR Manual posted on the C-D Website with the new firmware release of today.

It is in PDF format.