Hard drives are a dime a dozen nowadays. At last check, I think Best Buy and Fry’s had them at the checkout counter next to the latest Star Magazine and Chewlies gum. Despite the seemingly over abundance of drives, not all drives (let alone a collection of ‘em) are created equal.

Most hard drives, as I’m sure you know, have spinning platters in them were data resides. While spinning, they allow data to be read and written to them. The faster the platter (spindle) the quicker a computer can read and write the data. So, wouldn’t the same hold true if you connect a bunch of drives (hence the storage geek acronym: JBOD: Just A Bunch of Drives) together? Why yes, you’ve got a point there. More drives = more and faster throughput.

So, a JBOD, with some management software on it, and WHAMMO, you’ve got a large mass of faster, useable storage. Should be pretty cheap, right?

Wrong.

Let’s start at the beginning where this logic falls apart.

All drives are not created equal. Drives are measured in many categories. Some of which include:

RPM (Spindle speed)
Essentially, the faster the better. The faster the rotational speed, the faster the drive can be written and read to, barring no other bottlenecks.

Disk Buffer: (AKA Disk Cache or Cache Buffer)
This is where data is stored on the drive temporarily, before it’s read from or written to the drive. This allows time for the disk to “catch up” if the requests for reading and writing cannot be met immediately. However, it mainly makes the reading to and writing from a drive more efficient and organized. Bigger is usually better (currently, most drives are 8-32MB in size), but there is some debate over the validity to this point. However, since Enterprise drives typically have bigger Cache/Buffers, take the MBs and run.

Interface (SAS, SATA, PATA, IDE, SCSI, TIN CAN AND STRING)
Each drive I/O interface has it’s own quirks and own thresholds, but for our discussion, it’s main limiting factor is how much data the connection allows to flow through it at one time. SATA or SAS are the most common interface nowadays for single drives or small arrays. These interface types typically allow for more throughput than single drive could ever deliver. Thus, a SAS or SATA connection is rarely your bottleneck, until you get into many “striped” drives (an array). Once you get into this realm, we move to other, more robust solutions. However, as we discussed in Part 1 of Choosing the right shared storage solution: Bandwidth & Connections, a fatter pipeline to and from the array may NOT be what you need.

MTBF (Mean Time Between Failure)
Muy importante. The lower the MTBF, the less robust the drive is, compared to others with “enterprise” branding.  This means the drive may fail earlier in its lifetime of expected use, compared to an enterprise-class drive with a higher MTBF. This also comes at a price premium – better parts and more strict QC. If you want the steak, you gotta pay for it, lest you get ground chuck.

Size
The bigger the better, ladies. More storage = more space for your important media professionally-ripped for marketing campaigns, and pr0ntube, err, research.

Shades of Drives

Some manufacturers market their drives into more easily to digest categories, as hard drives can have varying degrees of quality components. Let’s take Western Digital’s drive categorization to better illustrate this. WD hasGreen, Blue, and Black designations. Green drives are usually in the mid to slower side of the the speed pool, and hey also tend to spin at lower RPMs and have smaller disk cache’s. They are called Green because they tend to spin down when not in use. This saves energy, saves money, and saves Gaia. These are usually the least expensive drives. They are horrible for video usage, as how can you playback fat video files if a drives decides to take a nap?

Blue drives are more meant for everyday computing and are commonly found in laptops. They are usually priced around the same, if not slightly more, than Green drives. These are the most common of the HDDs out there, and are mid range on the speed race. Black drives are enterprise class, are usually the fastest, and have the lowest MTBF. They can operate in warmer temperatures (drive arrays can get toasty) and due to these extras, are the most expensive in the bunch. While I use Western Digital as an example, drives with specs which are similar to WD’s Black classification are what you WANT in a mass storage solution. These are not your fathers hard drives, are typically NOT the ones you see in the weekly electronics flyer. You need to seek them out.

As we’ll examine later, determining the right combination of the right hard drives, then building software around them is paramount to decent performance.

Assemble the troops

That was just choosing the drives. That, in and of itself, is a pain. Now, we need a chassis to house the drives. When you buy a shared storage SOLUTION, the solution provider (manufacturer or vendor) has already factored in all of these drives variables and incorporated a drive chassis in order to create a turnkey package *just* for you.

When designing these turnkey solutions of drives and chassis, typically the Manufacturer or Vendor will:

• build or OEM a chassis which holds the drives, and test the aforementioned drives IN the chassis to assure performance is good and constant
• beat up on the drives for failure and performance with various software applications
• systematically write data across the drives equally to ensure sustained performance as the drives fill up.
• design management and sharing software for the user to actually USE the data, and possibly with other users. I will cover this in detail in part 3 of the 3 part shared storage blog.
• write software to poll the drives to check for impending failures (health), as well as optimize the usage of their buffer(s)
• last but most critical, protect the data (using RAID or better technology)

These solutions, if done right, relay on a battle tested combination of hardware components. Off the shelf components, put together because the cables fit, will never deliver the performance a tuned system can. This is yet another reason why consulting a shared storage systems integrator or consultant assures you’re getting a best of breed solution – not product scattershot.  I’m serious about this and I can’t stress this point enough.

I know, this is fun, right? Are you not entertained?!

We now move on to yet another acronym: RAID.

RAID, RAID, RAID. Oh how you complicate thee.

A RAID is an Redundant Array of Independent Disks. Take this scenario: suppose a drive fails (MTBF) once in 1 million uses. We don’t know *when* it will happen, we just know it probably will – and before 1 million uses. Where this happens is up to chance, environment, and usage. Now, let’s say we RAID two drives together as one, because that would yield twice as much space and speed. This obviously increases the risk of MTBF. Plus, if ONE (yes, ONE) drive starts to smoke – you’ve lost all of your data, because you spanned the disks together. You can’t edit with half of every bit and byte gone. Given this truth, now multiply this by 4 drives. Howabout 16 drives or more? Russian Roulette, geek-style. Combining drives in this manner is known as RAID 0, the largest combination of throughput and capacity, but absolutely no support for preserving data if one drive dies. This absolutely bites when it comes to DATA AVAILABILITY.

The loss of one drive in a RAID 0 array could be a massive problem for the video editor (you just lost the entire movie, no problem… right?!?).  Since this is not acceptable in most circumstances, other RAID data-protection and performance formats have been developed that ensure there is some REDUNDANT distribution of data across multiple disks. (Ah yes, the R in RAID!) While there are as many as the day is long, let’s examine those you will probably find out in the wild when dealing with video shared storage solutions:

RAID 1: If RAID 0 doubles your storage, then conversely, RAID 1 cuts the cumulative size in half. Why? RAID 1 (AKA “mirroring”) allows that in the event of the rapture and half of all of the drives in your array blow chunks, that you don’t lose any of your data, because a 1:1 copy of the data has been made on that extra storage. This can cause a slight hit in throughput (after all, your data is being written twice), and as outlined, a massive hit in storage space. Those of you who have used Avid’s Unity (not ISIS) have used RAID 0 or RAID 1 for years – it’s all Unity supported. Most other shared storage solutions also offer RAID 0 or RAID 1 as well.

RAID 2, 3, & 4. Outdated, or yielded unnecessary by RAID 5. Move along. BTW, what ever happened to Leonard Parts 1-5?

RAID 5: Probably the most popular out there. It balances throughput and redundancy, with minimal overhead. This achieved through parity. (Warning! Higher geek content: When data is written, parity data is introduced and written with your video data across the drives. In the event a drive fails, this parity data is combined with existing media to recreate the lost media for your enjoyment. As one can imagine, this decreases performance slightly: not only while the initial parity data is created and written, but if a drive dies, the array needs to recreate the media for usage in real time.) All this being said, RAID 5 allows for the speed benefit afforded by a RAID, along with good redundancy. As a bonus, if a drive dies, most shared storage chassis can rebuild the lost media once a correct drive is inserted into the chassis to replace the dead drive – restoring your array to it’s former glory.  Just give it until tomorrow, it usually takes a bit of time and you will see a modest performance hit during the rebuild process. But hey, it’s not gone!

RAID 6: Very similar to RAID 5, although the user has one more guard at the gate: 2 drives worth of parity are written, instead of 1.  If a drive does die, there remains 1 drive still spinning and keeping the array functional.  Same basic performance and storage hits as RAID 5.  RAID 6 is slightly less common when seeking out Video RAIDs.

I usually ballpark a 12-20% hit on storage space AND throughput for your shared storage solution to handle a RAID5. This varies by manufacturer, but the 12-20% plays heavily into my storage formula at the end of this article. I know;  no one wants to lose space, but it’s better than losing half of your space with RAID1 or having no redundancy, a la RAID 0.

Other less popular RAID formats include RAID 6, RAID 0+1, RAID1+0 (AKA RAID 10), RAID 0+3, RAID 3+0, etc. Consult your local storage geek if you *realllllly* want to delve into these.

It should be noted that a RAIDSET can be done at either the hardware level, or the software level. In Windows or on OS X, for example, you can RAID drives (usually RAID 0 or 1, rarely RAID 5) from within the OS. (Manage–>Storage and Disk Utility, respectively) This is a software RAID, and while it works, it’s usually not as fast or bullet-proof as a hardware RAID 0 or 1, which (if available) is done on the chassis which contains your drives.  Most hardware RAID controllers are designed specifically for RAID 1, 5 and 6. Hardware RAID is faster than software RAID for managing the layout of data and parity bits.

Now for my patent pending formula.

Let’s take a 1 TB drive. Small, and easy on my math challenged brain.

As you probably know, marketing 1TB is not equal to 1TB useable storage. This hard drive loss is due to base 2 math rather than base 8. (1000 bytes = 1 kilobyte marketing, 1024 bytes = 1 kilobyte in reality) (Editor’s note: Thanks Micheal!) Thus, when you begin to multiply bits, bytes, kilobytes, megabytes, gigabytes, etc…you end up with less than 1TB. And of course, marketing wins: 1TB is easier to sell than 930GB. So, we’re saddled with a 7% loss. Keep that number written down.

We now need to initialize the drives, and format them into a RAID. Let’s say we go with RAID 5. Best balance of speed and redundancy. RAID 5 in hardware can be between 12-20% in loss of space due to the aforementioned redundancy. Again, this is different for each manufacturer, so no need for the math hate mail. Let’s use 15%, and subtract that from 930GB. This comes out to approx. 790GB. So, now we’re down 210GB from the advertised size.

As I mentioned earlier, performance (throughput, in this case) can decrease as the drive fills up, if the data is written sequentially on the disc(s). Think of trying to pull a toy from the bottom of a box of cereal: it’s tougher to get to when the box is full of cereal than when it’s empty. Some shared storage manufacturers (Facilis comes to mind) scatters the data around the drive, so a user never sees a performance hit; as performance is equal regardless of the amount of free space. That’s in the minority, so the magic number before a noticeable loss in throughput seems to be around 80%. Thus, we subtract another 20% from the 790GB. This comes out to 632GB.

That’s right. Of that shiny new 1TB drive, once introduced into a RAID 5 RAIDSET, and given some room for performance, we have nearly a 40% space loss.

So concludes Part 2 of our 3 part series.  Stay tuned for Part 3: Management, Permissions & Support.  Same bat time, same bat channel.

Special Thanks: David Sallak of Isilon.

In part 1 of 3 part posting, I’m going to examine shared storage for video – SAN & NAS.

Many factors go into choosing the correct shared storage solution:

1. Bandwidth & Connections
2. Drives: Size, Spindles & Protection (RAID)
3. Management, Permissions & Support

In this post, we’ll examine #1: Connections and Bandwidth.

Before we jump into the geeky goodness, let’s make sure we’re all following the same nomenclature.

1. SAN: Storage Area Network. Based on Fibre topology.
2. NAS: Network Attached Storage. Based on Ethernet topology.

Currently, there exists 2 main methods of connecting many computers to the same storage: Ethernet and Fibre. A good rule of thumb is if it’s Fibre, it’s a SAN, and if it’s Ethernet, it’s a NAS. While there are a few exceptions, this guideline is true a majority of the time. I humbly await the flames…

The endgame is that BOTH (when configured and deployed correctly) can be run long distances, are somewhat flexible, and most importantly, can be used for mass storage in the video realm. The big difference to the end user is bandwidth.

Bandwidth – also known as throughput – is the amount of constant data your computer can sustain to and from storage, and is paramount for video playback. Too little bandwidth – or poor sustained bandwidth – causes your video to stutter or downright refuse to play.

When it comes to bandwidth, the video industry is actually in an excellent place right now. Acquisition codecs, like h.264 (Canon 5D, 7D), XDCAM, and P2, take up a small amount of bandwidth, while still delivering decent quality. Let’s look at Standard Definition (SD) video from 10 years ago. Many broadcast networks would play material to air that had been onlined at 1:1 uncompressed or frequently 2:1. The video datarate of SD at 1:1 is 22 megabytes (MB) per second. The current broadcast quality HD Avid codec (DNxHD 145) is actually less, clocking in at about 18MB/s. Heck, even DNxHD 220x (the least amount of compression before going uncompressed in the Avid realm) is only about 27 MB/s. Thus, we can take advantage of the drops in storage pricing, advancement of computing power and still use the same bandwidth we were using back in the SD days.

Below is a quick list of current Ethernet and Fibre transmission speeds.

Connection	Throughput	20% Real World
4GB Fibre	425MB/s	~340 MB/s
8GB Fibre	850 MB/s	~680MB/s
1 Gig Ethernet	125 MB/s	~100 MB/s
10Gig Ethernet	1250 MB/s	~1000 MB/s

The smart reader has noticed that real world throughput differs from theoretical throughput. For example, Ethernet typically has more overhead (read: less bandwidth) than Fibre, but neither typically perform as fast as the theoretical speed. Kind of like that bag of life-shortening potato chips you picked up at the grocery store. It’s a bag of chips, yes, but is it ever really filled to the top?

Personally, I normally ballpark 10-30% off of theoretical for a more real world ballpark estimation. ALL shared storage solutions are a little bit different. However, for sake of discussion, and to be safe when planning your facility, let’s say 20%.

In addition, all of these connections inherently have the ability to be bonded, that is, the aggregate speed of multiple connections yield more throughput. This, of course, is based on the SAN or NAS, the switch, and the Fibre or Ethernet card in your system supporting it. Never assume any of them handle aggregation– verify. If they do, then you now have an opportunity to potentially double your available bandwidth. This is a very good thing.

Now that we know how wide our highway is, let’s see how many cars we can fit on it. Here is a short list of some of the most popular codecs at their highest data rates.

Codec (at 1080i/60)	Speed (Mb/s & MB/s)
AVCHD	24 Mb/s (3 MB/s)
HDV	25Mb/s (3.125 MB/s)
Canon7D (h.264) (1080p)	48 Mb/s (6MB/s)
XDCAM HD 50	50Mb/s (6.25 MB/s)
AVC-Intra (100)	100 Mb/s (12.5 MB/s)
DVCPro HD	115 Mb/s (14.4 MB/s)
DNxHD 145	145 Mb/s (18.125 MB/s)
ProRes 422 (HD)	167 Mb/s (20.82 MB/s)
REDCODE 42	336 Mb/s (42 MB/s)
Uncompressed 10-bit RGB	1990.24Mb/s (248.78 MB/s)

For you non-math majors (don’t worry, I’m not one, either) you’ll notice some big number discrepancy. Here’s why:

Apparently, not everyone got the memo on standardizing measuring practices. So much so, that codec data rates are typically measured in MegaBITS (often written as Mb/s, Mbit/s, or Mbps), while storage is usually calculated in MegaBYTES (MB/s), GigaBYTES (GB/s), TeraBYTES, (TB/s) etc. This makes calculating storage somewhat of a headache. A tip? Divide the codec data rate by 8. (A byte contains 8 bits). Thus, a codec running at 48 Mb/s = 6MB/s. Genius.

So, let’s now match up our cars (codecs) against our highway (throughput). Below we see codecs vs bandwidth (remember, bandwidth calculated at 20% less than theoretical max, which is a better approximation of real-world performance):



Codecs and Bandwidth Comparison

So, what does this mean?

Clearly, most codecs can easily fit through the pipeline 1GigE provides. Fibre becomes the obvious solution when uncompressed codecs (or similiar) come into play. Thus, for most video-centric applications, an Ethernet connected solution – single or bonded (even better) – can handle the job.

I would add that not all Ethernet solutions are created equal. Sustained throughput is the name of the game, and off-the-shelf or I.T. centric solutions almost never handle video properly. A Pinto can get onto a race track, doesn’t mean it performs well, ya know?

In closing for the 1st entry in the 3 part series, (1 for 3 may be good in baseball, but not in Post, and certainly not when choosing a shared storage system) I cannot stress enough that if you’re considering a SAN or NAS, consult a Video Shared Storage specialist. SAN and NAS solutions are not at the point where they are plug and play.

Yet.

Be on the look out for part 2: Drives: Size, Spindles & Protection (RAID).

Special Thanks: David Sallak of Isilon, Pat Howley of Key Code Media.

Matt Stratton turned me on to Clicky Stats awhile ago, and through Clicky, I’m able to see what web searches come up with my blog as a result. I also see when these searches lead them to my blog – but then they leave because they didn’t find the answer. I thought since the search engines think I already have it on my site, perhaps I should.   Below is a sampling of the search queries that my website supposedly already has the answers for.  So, I present to you:

It came from the Searches, Volume 1.

dnx-36 firewire 400 and bandwidth requirements DNX36
Yes, DNxHD36  (aka DNx36) can certainly work through a firewire400 pipe. DNxHD36 runs at a 36mbps, while firewire400 has a theoretical max of 400mbps. This makes firewire400 a fine choice as a transport for DNx36 offline workflows.

29.97 and dnx36
This is a source of confusion for many Avid users, and I’m in the process of authoring a blog on this. DNxHD36 is a “family” according to Avid. While the “36″ label refers to the data rate for 23.976 material, the DNxHD36 “family” codec can be applied to 29.97 material. This would be technically known as DNxHD45 (45mbps as opposed to 36mbps).

“episode engine” cpu restriction
This is kind of vague. Within Episode, you can assign priority of encodes and cpu usage. Quicktime already is pretty poor with processor usage to begin with, however.

Metafuze Lossy?
Yes. After all, you’re transcoding from one codec to another – there will always be quality loss. In addition, DNxHD is a lossy codec – so, yes.

edit room day rate
This varies wildly. Depends what gear is in the room, what the room is used for (editorial, audio, finishing, color, etc.) your experience, and geographical location – and hell, what your rent is! Normally a reputable rental rate at a good facility would be a couple hundred bucks per hour or even much more.   As a side note / soap box,  don’t sell out the rest of the industry by undercutting other facilities.  Talent and experience are worth the money.  That’s a majority of what the client is paying for – not the gear.  By undercutting everyone else, the industry is forced to adopt your lower rate as a standard, then everyone has to drop their prices.  And the cycle continues. You’re shooting yourself in the foot.

Does clipster support facilis
Clipster runs on Windows XP 64bit, which Facilis has a client for. Fibre is the best choice (Ethernet won’t deliver the bandwidth needed), and it should be a recent version of Facilis software to enable file locking – volume locking will cause organization issues, but can be done.

convert red footage cluster setup
I wish I could do it better than these guys have:
http://www.kenstone.net/fcp_homepage/compressor_multi_cores_stitzer.html
http://www.fcsoutlet.com/home/Studio_Outlet/Entries/2008/9/1_Virtual_Clusters_-_Compressor.html

fcserver script
Good luck. Most everything is manual at this point. Try CATDV as a more GUI based alternative.

QIO-PCIE sonnet tech
The QIO comes with either a PCIE host card or a E34 (Express slot) host card. Unveiled at NAB 2009, and finally shipping now! Mac only support for now. List Price is about $1000.

FTP, KiPro
Well, once the KiPro encodes to ProRes, you can certainly FTP the file – although it’s gonna be huge. Your best bet is to offload it to a portable drive for transport or use a transfer solution like StorageDNA.

share msm database avid
I can only assume you’d like two or more machines to access the same Avid Database at the same time, in order to share media. Nope – the functionality you are attempting to do is achieved through Avid Unity, ISIS, and Interplay.

final cut server frontend
Final Cut Server (FCSvr) clients have a front-end based in Java; it looks the same on Mac or PC – and the administrator can restrict what functions a client can have. A popular alternative is creating a web page interface which ties into the database and media of FCSvr. The functions on thew web page are usually limited and typically only used for “review and approval” functionality. Several companies out there can create a custom web based interface – although it is far from cheap.

episode pro pro res 422
Yes, If Episode is running on a Mac, you can encode and decode into any of the flavors of “ProRes” (1 word). Decoding is only available (currently) on the Windows version.

How can I get edits which need review out to non tech savvy producers for approval so they can:
A) easily view the edit (did I mention easily?)
B) stay out of the edit room.

Of course, sometimes A) means burning a DVD or laying off a tape, which is time consuming, not secure, and let’s face it, decidedly not green.  It also can eliminate FTPing a file to a server to then be downloaded and watched as a viable solution, as sometimes this walking and talking at the same time complication can cause more time in tech support than just letting them in the edit room, which violates B).

Aside from my column and proposed workflows with Final Cut Server, I have something even simpler…and in 2 flavors.

Scenario 1:  Small scale.

What you need:

Your Edit Bay NLE
Generic Computer (Mac, most likely)
AppleTV with Video Monitor (HDMI)
Extras: Encoding solution, Shared storage, same LAN access.

Procedure:  Editor exports a full QuickTime file in the appropriate H.264 format for AppleTV, to a shared network drive.  AppleTV runs off of iTunes, so your generic computer picks up the H.264 file, which sync (or streams) to your AppleTV.  Now, the producer can view the cut in the comfort of the plush couch of his 4 wall, and not in the edit room.  This can be streamlined even further by having the editor export a QT Reference to a watch folder, which the encoding solution would pickup (make sure all volumes containing the referenced media can be seen by the encoder) and proceed with the H.264 encode, then sending the file to the generic computer running iTunes.  Having all of the satellite AppleTVs stream from the 1 machine makes media management very easy.

Limitations?

5 AppleTVs can sync to 1 iTunes Library.
1 AppleTV can stream from up to 5 computers.
AppleTV is specific in what formats it will play.

Scenario 2:  Larger Scale

What you need:
Your Edit Bay NLE
Several Mac Minis with DVI to HDMI cables (for a Plasma / LCD display), Apple Remote.
Extras: Encoding solution, Shared storage, same LAN access.

Same concept applies: Editor exports a QT or QT reference, and either the 3rd party encoding solution delivers the file to a shared network drive, or the NLE does.

Here is where the Mac Mini comes into play.

OS access is a no-no for a 2 year old.  And for Producers – for the same reason.  So, here is what I did:

Parental Controls Preference Pane (Click to Enlarge)

Create an admin account on the Mac Mini.  While in this account, create a new user (“Producer”), and enable Parental Controls on the account.  In Parental Controls on the Producer account, activate “Use Simple Finder” and “Only allow selected applications”.  In this box, select the application Front Row.  Make other changes at your discretion, but these are the biggies.  This will ensure that this user has limited access to OS functions and can only run Front Row.

Now, we need a way to have the Mac Mini see the shared / network drive without user intervention.  Automator is an easy way to accomplish this.

Open Automator.  Create a workflow that:

Gets Specified Servers and make sure to put the username and password in the URL; i.e.: afp://username:password@192.168.1.1/DRIVE_FOLDER_WITH_ENCODED_MEDIA

Add a “Connect to Servers” Action.

You can download the workflow here: producer_automount.

Automator Network Share Mount Workflow (Click to Enlarge)

Save this as an Application.

Run this to test.  Does it work?  Great!

Now, create an Alias to this shared / network drive.  Place this alias in the Movies folder on your Producer account.  This allows Front Row to see movies located on the shared / network volume.  You can change the name of the alias if you wish to something a bit more verbose.

Place the Automator Application you’ve created in the Login Items under the Producer account.  Also, add Front Row.  Set the system to auto boot into the Producer account.  In System Preferences, disable any Bluetooth keyboard / mouse options – so the Mac doesn’t look for Bluetooth devices.  If this is not disabled, the Mac will look for devices on bootup, potentially stalling the launching of the Automator Application and Front Row.  Reboot.  As the system is rebooting, disconnect your keyboard, mouse, and make sure you have your Apple Remote handy.

When the computer reboots, it will boot into the Producer account, auto mount the network volume which has the media you want them to see, then launches Front Row.

Now, using the Apple Remote, navigate through Front Row, and through the MOVIES section.  Because we placed an alias to the network drive (which the computer is connected to via our Automator script), Front Row can now see that drive.

Success!

Now, you have the ability to play back ANY file format QT can play back, from an unlimited number of machines AND restrict access to what clips can be seen by mounting different network shares though Automator.

As an added bonus, if the Producer decides to think outside the proverbial box, and hit the MENU key on the remote while at the Front Row main menu – it will take them to the OS desktop.  Surprise!  No keyboard and no mouse make tampering very difficult, PLUS you’ve already locked out OS functions with Parental Controls.  All they can do is turn the Mac Mini volume up and down…. and simply hitting the MENU button relaunches Front Row.

Success! Easy edit review with a nice Apple sheen.

Among the goodies:

Final Cut Studio 3: Increased RED support (confirmed), as well as no support for blu-ray within DVD Studio Pro. I am unsure if this means no authoring ability or the user not being able to even build a project.

Avid: Specs for Nehalem support. This is, of course, unofficial.

Nehalem Mac Pro

OS 10.5.6

2.66 or 2.93 Quad

Core Intel Xeon processors (8-core)

6BG of 1066 DDR3 ECC SDRAM

NVIDIA GeForce GT 120 512MB**

640GB 7200-rpm SATA 3Gb/s

**It should be mentioned that I did not see any Mini Display Port extenders on the NAB show floor, which make any Nehalem Mac install extraordinarily difficult.  One can, of course, convert to DVI, as a fallback.

More as they trickle in.

• Launch Metafuze on a PC. (comes with the Avid installer, or download here.)
• Import the Left Eye & Right Eye (in that order) Folders. Avid calls this scanning. These will have unique file names, but the numeric values in each file name will match Left Eye & Right Eye files, and must have the same file format (size & resolution) and same duration.
• Highlight a Left Eye file AND a Right Eye file. On the right window pane there are transcoding options. Select your flavor of DNxHD, and Click the Create Stereo Group button.
• You now have Avid appropriate (OP1a) MXF wrapped video files which can be loaded into Avid (without Avid having to re-wrap the file). Utilizing the Stereoscopic settings in Avid, you can now view Left Eye or Right Eye only, over/under, or checkerboard. Remember, you can only view your 3D playout correctly via the DVI port on your computer – not via the baseband video output on your Mojo or Nitris DX. Don’t forget your IR 3D glasses and 3D capable display!

Here is what is going on with your media, as you work within the Avid:

• Almost everything you are doing in Avid (from launching the Avid, saving any bins, leaving capture mode, or closing the application ) is causing the system to read and write data to your media drives simultaneously.
• Each partition will have one OMFI MediaFiles Folder and/or one Avid Media Files Folder (for MXF media).
• Each media files folder contains two database files (msm.MMOB and msm.FMID) which keep track of all of the changes to media files; keeping them constantly linked to the master clips in your bins (pointer files living on another drive in your applications folder).
• Every time you launch the Avid, save any bins, leave capture mode, or close the application it is forcing those database files to index all of the files in that media files folder.
• By having 2 database files on one very large partition containing 500GB 1 TB, etc of media , the Avid is indexing the hundreds of thousands of files included on that partition . That, in turn, taxes the database files beyond a reasonable level and they begin to either lose track of media, or fail to complete their updates.
• Media Databases no longer update correctly, causing things like “OMFI HP Domain INIT Failed” errors as well as ‘Media OffLine” messages, among others.
• By creating more, yet smaller Drive Partitions, the Avid can more efficiently and reliably maintain its Media Database files, giving overall stability and speed back to the system.

Avid Customer Support has found that partitioning down larger striped sets to sizes of approximately 250-300 GB has TREMENDOUSLY helped overall performance and stability. We recommend this for systems setup with larger than 300 GB partitions, in use with a 12 or 24 way stripe.

A note about Windows File Limit:

The Windows OS starts to slow down after 10,000 files. This is a limitation of the OS itself, not of the Avid. After 10,000 files, the system cannot buffer it’s file count fast enough, as well as the Avid’s Media Databases also not updating correctly, if at all.

More info available at:  http://avidtechnology.custhelp.com/cgi-bin/avidtechnology.cfg/php/enduser/std_adp.php?p_faqid=71457