[Dave Haynie]

You can’t balance things that aren’t similar enough. A good example is shooting a musical performance — you may have clips of music, clips of speakers, etc… they’re going to be at drastically different volume levels.

You probably want to compress speech, but you definitely don’t want to just randomly apply compression to music. The former is generally informational, the latter… is music. It’s supposed to be dynamic.

Even if I’m just using a mic or two, I will ALWAYS split up different kinds of audio into different tracks. So in a typical musical performance, I’ll have an voice track and at least left and right music tracks, even if I’m just using a single set of mics. I always want to be able to mix the voice to the center channel, if there’s the option of a 5.1 audio output… and I’ll think in those terms, anyway. That’ll be a mono voice mix… and I’m talking about things like announcements in-between music sections.

It should be obvious that with other kinds of speech, like dramatic speech, theater, etc. you don’t want much if any compress, and you’re going to keep the stereo mix. You’d be dealing with speakers who are using their vocal modulation for an intended effect, not just those who might not be careful about their vocal levels when making announcements (or whatever). And of course, if a normalized speech track sounds clean, you may not want the compression — it’s just fairly typical that light to moderate compression is a good treatment for speech.

Normalization is also necessary, or at least very useful. I would typically do RMS normalization of voice at around -10dB and music at around -16dB, but it going to depend a bit on the content. Using RMS normalization (not built-in to Vegas, but available in Sound Forge) means you’re not having your normalization thrown off by the odd noise or other unusual sound. So -10dB always sounds like -10dB.

You can get into trouble with compression either pre or post normalization, if you don’t know what you’re doing. Most of the plug-ins use compression curves that assume you’ve already normalized the content, and most automatically provide some make-up gain, so the output will have about the same levels as the input. If you’re not well versed in applying compression, it’ll be easier to normalize then compress. Knowing what I’m doing relative to these, I usually do it the other way around.

-Dave

[Dave Haynie]

[Roger Alexander] “I guess I am confused. Am I correct in thinking that access time is the indicator to how smoothly a large file will work/play inside of an editor?

“Access time” is kind of a nebulous thing. In order to get a bit of a file loaded, you have to get your drive to where that file is on the disc (seek time) and then load it into your NLE (transfer speed). RAID will improve your transfer speed. It will actually make your seek time worse — when seeking for any RAID sector, it’s the slowest of N drives for that seek that determines the aggregate seek time. Of course, within a file, you’re doing far fewer seeks — each track is N times larger.

SSD improves things in general, both in seek time and transfer speed. There’s no physical seeking, so moving to a new block is always the same speed, and dramatically faster than an electromagnetic drive.

But an SSD RAID isn’t necessarily cheap, and isn’t necessarily what you need — it depends on what you’re working with. I have a single SSD for my boot drive and a four-drive RAID10 for my data drive… so I get a factor-of-four (ish) boost on transfers, making the RAID read/write at about half the speed of the SSD, as benchmarked (forget which tool I used — I did some measurements when the system was new last summer).

But how much do you really need? I get about 250MB/s from the RAID and about 500MB/s from the SSD. My typical video files range from 25Mb/s HMC-40 AVC files to 90Mb/s Canon 6D AVC-Intra files. I might get a bit larger using intermediate file (usually MXF MPEG-2), more like 100Mb/s, which is about what I had for Cineform back when I used it. So that RAID could handle 20 of these files in realtime without seeking, probably more like 10 in real life/realtime. If I used every HD-compatible I have, I could have six streams at once. Realistically, a drive 10x faster would not do much for me, far as video access goes.

It’s a bit different for animation… which I do occasionally. I might have 20-40 different video files, all uncompressed (because “Alpha Channel”). But I’m only doing a 2-5 minute animation…so even with uncompressed file, it’s not a crazy amount of storage. If I did enough of this, I might think about an SSD RAID, that would have a noticeable improvement on editing speed, because there’s simply no way my existing RAID can load up a whole animation in realtime. On the other hand, having enough RAM (64GB) also solves that problem, since a whole project may actually fit in RAM.

[Roger Alexander] ”
What is the SSD RAID going to improve in editing if it is not access time? RAID 0 seems to only affect transfer rates. How is that going to help me with editing? Am I missing something here?”

If seek + access adds up to enough time, you notice the delay when editing. If it doesn’t, you don’t.

Looking at the 4K cameras I’m currently drooling over, er, thinking I could actually afford, I see AVC at between 60Mb/s and 100Mb/s… really nothing I’m not already doing. On the other hand, my CPU is going to need 4x the time to decode 4K AVC versus HD AVC… quite a bit more, yet, if you’re comparing MXF MPEG-2 or AVC-Intra files.

In short, with limited funds, I personally make the choice to spend more on the CPU (six core i7-3930K) rather than the RAID. And I also wanted the reliability of RAID10 vs. RAID0. Now, you could argue that SSD is more reliable than HDD… but that’s actually not the case. Rather, SSD and HDD have different aging mechanisms. HDDs basically last a fixed amount of time, with little aging due to use. SSDs are more likely to last for a certain amount of use, no matter how long that takes (within some limits — electronic components also fail in a secondary mode, due to thermal stress, electromigration, etc. unless they’re kept very cool).

There’s also the question of how you’re connecting your SSD RAID. Given that a single SSD can use up most of a SATA 6GB/s link, you’re not going to “about double” performance with 2+ drives on an eSATA box. In-the-box “soft” RAID0 may actually go faster…. in fact, Tom’s Hardware just did an article on exactly this option: https://www.tomshardware.com/reviews/ssd-raid-benchmark,3485.html.

Put it on PCIe rather than SATA, faster still. But that can get crazy, and expensive. So figure out what you need first.

-Dave

[Dave Haynie]

The hybrid 7200rpm drive is still a 7200rpm drive… just pointing out that the “hybrid” SSD part isn’t terribly useful for a data drive, since it’s never large enough for media files. I first bought a hybrid drive for the PC I built for my son two years ago, and there was a premium for those… and SSDs were kind of out of sight. Last summer, I built myself a new PC, and included a 960GB SSD… prices have been dropping. The 750GB hybrid in my office PC wasn’t much of a difference in cost over a plain HDD, and for a C: drive it’s quite nice.

Anyway, you want the 7200 over the 5400, no contest there.

-Dave

[Dave Haynie]

[Chris Newberry] “y only problem with DLSR’s is the lack of XLR/decent sound recording options”

Practically everyone using DSLRs for video are getting good results with auxiliary recorders. I have a Zoom H4n — kind of the go-to standard these days, though not when I bought it — and it’s just dandy for DSLR video. You can hook in two XLR mics, record to 24-bit uncompressed audio, and feed the output to the camera’s 1/8″ jack if you need to. It’s been awhile since I counted on on-camera audio for much more than sync, anyway, for any serious video work.

[Chris Newberry] ” I hear about a lot of issues if you do a lot of run and gun filming i.e auto focus, handheld isn’t really an option etc”

Actually, pretty much all of the m43 cameras do video autofocus as well as any camcorder. The DSLRs, largely, do not… aside from the Canon 70D and some of the mirrorless models from Sony.

But yeah, the workflow is different, and I’d honestly still grab my HMC40 with two XLR mics (at different gain levels) mounted on it for any “run and gun” type shooting.

The other major issue with most true DSLRs (Sony, Canon) is that they’re still locked to the European tax avoidance limit of 29’59” continuous shooting. Even for USA models. They used to blame these limitations on sensor heating, then on file size limitations, but it’s clearly now just a malfeature of many of these. Of course, you don’t find these limits on Canon or Sony’s dedicated — and much more expensive — camcorders (EOS C, etc).

Panasonic seems to have dispensed this limit. The m43 format is the only one I’d consider other than full DSLR… I love my Canon system, but I can fit an Olympus body and 5 very good lenses in the space of the 6D and one normal-zoom… and it weighs less. There’s lots of motion here for video, too: Panasonic GH4, Blackmagic Pocket Cinema Camera, JVC’s new m43 camcorders, etc. And about twice the native lens selection of any other mirrorless line. I don’t have a video m43 body yet, but I started with a small Olympus some years back, as a secondary camera system, but also because even then m43 looked like it would be a very interesting ecosystem for video.

-Dave

[Dave Haynie]

[Norman Black] “he whole 4K thing and internet delivery seems hype to me. I download some 4K samples showcased by Youtube and they do not even, or barely deliver Blu-ray HD bitrates and they have four times the pixels.”

Blu-ray is certainly capable of way higher bitrates than many camcorders, much less online. That doesn’t mean that every video necessarily benefits from a higher bitrate. And of course, once you’re using a different CODEC, all bets are off.

That said, I haven’t been terribly impressed with the state of HD video on streaming services… and in fact, I’m kind of in the Groucho camp on this one… I’m probably not happy with any video streaming at 4K that would work for me as a viewing client.

That said, Netflix claims they’re happy with 4K at 15Mb/s, and Red’s own RedRay player claims to deliver 4K they’re happy with at 20Mb/s (and that’s peak.. some material was shown at 10Mb/s)… and that’s a dedicated media player, not a streaming format. Both use new CODECs… Netflix with H.265/HEVC and Red with their proprietary tech.

It’s true that as you increase resolution, you need fewer bits per pixel… just as ATSC video was about twice the DVD rate for six times the information… and that’s only if the broadcaster isn’t transmitting additional SD channels on the same channel/stream. Cable (Comcast) has been dropping HD MPEG-2 down to as low as ~10Mb/s… few transmit at the original format received. Comcast has also been caught downrezzing… to 1440×1080 or even 1280×1080. Both of the satellite companies are AVC-only these days, and have also been known to downrez. And Netflix’s “SuperHD” runs at around 5.8Mb/s peak (there are lower bitrate HD streams), for a 1080p24 video stream.

So, while I’m not about to say this is proper behavior, or that I like it (I don’t get cable or use Netflix, I like Blu-ray), I’ll claim that these things are establishing a level of consumer tolerance for crappy video. Just as VHS and DVD once did, in their own ways. Or TiVo. Your brain actually does adjust. In the early days of MPEG-1 video, I was watching way to much of it, and I noticed at one point I was filtering out the really bad stuff… you find it again if you’re pixel-peeping rather than just watching a show. I also noticed that I lost that for analog over time… a few years back, I captured all of my 8mm material, just in case my lone D8 camcorder died… I was kind of surprised, after a decade of HD and two of digital, just how bad that format had been.

So you get someone relatively happy with HD at 6Mb/s, and show them 4K at 15Mb/s with VP9 or H.265 or some other more efficient CODEC, and they’re going to be blown away, on the right screen anyway. I’ve seen some qHD (2560×1440) streams on my desktop (I have two monitors at that resolution, one 12″ tablet at 2560×1600), and it looks damn good, from a viewer’s perspective. Not editing it, not comparing that to an original source file shot at 50-200Mb/s either.

-Dave

[Dave Haynie]

MC doesn’t provide all the CODECs for Vegas — in fact, Sony has their own AVC encoder, of course, in addition to the MC version. And MC has at best proven a poor partner, given the corporate shuffle they’ve been through and the fact that MC isn’t supporting GPGPL coding properly, or any GPU introduced after about 2010.

As for CinemaDNG itself, it’s hard to guess if SCS will consider it important enough to support. Adobe dropped official support of it last year, ironically just about the time that a bunch of Cinema-style cameras adopted it as their format-of-choice. There is a CinemaDNG SIG: https://www.cinema-dng.com, which will presumably track happenings in this area.

It’s also important to understand the size ramifications.. you’re talking about 5GB per minute of CinemaDNG for ~2K video. That adds up fast. The Digital Bolex people are suggesting a workflow that keeps the CinemaDNG files around as long as possible, to the extent they’re building a tool that’s basically Lightroom for video, so you can do all kinds of stuff (color grading, etc) non-destructively on CinemaDNG files before doing a one-time transcoding to some editable format.

They’re not only assuming that NLEs won’t likely support CinemaDNG import, but dealing with the truth that even if they did, they’re not currently able to do “raw” things. I’ve run into this myself. I’ve done some time-lapse shooting with my Canons, which get me a series of Canon RAW files, basically 5K video. Using Vegas’ support of the Microsoft RAW still photo CODEC, I can import a whole series of these directly into Vegas. But I don’t have any of the RAW controls I’m used to from Lightroom or the Photoshop Camera RAW importer… I’m not really sure what Vegas actually gets from the output of the RAW converter. So I’m probably going to make RAW adjustments in Lightroom anyway (not the best tool, just the only tool for the job), export that sequence, and then edit that in Vegas… that’s what has worked. So maybe the Digital Bolex people are correct on this — just as a big chunk of Lightroom began life as Pixmantec’s “RawShooter” — a program just for RAW photo manipulation — we may need a similar thing for RAW video to get the best results.

That said, I understand the need for better solutions today. I’m just not sure SCS will have any skin in this game. And they have bigger issues, like the absolutely necessary support for H.265 and maybe VP9 that will be 2015 issues if not necessarily 2014 problems. I’d really like to see SCS open up Vegas for easier authoring of external CODECs, and built-in support for input and output frameservers. At least that way, I could write my own if I felt it critical enough.

-Dave

[Dave Haynie]

[Steve Green] “There is absolutely no difference in speed when using “Use GPU if avialible” and “Use CPU only”. I’ve updated my drivers, and now it says “QSV avialible”. Still no CUDA acceleration.”

This has kind of been hashed out, but let’s repeat. Vegas has a GPU setting — it’s the one you find on the Video tab in preferences. That will work for ANY OpenCL-compatible GPU. It does not use CUDA, but in most cases, nVidia’s CUDA drivers also support OpenCL. That’s the setting that Vegas uses for GPU-based compositing, etc. That’s the one and only one that makes your previews go faster — and by extension, all renders, since the same rendering has to be done for any video as for preview.

There are also GPU settings on a few of the CODECs, which apply to only those CODECs. Offhand, there’s a setting on Sony’s AVC CODEC and Main Concept’s AVC CODEC. Sony’s does very little with the GPU and I haven’t taken a close look at that one recently.

Main Concept, on the other hand, delivers a dramatic speedup if you have a compatible card. Unfortunately, they’ve rather subverted the whole point of APIs like OpenCL or CUDA (they actually support both) by hard-wiring their CODEC to use OpenCL ONLY for a small set of AMD GPUs — those available circa 2010. And same with CUDA — just those nVidia GPUs available around 2010… GPUs that exited prior to Vegas 11 shipping.

Basically, Main Concept has been shuffled around as a business, being bought first by DivX, then Roxio, and recently sold off. During the years it was owned by Roxio, pretty much nothing happened on the AVC CODEC — no improvements, no unlocking it for newer GPUs. Sony’s still bundling it, and it’s actually going to produce better quality video on the CPU (keep the GPU set for Vegas itself, but don’t use the Main Concept GPU setting for production video unless you’re willing to take somewhat worse quality video). Of course, if you’re using any recent GPU, it’s not something to worry about — you ARE using the CPU for the CODEC-specific part of the render.

-Dave

[Dave Haynie]

[Carlos Silva] “c) Secondary HD (1TB 5,400 RPM) or (1TB 5,400 RPM but hybrid SSHD 8GB SSD SATA 3 6GB/seg)?”

For video editing, I’d go for a 7200RPM drive without hybrid cache. The hybrid drives aren’t bad for a main drive… I have one at work. Not as fast as an SSD, but they can fool you sometimes, since they cache the stuff you use the most. Kind of pointless when a single video file is larger than the cache, though, so for a “data” drive, no point.

On the other hand, the 7200RPM drive will reduce your drive’s seeking latency. Sure, it’ll make it a little bit faster, too, but you might get more linear speedup with a 3-4TB drive. The latency comes to play when you’re shuffling between multiple files in a single project on that drive. For that, the faster, the better.

-Dave

[Dave Haynie]

[Norman Black] “Standard RAM timings for PC12800 are 9,9,9,24. Faster RAM will be 8,8,8,24. Same Mhz bandwidth but faster initial/random access (less latency)”

Not exactly… “CAS” standard for Column Access Strobe, rather than RAS, which is Row Access Strobe. The random access time is the same as the RAS time (sort of), as addresses always go row, then column.

Why care? Because modern PCs are very good at optimizing things, and they always hit memory for many cycles at a time. Normal memory isn’t read or written byte or word at a time, it’s written a cache line at a time… 256, 512, 1024 bytes depending on the CPU.

So anyway, that last number, 24 clock cycles, that’s the random access time, the RAS time, the same for each, and you pay that once per cache line read or write (at the most). The first 8 or 9 are usually the TCAS time (sometimes TCL, which means CAS latency, which is the same thing), and that’s paid for a bunch of subsequent memory cycles, as long as the memory controller it hitting that same memory page, it can probably just run in TCAS time. Always, when it comes to a cache line read or write. So it’s the first number that’s going to be more of a factor in memory speed than the second.

FYI, the second number is usually the RAS to CAS time (how long after I’m allowed to assert RAS can I assert CAS), the third is usually the RAS precharge time (how long after negating RAS can I re-assert RAS). These factor in when you’re calculating a full cycle time, mostly.

It gets more mathematical when you understand that you’re talking about clock cycles… so is a faster DIMM with a TCAS=9 better than a slower one with a TCAS=8? For that, you have to count cycles. So a TCAS=8 at 1600MHz is a 5ns cycle… and so is a TCAS=9 at 1866MHz, that’s also 5ns. If they’re both 24 cycle RAS, the 1866MHz part will run ever-so-slightly faster than the 1600MHz part, but not so you’d ever notice it. Going from TCAS=9 to TCAS=8 at the same clock speed is always a win, but a small enough tweak you’d need some special tricks to actually measure the performance difference.

-Dave

[Dave Haynie]

DVD native format is MPEG-2. YouTube’s native format is essentially H.264 these days. There is no way to do what you’re doing without reformatting.

If you’re seeing “combing”, that’s probably due to your reformatting the video to DVD to 60i… DVD can only be 60i, 50i (Europe) or 24p. Look into generating a proper 24p video, which is what most YouTube video is converted to when YouTube gets it. Incidentally, YouTube really doesn’t like folks downloading their video. Just sayin’…

You also have to realize that something which looks ok in a small windows on a PC desktop will not necessarily look very good on television. You might have to learn quite a bit more about what YouTube can do to a video’s original format, and how to potentially restore interlacing (if that was present in the original) to get the best results.

-Dave