I can’t think of a single instance in the last decade where an editor wanted a discrepancy between the left/right channel as laid in on two mono tracks (split stereo). And I can’t remember a single time where I wouldn’t have been able to quickly create whatever that would have been myself. Come to think of it; most engineers I know prefer to “nuke” the editors settings anyway, be they panning or levels, because they generally a) know less about audio, and b) have been forced to screw it up through last minute changes forced on them.
In short; I never encounter any situation where there is stereo material on two tracks and L/R differ and should differ, and I never encounter any situation where whatever was different couldn’t have been recreated (duh) quickly.
The point I was trying to make is that there should be some kind of algorithm that “identifies” if two files actually belong together. Without that detection, you would be able to merge any two mono files into a stereo file. Not that this is a problem, but it would distroy the warning function that you might be merging the wrong files, or that there is another file on the track that doesn’t belong there. I think removing the detection would be bring a whole other sets of possible problems and errors, and would not lead to an advantage over the current implementation.
First of all, there seems to already be some sort of detection going on since it fails the merge when things aren’t identical. At that point it seems reasonable to me to just log those events when they happen. Anyone that chooses an option other than deleting the source mono tracks can then just refer to the log to see where there were events that were merged despite being different. If it’s not possible to merge the events then just delete them. Same thing; check the log for errors.
Now look at the above and compare it to what we see today: Error. Done. No troubleshooting help at all but one has to go through the entire timeline with a comb to find the errors, and if none are found it may still not work apparently. Better then to just ‘brutally’ merge or delete and create a log, then we can compare. Much better and much less time consuming.
Secondly, there are cases where editors generally place sound effects in stereo on the timeline, such as “swhooshes” for example, but at times then goof and post a single file instead. Just double it then. I understand that I’m now stuck with mono rather than an actual stereo effect, but two things apply here for a lot of engineers: a) again - just give us a log so we can quickly get to the spot and replace the sound, or, b) nobody cares that the fx was mono and we have no time to fix it anyway, so we can leave it that way.
Again, I’d like to see examples of cases where you’d actually work faster the way it currently fails merging completely rather than any of the above scenarios. Because I can’t for the life of me come up with any.
You are turning the problem into an exotic user case.
It’s not that every attempt to merge dual mono files fails.
I have that every now and then, one in a few dozen. And I have very rarely came across a case where I couldn’t fix the problem. So in the majority of user cases, it works pretty damn good.
If the functionality fails every time for you, then it’s not the functionality that should be criticized, but the person who delivers you these badly edited files.
As I said before, the problem “begins” with having to clean up the OMF or AAF we recieve from the editors.
In an ideal world, music should be on music tracks, in stereo. Stereo effects on stereo FX tracks. Dialog on mono DX tracks, etc … That’s not a problem caused by conventions or file formats, it’s a problem caused by people. So the more they screw up, the more time we have to spend to clean up the mess.
Again … just my two cents.
You are free to disagree.