Why are BEDS limited to 7.1.2?

The omission of the rear height channels is a major PITA! What’s the technical reason for this design?

I’ve wasted days on routing issues with objects, just to get sound, let alone processing! But it only took me 40 minutes to go from an empty project to a fully loaded 7.1.4 surround template with all traditional processes available.

As such, I’ve been looking for the simplest possible ATMOS setup where 99% of the mix goes through the bed and objects are reserved for the rear height channels and even that simple objective is a routing nightmare.

This nonsense of inserting an FX into a group channel just to gain access to the renderer is bad enough. But all the subsequent requirements for something as simple as isolating a source with an FX to the rear height speakers is flat out ridiculous!

At this point, I’d like to just do a 7.1.4 surround project and find a way to print it in an ATMOS deliverable format. Life’s too short for this madness!:triumph:

I move this to the Nuendo forum, where you will hopefully find a higher number of knowledgeable people.

The short answer is that most home theatre use 7.1.2
Even if you don’t actually use the beds, just using the objects you could recreate anything from stereo to 7.1.2, 7.1.4 upto 22.22.22 and beyond. It future proofs your creation.

Majority listen to music using earplugs so accurate binaural reproduction was best achieved using objects eliminating the need for beds.

So don’t feel limited by just 10 beds.

Not so fast. Some reasons NOT to use objects:

  • Objects will not “light-up” speaker arrays (ie. larger rooms with multiple side speakers)
  • Limited bandwidth. ie. Streaming Atmos has a max 768 kbps. Do the math and ask yourself realistically, what kind of black magic voodoo can really accommodate a large amount of object channels and still maintain fidelity? For comparison: iTunes Music streams two channels at 256kbps.
  • FYI, when encoded for streaming, bed channels get converted to objects. (AND they can “light up speaker arrays” in larger rooms) There is nothing “anti future-proof” about using beds since those channels get converted to objects anyway.
  • FYI, when encoded for music or home theater streaming, the end user will only be able to render 16 objects total. Read again: ALL objects AND bed channels get effectively “mixed down” to 16 max objects. (Bonus FYI, the 16 objects include the 10 bed channels and the LFE!)

All of the above is in Dolby documentation papers. My opinion follows.

I also don’t think it’s a good idea to get too wrapped up in the height channels. Most users will hear those channels/objects mixed-down to 5.1.2 or binaural and it can get pretty messy if you have a lot of information up there. And then there’s high-end users with .6 heights who complain about getting a “hole” in the middle of their ceiling heights due to the .4 processing.

Here’s Apple’s advice in regards to mixing music for spatial audio:
“However, to keep the mix clear and coherent, limiting the number of object tracks to just a few featured sounds is recommended.”
I read this as: For optimal results, stick to the bed, kids. :wink:

*Above considerations are for music production. Post production being a different beast since since objects are primarily brief sound effects and what not which do not require constant and high bit rates as does music. (Also, theater-distributed Atmos is not bound by the strict bandwidth requirements of streaming audio.)

2 Likes

^^^^^^^^^^^^^ This!

… although I think the x.x.4 are mandatory for actual 3D music reproduction on speakers. x.x.2 do more harm than they help, in this context.

(That said, my personal sweet spot between “effort” and “impact” is 10.1 (read “5.1.4.1”) in an AURO setup anyway. :sunglasses: …)

1 Like

Because… Dolby. I don’t know what their reasoning for it was, but they are the limit. They decided on 7.1.2, 10 channels, for the max for a bed. It’s always seemed really stupid to me.

To me, it actually made the most sense to have beds be 5.1, as a backwards compatibility thing for regular DD. 5.1 bed, all height must be done with objects. I could then understand having a different bed and objects.

But for reasons I’ve never been able to find out, Dolby decided that beds would be allowed to be larger… but only to have 2 height channels. Makes no sense to me but now it is what it is unless another format takes over.

1 Like

Hang on a second though.

I think there is some nuance there. If you have a 5.1.2 bed for example and it lives in an ADM and you then play that back on a different system that is 9.1.6 you surely aren’t going to gain any location precision back from that bed. If there were sounds panned between front left and surround left in that 5.1 field that’s now baked into those channels together with other sounds and will never get de-baked. The “phantom” image-creation happens in the routing stage to that bed by virtue of it being pretty much a ‘regular’ surround path.

As for beds to objects: the bed channels get converted to static objects as far as I understood it, which is to say that technically front left in a 5.1.2 bed is the same as an object panned to the exact same location (ignoring spread).

So we are “losing” some (up)scalability every time we choose to output to a bed track rather than an object because that bed will be the sum of all signals that enter into it whereas the object is just one item.


Just to be clear: I’m saying that if the option is given to pan a sound to full left exactly 50% from front/rear then the comparison is between making that an object and on the other hand choosing the output to be a bed track of X channels. We can play with the idea of playing back that 5.1.2 bed in a 9.1.6 setup versus an object. Surely one would be pin-point and the other “phantom”.

I’m not saying that music deliverables should be the highest possible channel count for bed tracks or make us of a massive amount of objects either, just pointing out that there is a difference to be aware of if one ever wants to go back to the project for other output channel counts. Just don’t want people to think that beds will be converted into objects and thus sounds panned into beds will become objects in the process of encoding for streaming.

Sure I agree with what you have said, but the stress is on future proofing you mix.
Also the way smart devices communicate it is a non issue.

Majority listen to music using earplugs so accurate binaural reproduction is best achieved using objects eliminating the need for beds. altogether.

Personally I really like the sound of Sony360

Bottom line is that there are practical and commercial reasons behind Dolby’s decision to restrict the beds to 7.1.2… and Objects are the way forward as technology improves you are covered.

Right. But the same is true for panning a sound within an object bed, which has become popular among producers. Yes, you can target front-wide speakers with a 9.1.4 object bed, but in doing so, lose out on compatibility with speaker arrays. (Pick your poison)

A dense 9.1.6 (or even 7.1.4) object mix sounds like heaven in a recording studio, but the reality in 2024 is that sound bars and especially earbuds are just not there yet. And IMO, nobody will want to listen to the mix in the future if it doesn’t sound great today. It’s worth reposting this quote from Apple: “to keep the mix clear and coherent, limiting the number of object tracks to just a few featured sounds is recommended”

Sorry, I don’t understand what you are trying to say.

When you write that " you can target front-wide speakers with a 9.1.4 object bed, but in doing so, lose out on compatibility with speaker arrays." it almost sounds like you agree with me and Rajiv earlier. But you wrote “There is nothing “anti future-proof” about using beds since those channels get converted to objects anyway” and that seems contradictory.

Again, I’m really just saying that if we create 7.1.4 track in Nuendo and pan a source into that, and turn it into a bed track, then any x/y/z coordinates will completely disappear in the process. They exist in the panner at the source but once the signal is in the bed it’s all just summed with other stuff. In that sense it is no longer “future proof”. It doesn’t matter at all that the 11 channels in the bed get mapped according to the setup in the playback environment - as objects. No “poison” to pick, it’s all the same.

The only way around that is to leave objects as objects. Not saying this is what music engineers should do, it’s just that some will think an “object bed” (a poor label) is essentially the same as panning things and designating them as objects directly, which is not right.

To clarify, what I am referring to when I say “object bed” is different from the standard channel bed. I think you know what this means, but let me know if otherwise.

When you write that " you can target front-wide speakers with a 9.1.4 object bed, but in doing so, lose out on compatibility with speaker arrays." it almost sounds like you agree with me and Rajiv earlier.

When producers send an instrument to an object bed, then that audio IS being summed within those bed objects which are typically panned to virtual speaker locations. The difference being is that while an object bed does allow for compatibility with larger speaker set-ups beyond 7.1.2, it is not compatible with speaker arrays and more importantly (IMO) is subject to the Dolby streaming bandwidth “fidelity tax” (assuming you have additional individual objects on top of the object bed) So in terms of “future proofing,” the x/y/z panning coordinates for the instruments gets baked into that particular object speaker bed arrangement just the same. No advantage there in terms of fidelity or “future-proofing.” I believe most producers do this simply because it creates a more flexible workflow for dealing with importing other Atmos mixes or ADM files.

Here’s a recent video from an Atmos music mixer worth watching in regards to this topic:

I understand. I just thought you were referring to objects in general and not only specifically “object beds” vs “plain beds”. In terms of production I think it might make sense in some cases to have objects be objects exactly because they can “scale” and retain localization better depending on playback systems.

Since you posted a video his example is actually interesting: What if you want to rent out a theater for music playback of your new album?

If you have routed what would have been “single” objects into beds then you can never get the detailed location back in the theater. I’m not talking about object beds now, just objects. I’m also not advocating that people should be doing this a lot, some of the time or none of the time, just saying this is a distinction that wasn’t clear in your comment (because I didn’t understand you were talking specifically about “object beds”).

Or more common is the high-end home theater with multiple rows of seating. These are the folks who are more going to install side speaker arrays.

If you have routed what would have been “single” objects into beds then you can never get the detailed location back in the theater.

Right. I understand how objects work - I just don’t believe the juice is worth the squeeze when it comes to an all-object production workflow. For music anyway. More cons than pros, IMO.
:peace_symbol:

2 Likes

With the Bed Requirement and the bus requirements for objects placement, I find there are way too few objects with which to work! You’re down to 118 right out of the gate and to get maximum economic use of them, you’re going to need subgroups to send your mono and stereo objects. Now, you’ve got even more restrictions with regard to processing said object. All of this to serve the AI engine that provides the theoretical realism that may or, most likely, may not translate for the end user.

This, to me, is backwards. The AI should support the surround features to improve the ability to mix the components, thus giving much better odds at end user translation.

I’ll be sticking to the bed and using the objects as little as possible. I’m doing music only projects. So, I only need the ability to incorporate into film/theater projects. The static nature of the mix for listening only should be a plus with a Binaural Majority Market.

Think of objects as tracks, all the variations of piano goes there. so 118 should not be a limit.
There is no one way to work, If beds is the way you want to go then beds all the way.

Nuendo allows you to use multi beds of 7.1.2. you can have beds for drums, Base, etc etc. In the end you should do what you are comfortable with.

Just remember that AI would depend more on the object metadata and would be able to produce with pin point accuracy when it comes to instrument placement and extreme immersive experience. Its coming. But that’s a wholly different debate.

I get the feel that you wanted to reconfirm your personal choices and started the topic.
You need not, Beds are fine and SB has no choice when it comes to Beds it Dolby choice and as said earlier, they have their reasons- but SB has given you Multi Bed option (Nuendo only feature I believe, correct me if I am wrong)

What do you mean by that?

I guess to me the question would be just how many point sources I could even perceive during playback in a music mix, especially considering the limits of playback systems. I imagine a 7.1.4 setup where I’m listening to a mix, and if the mix is based on something fairly traditional like audience perspective of a band then how many objects would be needed to enhance the experience? I probably wouldn’t benefit much from anything more ‘resolved’ than 7.1.4 for reverbs or even delays. And then between for example front left and center how many objects in different locations could I perceive? 2? 4? 6? At some point I’m probably not going to be able to tell the difference between the position of adjacent objects because they’re too closely spaced, and at that point running multiple ones into a subgroup that is made into an object might be good enough.

I get that it’s a bit cumbersome, but that’s also part of audio engineering - making these decisions to satisfy limitations of deliverables. Maybe 10 years from now we have all the bandwidth we want to run all tracks as objects by default…

Nuendo allows you to have up to 64 beds.

1 Like

Not a Nuendo exclusive to have multiple beds.