Thread Rating:
  • 0 Vote(s) - 0 Average
  • 1
  • 2
  • 3
  • 4
  • 5
Why dual mono files when recording in stereo?
#1
Hi, does anyone know what was the particular reason behind the choice made to record stereo sources as dual mono files instead of a proper stereo file?

Dirk
Reply
#2
I've often wondered this too !

Back when I added ArdourXchange support, I arranged for ArdourXchange to generate stereo files (if the audio was stereo) and Mixbus seeeed to read them just fine...
Knowledge is knowing a tomato is a fruit...
Wisdom is knowing you don't put tomatoes in a fruit salad !!
Reply
#3
I have always associated interleaved audio with Video / Broadcast whilst multi-mono is more the norm for Music and Cinema work.
Macmini 8,1 | OS X 13.6.3 | 3 GHz i5 32G | Scarlett 18i20 | Mixbus 10 | PT_2024.3.1 .....  Macmini 9,1 | OS X 14.4.1 | M1 2020 | Mixbus 10 | Resolve 18.6.5
Reply
#4
Two mono files are not necessarily intended to be in stereo and one can have many more possibilities when one can process each of them and eventually mix them together in a perfect balance. And if they are intended for stereo usage, it's still very nice to have the possibility to treat them differently or just take away one of them if that is better for the mix. So simply said: -Two mono files give more versatility - I very often split a stereo file into two mono files.
Mixbus/Mixbus32C on Linux (Kubuntu)/KXStudio repositories.
GUI: KDE and Fluxbox
Reply
#5
Because prior to computer DAWs, there was no such thing as "stereo" files, tracks, and VERY few (specialized) mixer channels.

So "proper stereo file" is an advent of this century-and more amateur tech of this century...and I think you'll find some disagreement about what makes it "proper" but I'm not a mastering guy.

As to why Mixbus rips your stereo file into two mono ones, I imagine it's because you can't model a stereo channel/EQ of an analog mixer, because they don't exist. Thus while they will nicely display it as a stereo track/channel/waveform for you--the underlying analog model has to remain dual mono control linked.
Win10pro(2004) : i7 8700/RX570 8gb/16gb/970evo : RME PCIe Multiface : Mixbus 32c 4.3 & 7.2
Other DAWs: Logic 10.4 (MacBook) Cubase 10.5 (PC)
Music: https://jamielang.bandcamp.com
Reply
#6
I come at this from a different angle. I record classical music using a field recorder. When I first started using MB a few weeks ago I noticed that having the "copy files to session" option selected in the import dialog caused the resulting copies to be split into mono files. To avoid this I have been moving the files directly into the "Interchange" folder and then importing them from there (with the copy button deselected). This keeps the files in their original interleaved state. Is there any reason I should consider letting them be split instead?
Reply
#7
I would normally go for seperate tracks as this allows me more control over the material.
Even if there are stereo or 5.1 pairings I would always bring those up as mono channels.
That way I have total independent control of EQ, Dynamics and panning of any channel.
Macmini 8,1 | OS X 13.6.3 | 3 GHz i5 32G | Scarlett 18i20 | Mixbus 10 | PT_2024.3.1 .....  Macmini 9,1 | OS X 14.4.1 | M1 2020 | Mixbus 10 | Resolve 18.6.5
Reply
#8
(09-16-2020, 11:05 PM)Dingo Wrote: I would normally go for seperate tracks as this allows me more control over the material.
Even if there are stereo or 5.1 pairings I would always bring those up as mono channels.
That way I have total independent control of EQ, Dynamics and panning of any channel.

While I agree in theory, the imported files are still treated as stereo with the mono left and right channels added to the same track. This doesn't afford you any more control than if the source was interleaved. They are even listed as a single stereo source in the source list. The only way you would even know they have been ripped to dual-mono would be to browse the hard drive. MB treating those two mono channels as if they were interleaved seems to negate any advantage there would be to having them mono, unless it's for some internal processing that I am unaware of. Regardless, I can't think of a single situation where I would apply processing to only one channel of a stereo classical recording. M/S, sure, but not L/R.
Reply
#9
@RecordingKC:

I agree with all of your comments. But this was a design choice made 'long ago' and it's not something we are likely to change.

There are a few downsides of this choice: you might lose a bit of disk-performance because of seeking (rarely an issue on today's systems) and you can't just 'steal' the stereo recorded file out of the interchange folder... you have to 'export' it if you want a stereo file.

There are also a few upsides: if you drag a stereo region into a mono track, we only have to read the first ("left") channel. And it helps to avoid file-size limitations: you can record twice as long in a mono wave-file, as can in a stereo wave-file, before you hit the filesize limit.

Best,
-Ben
Reply
#10
(09-17-2020, 08:07 AM)Ben@Harrison Wrote: @RecordingKC:

But this was a design choice made 'long ago' and it's not something we are likely to change.

Hey, I am a long time Samplitude user. I know all about legacy features!

Quote:And it helps to avoid file-size limitations: you can record twice as long in a mono wave-file, as can in a stereo wave-file, before you hit the filesize limit.

That's actually brilliant. Somebody earned their kudos that day.

There are two reasons I move files directly to the "interchange" folder. One, since MB is non-destructive it seems like a waste of HD space not to use the original files. And two, I don't like that the originals are being altered during the import operation. As you said, it's nice to be able to just grab the original file and use it somewhere else. So, just to be perfectly clear, I'm not violating any sort of best practice by doing what I'm doing? The other option would be to simply use my own folder structure and import without copy, but it makes sense for portability to just use the default folders provided by MB.
Reply


Forum Jump:


Users browsing this thread: 1 Guest(s)