[Dave Haynie]

It makes perfect sense that Sony would be selling off their PC division. They never sold that many PCs; at their peak, under 1M, more recently, about 600K per year. That’s a very low margin business, too, and Sony’s hardly the first company to sell off their PC business (PC sales have been shrinking about 10% per year for awhile), or transition to mobile devices. Sony’s already in the mobile devices business, and they seem to be concentrating on that. Also unaffected are their camera and camcorder, gaming, and other professional and CE divisions, far as they’ve said.

They are spinning off the TV business as a wholly-owned subsidiary. This makes some sense. I actually bought a 70″ LCD/LED TV from Sony last Spring… it’s a very nice television. But the competition in the market has been fierce, and Sony has a disadvantage. Early on, Sony backed LCoS as their display technology of choice, and so didn’t get into the LCD panel business. Like some other companies, Sony get panels mostly from LG… but LG is a competitor…. Sony’s kind of in the Nikon position, not the best place to be.

And look at TV: it’s Sony, Samsung, LG, Panasonic, Sharp, and a boatload of Chinese. Samsung, LG, Panasonic, and Sharp all have their own LCD panel business. The Chinese brands are all discount brands, so they’re ok with the “OEM quality” displays from suppliers, but Sony’s got to be able to get the same quality as the top models from the display-making-TV-companies, or they can’t compete. Not sure what the spin-off does, but they might be more agile, at least, than as part of the big Sony machine.

-Dave

[Dave Haynie]

[Bob Moyer] “If this is really true then I have been wasting my time rendering to “MainConcept MPEG-2(.mpg .m2v .m2t mpa) – Blu-ray 1920×1080-60i, 25 Mbps video stream” “

I use AVC. And yeah, the older Main Concept was not recommended for BD. Tge version in Vegas 12 is new.

[Bob Moyer] “To further muddy the waters, if I check the ‘clip’ properties within Vegas, it just says that it is an Mpeg2 transport stream.”

.ts, .m2t, .m2ts, etc are MPEG-2 Transport Stream files. That’s the container format… like .avi, .webm, .mov, or .mp4. AVCHD, Blu-ray, ATSC and DBV broadcast standards, and most cable/satellite systems use TS streams to contain video and audio in various formats.

-Dave

[Dave Haynie]

The best is MainConcept AVC at 25Mb/s…. you didn’t list that.

Rule of thumb is that a good AVC encoder will have twice the coding efficiency of a good MPEG-2 encoder. So that 16Mb/s Sony AVC will compare to 32Mb/s MPEG-2.

Another rule of thumb: all MPEG-2 encoders are good. Some AVC encoders are less than good. AVC got better every year for about a decade… at some point being good enough that an encoder chip on a portable camera could crunch HD in realtime. Those first, not so good, today, we don’t think about it. So in short, the AVC at 16Mb/s may not always beat out your MPEG-2… you really have to evaluate the two, on a good television or monitor.

Another one: your mileage may vary. Video compression is basically a means of using math tricks to make our brains believe that a 1/2 oz of beer is actually a 2-litre stein. Sometimes the content (video, not beer) isn’t well dealt with with that particular bag of tricks. In short, you have to watch it. The video, I mean. Lots, on different screens.

That may be a thing starting to get lost in today’s tech, because things usually, pretty much judt work. When I mix an audio project, I probably listen to each song 100 or more times before it’s done. That’s in my computer room, in the car, the gym, at work,,, crap, need -3dB on the bass, repeat. Stop listening for a week, come back, try to hear what I missed, etc. Modt of the time, either of these CODECS will be just dandy… but give it the critical eye, just in case.

-Dave

[Dave Haynie]

Here’s how to think about this: much of the work done for a preview has to be done for any kind of render. And of course, the resources used to do that stuff, compositing and FX and all, is unavailable for the actual encoding part of the render, when you get around to rendering it.

So I see about 6x slower renderings going CPU-only than CPU + GPU on this project. That’s not even slightly shocking, given that my CPU benchmarks at about 154 GFLOPs, while the GPU’s peak performance is about 2700GFLOPs. Not the whole story, of course, because it’s very hard to use all of that GPU performance. So I see the CPU-only render pretty nicely pegged at around 95%; when I add the GPU, the CPU use drops to below 25-35% depending on settings, and the GPU use is jumpy, but peaks at 93%.

-Dave

[Dave Haynie]

It’s not as if I’m stuck in Acid… I’ve got Vegas, I’ve got Cakewalk Sonar, and I’ve got REAPER. But there’s really nothing like Acid for loop synthesis… everything else is clumsy and limited.

Acid’s only a dead end if it’s never being updated… I mean, it still works, but it’s not fully functional with modern gear. Sony ought to just say it’s done. After all, they still sell it… most people do expect a program currently for sale to be still supported.

And after all, Acid Studio was just updated, it’s version 10 now and “Windows 8.1 compatible”. Acid hasn’t been updated since… 2010!

-Dave

[Dave Haynie]

[Stephen Crye] “On my system and his, the only options in that drop-down are “none” or the names of the card. OpenCL is only available as an option in the MainConcept render template; in the Sony render template, there are three choices, Auto, CPU-only, or GPU if available.”

Just to clarify — when you seen your GPU listed in the Preferences/Video tab under GPU acceleration, that IS OpenCL. Vegas only uses OpenCL internally. That setting is only for Vegas’ own use: compositing, etc. That setting is passed on to plug-ins that know OpenCL.

Some 3rd party plug-ins may have their own GPU settings, which can of course include CUDA or OpenCL. Among those plug-ins are the video plug-ins. Sony’s AVC plug-in inherents the setting from Vegas (that’s the “use if available” setting), while Main Concept requires explict setting of OpenCL or CUDA.

That’s why I was suggesting a test render with/without the Vegas preference setting. What what I gather, you’re always running Vegas in OpenCL mode, but switching between CPU-only, CUDA, and OpenCL when running the Main Concept plug-in. Which seems to always do the same thing, suggesting to me that it’s not using the GPU (when I run with the GPU enabled in both places, I’m see 80-90% peaks from the Main Concept CODEC, as viewed with GPU Shark). So if you set the Vegas itself to CPU-only, reboot Vegas, and try a CPU-only Main Concept render, that’ll give you more information about whether OpenCL is helping you or not with the Kepler card.

Right now, from you’ve told me, all we know is that Main Concept’s AVC encoder doesn’t do anything different with OpenCL or CUDA, but there’s a reasonable expectation that it won’t use any new GPU for either of those things. If OpenCL is really bad on the Kepler, switching that off in Vegas might actually make things faster, particularly on a very fast CPU. Maybe not, but it’s worth knowing.

-Dave

[Dave Haynie]

And to the point of the question… you want the loudest signal that you can get that absolutely doesn’t clip (eg, it’s always below 0dBFS). I’m a big fan of not trying to get audio on a camera if I have another option… using my PC or my Zoom, I can put in a soft limiter, I have more resolution, etc. But basically, everyone agrees you want the best SNR you can get, which means the most signal possible.

Start with a quiet room. I did a thing last year with some voice-over, had the whole thing perfect, only then to notice that I had some annoying background noise in my PC room (mostly from the PC.. one reason the new one is crazy quiet). I was able to “fix in post” using a noise gate and a background track (duck that when you’re speaking, of course), and it sounded great, but I felt stupid for letting happen in the first place.

Depending on the situation, you can’t always be perfect. If you’re recording at 24-bit and producing for a 16-bit project, you have plenty of headroom… so in that case, try to get your peaks while you’re setting levels no more than say -12dBFS, and you’ll never risk blowing it out, even if you get a little excited while narrating.

For a voice-over, I’d probably compress 2:1 or 3:1, probably no more unless you’re a really dynamic speaker. I nearly always record “dry”, but this is one situation where it’s not likely a sin to use a compressor while recording, if you have one, particularly one with a soft limiter (my dbx 1066 is one of the few pieces of “classic — eg, real — audio gear I keep available, though with all the software tools and 24-bit recording interfaces, not so much these days).

If you’re compressing in a DAW, don’t just randomly choose a threshold, either… you really want to follow the signal with your compression. You can do this by ear of course, but I’ve gotten awfully spoiled by Izotope Alloy, which lets you dial this in graphically.

Then RMS normalize to about -16dBFS, give or take. Some goes as high as -10dBFS for voice… not sure I’m one of them. Whatever you do, being consistent is important.

-Dave

[Dave Haynie]

[Roger Bansemer] “Here’s one thing we do as a safeguard:
When recording in the field with a SLR lav mike, my camera will record on two tracks and unless I have a mic on two people I set it so I get a slightly higher or lower level on each track. That way if a track ends up being to hot I have the other track as a choice.”

I learned that as “run and gun” mode… with a single mic, you dial one to the level you think you want, the other down 12-18 dB, and you get an extra 2-3 bits worth of effective headroom on your signal.

Obviously, the best setup is to have a full-time sound guy actively monitoring the recording on 24-bit gear. Not always possible. But funny to watch me try to operate a boom pole and a camcorder (tripod-mounted, of course) at the same time 🙂

-Dave

[Dave Haynie]

Don’t know… I always use uncompressed files for alpha channel stuff. It remains the case that 4:4:4:4 is probably not what he wants.

-Dave

[Dave Haynie]

It could be your 4444 encoding. And that’s almost certainly not needed. If you recall the notation for color subsampling, it’s nearly always three numbers: 4:2:2, 4:4:4, 4:2:0, 4:1:1. The reason is that this is setting the ratio of Luma samples to Cr and Cb samples in a pair of digital scan lines… 4:4:4 means you’re not tossing out any color samples.

When you’re talking 4:4:4:4, that means you’re also including an alpha channel… one additional 8 or 10-bit channel of information. This is usually meant to be transparency, and as I recall, DNxHD allows this to be rendering uncompressed, even while doing the usual JPEG-like intraframe compression on the YCrCb components.

In short — unless you’re using the alpha channel, this will make your DNxHD files large, perhaps even huge, compared to just 4:4:4 or 4:2:2… or it’ll make them lower quality, since some of the bit-budget is needed for the alpha channel (I think that’s how DNxHD does it — fixed bit rate, but it’s been awhile). I do not know if that could also be a compatibility issue… I know Vegas handles transparency, but only if you ask nicely, otherwise it’s ignored. But it’s possible the older Mac software is confused about that.

-Dave