Topic: A device (or mixer) that monitors in decoded M-S but records discrete tracks

[runonce]

The reason I'm recording it as two discrete tracks (the mid and the side) is so that I have total control *afterwards* of how wide or narrow I want the sound to be. If you record in stereo you're stuck with whatever amount of width you've chosen and I don't want to chose that in the field, because sometimes there is no *one* correct amount. For film work, sometimes you want the exact same sound in two or three different perspectives to match different shots in the film.

but, thats my point exactly.  do it in post.  no need to monitor it at all to hear what it might sound like in realtime (decoded signal to your headphones, while reccording raw m-s).  You're still going to mix it in post after the fact, so why worry about the "real time sound" ...when the finished product is going to be different any way.  Trust me, having done this many, many times..., what you think sounds great on the fly is never as good as what you mix in post in a controlled environment.   Plus, if you record a mixed M-S signal as stereo L/R, you can still bring it back to raw-M-S and remix it.  There is no "one chance" with Mid-Side.  No matter how the stream is recorded.

Are you reading the thread? He IS going to do it in post...

He's gathering foley - and has specific need to monitor his raw M/S decoded...

,,,he's not recording bands...

[Javier Cinakowski]

NicksPicks Posted:

I hear ya, but I guess it comes down to math at its core.  And that is absolute, so no loss.

Yeah, I understand the M/S math in regards to sum and difference.  However, my concern is that the audio editing software has to actually make a new wave file every time the encode/decode is done.  Hence an additional digital conversion process.  Sure, it is all digital, but I don't see how it can make new channels without making a new representation of the bits.  Sure, it can be mathematical reversed, but I suspect there is loss, akin to an additional DAC/ADC stage.   I guess proof would be if you can run a data checksum program on a M/S that has been encoded/decoded and it would still match.   I suspect it wouldn't...

[page]

NicksPicks Posted:

I hear ya, but I guess it comes down to math at its core.  And that is absolute, so no loss.

Yeah, I understand the M/S math in regards to sum and difference.  However, my concern is that the audio editing software has to actually make a new wave file every time the encode/decode is done.  Hence an additional digital conversion process.  Sure, it is all digital, but I don't see how it can make new channels without making a new representation of the bits.  Sure, it can be mathematical reversed, but I suspect there is loss, akin to an additional DAC/ADC stage.   I guess proof would be if you can run a data checksum program on a M/S that has been encoded/decoded and it would still match.   I suspect it wouldn't...

Na, it wouldn't, but how much different is up for debate. If nothing else, sample conversion noise would be introduced and dither noise, but besides that I don't know how well the sum/diff algorithm is and how much noise it would introduce. It would be an interesting test to do it like 20 times and compare it (assuming you could get the same mix at the beginning and end).

[Gutbucket]

[snip..]my concern is that the audio editing software has to actually make a new wave file every time the encode/decode is done.  Hence an additional digital conversion process.  Sure, it is all digital, but I don't see how it can make new channels without making a new representation of the bits.  Sure, it can be mathematical reversed, but I suspect there is loss, akin to an additional DAC/ADC stage.   I guess proof would be if you can run a data checksum program on a M/S that has been encoded/decoded and it would still match.   I suspect it wouldn't...

No your misunderstanding what digital processing is happening.  There is no 'additional digital conversion', no sample rate conversion, no loss.  If you wrote a new file of the output of a plugin that did an X/Y to M/S to X/Y conversion (and didn't adjust the ratio in the middle) the output should match the input exactly.  Check it if you want to.  If it doesn't then something is wrong.  If you change the ratio in the middle, it changes the data and they won't match, but that's the whole point of making an adjustment.

The increased processing bit depth of the program you use to host the plugin, above that of your audio file, accommodates any rounding errors in the sum and difference processing.  It's simple addition and subtraction.  Any modern DAW can do it perfectly and far more acurately than an analog mixer.

But go ahead and try it to convince yourself.

[page]

[snip..]my concern is that the audio editing software has to actually make a new wave file every time the encode/decode is done.  Hence an additional digital conversion process.  Sure, it is all digital, but I don't see how it can make new channels without making a new representation of the bits.  Sure, it can be mathematical reversed, but I suspect there is loss, akin to an additional DAC/ADC stage.   I guess proof would be if you can run a data checksum program on a M/S that has been encoded/decoded and it would still match.   I suspect it wouldn't...

No your misunderstanding what digital processing is happening.  There is no 'additional digital conversion', no sample rate conversion, no loss.  If you wrote a new file of the output of a plugin that did an X/Y to M/S to X/Y conversion (and didn't adjust the ratio in the middle) the output should match the input exactly.

I'm mildly skeptical of that, just because resampling from 48 to 44.1 and then back to 48 yields differences well under 18khz depending on your SRC algo. Someone did a bunch of tests and you could see where noise was introduced (again, depending on algorithm). I havn't tried, I understand the principle and you're right, it's just math, but something seems real fishy about that once you step out of the theoretical and into reality, maybe it's just cause I've read enough academic theory papers to see that there is usually a hole or flaw, maybe I'm just cynical.

[Ozpeter]

I'm assuming that the recording is bound to go through some kind of DAW processing before actually being used, so most of the considerations about additional manipulation of the file become pretty moot.  It's going to be manipulated anyway.

If you did want mono only, having recorded the file as XY stereo, you'd simply turn the side level control of the VST effect to zero.  These days, popping a VST effect onto a track is so trivial that I'd regard that as neither here nor there, in proportion to the whole effort of post production.

I would continue to assert that simply recording the MS mics converted to XY at the outset solves so much in the way of monitoring complexities at the outset, with no comparable downside, that it's the obvious solution to the initially stated problem.  I would strongly suggest exploring and evaluating the free, low-complexity route on a couple of experimental recordings first and then decide whether it is really necessary to throw money at the problem.

Link to Voxengo MSED (yes, it has inline processing) - http://www.voxengo.com/product/msed/

[Erick del Valle]

can anyone recommend a good recording device that has this feature???

MArk, try this for your heaphones output!

http://www.canford.co.uk/Browse/21263

Saludos
Erick del Valle
Santiago de Chile

[Gutbucket]

[snip..]my concern is that the audio editing software has to actually make a new wave file every time the encode/decode is done.  Hence an additional digital conversion process.  Sure, it is all digital, but I don't see how it can make new channels without making a new representation of the bits.  Sure, it can be mathematical reversed, but I suspect there is loss, akin to an additional DAC/ADC stage.   I guess proof would be if you can run a data checksum program on a M/S that has been encoded/decoded and it would still match.   I suspect it wouldn't...

No your misunderstanding what digital processing is happening.  There is no 'additional digital conversion', no sample rate conversion, no loss.  If you wrote a new file of the output of a plugin that did an X/Y to M/S to X/Y conversion (and didn't adjust the ratio in the middle) the output should match the input exactly.

I'm mildly skeptical of that, just because resampling from 48 to 44.1 and then back to 48 yields differences well under 18khz depending on your SRC algo. Someone did a bunch of tests and you could see where noise was introduced (again, depending on algorithm). I havn't tried, I understand the principle and you're right, it's just math, but something seems real fishy about that once you step out of the theoretical and into reality, maybe it's just cause I've read enough academic theory papers to see that there is usually a hole or flaw, maybe I'm just cynical.

Maybe I missed something in this conversation. Where did the talk of sample rate converson come from? Why does it have anything to do with M/S?

[page]

Maybe I missed something in this conversation. Where did the talk of sample rate converson come from? Why does it have anything to do with M/S?

Exemplary mostly. I'm of the belief that all mixing/processing introduces noise, but how much, where, and whether you can hear it is the real question.

[Gutbucket]

We'll rest assured that sum/difference processing is about as simple as it gets in digital audio processing.   Computers rock at 1+2=3 and 2-1=1.  If you were to run a checksum on a file before and after processing with Voxengo MSED without adjusting ratio, it would match.  Try it or ask in the Voxengo forum about it if you have lingering doubts, the developer there has been very good at answering a few questions i've posted there in years past.

Sample rate converion is an entirely different beast, it is inherently more complicated than the simple addition, subtraction and sign change (polarity) of M/S processing.  SRC throws out information by definition when changing the rate downward, though its done so well now that I wouldn't worry much about that either.  There are plenty of things that make a far more signigicant difference to be concerned about. 

Priorities, overlooking forests for trees and all that..

[SonoOtoSound]

I would continue to assert that simply recording the MS mics converted to XY at the outset solves so much in the way of monitoring complexities at the outset, with no comparable downside, that it's the obvious solution to the initially stated problem.  I would strongly suggest exploring and evaluating the free, low-complexity route on a couple of experimental recordings first and then decide whether it is really necessary to throw money at the problem.

Hey Ozpeter, you make a really compelling argument. The only reason I'm still not 100% on board with your recommendation is the desire to be able to use just a mono file. Let's say I'm working on a film and I frequently need to pull in a... good car door closing. It would just be so much easier to drag in a mono Mid file to a mono track, than to pull in the X-Y into a stereo track and then use the plug-in to alter it. Panning a stereo FX can be a total bitch - even if the plug-in was making it mono, having to pan a stereo fader is usually much more difficult than panning a mono one - especially if the panning is automated and moving around within a scene. Then the 20% of the time I want to use a stereo version of the car door FX (let's say because the picture has the car off in the distance) I drag in the Mid and the Side to a stereo track and then put a plug-in on that.

I know, I know. You're not convinced and think I'm going about it this the wrong way. But I just found a 302 for a great price and I think I'm going to get that (which does allow to me to monitor in stereo while recording discrete M/S) for the same price of a MixPre-D, which I'd have to get anyway. So I figure it's worth a try. And if my way of doing it proves difficult, I can always just do as you suggest with the 302 too. Thanks for all your thoughts though

[Javier Cinakowski]

Hmm, interesting and educational responses, thanks everyone.  I am going to try the checksum using voxengo without any ratio adjustment.  I am encouraged by the fact that I may be able to record stereo on the fly and rematrix later, without loss.... 

[Gutbucket]

Cool, let us know what you find.

Something I feel does matter significantly with this is the actual physical starting point, the particulars of the M/S or X/Y array you use, which mics, which patterns, which angles, and how coincident the setup actually is.  The useful range of adjustment is in most cases rather limited, so starting with a M/S setup that is as close as possible to what you want with a straight 50/50 decode, or an X/Y setup that is as close to what you want before possibly tweaking things somewhat with an X/Y>M/S>X/Y plugin is one of the keys to goodness.

Consider that what most would think of as 'standard' M/S using a cardioid mid is not equivalent to X/Y cardioids and in no possible M/S ratio does it decode to X/Y cardioids.  All standard two mic M/S setups using a cardioid or supercardioid mid decode to virtual X/Y mic patterns that have some degree of rear lobe.. but to my thinking that's a feature not a bug. 

I'd think SonoOtoSound would probably want a supercardioid mid for his FX work, to help isolate the sound of interest.  A shotgun mid is often used for film dialog work, but that won't sound as natural for non-speech FX sounds.

[noahbickart]

There is one small, perhaps only theoretical, benefit to recording m and s, and not and encoded signal.

In most cases, because the sound source in on axis to the M signal, levels are higher on the M than the S. However, if you record the M and S separately, you have the option of recording both as close to 0db as possible.

Yes, in post you'll end up bringing down the level of S, but in the process you have maximized your signal to noise ratio, because as you bring down the signal of S you also bring down the noise on that signal.

You give up this sonic benefit when you encode before recording.

[Ozpeter]

I know, I know. You're not convinced and think I'm going about it this the wrong way.

Oh, I'm open to a persuasive argument related to your particular needs, and I can see where you are coming from - I guess it depends (amongst many things) on the software are using, and how easy that makes the extraction of the side signal.

At the end of the day, you knowing what your particular needs are, having reviewed the thoughts expressed in this interesting thread, are the only one who can decide what's best for you!  As so often in audio, there is no "always right" solution.