Hello guys,I'm using cubase 5 and I was quite happy with it....but some time ago i discovered that there's something weird with its master.Basically,what I noticed (and it's not my impression,it's an "aural" phenomenon that's quite evident to my ears)is that when I open a vst (Example Z3ta) and play some notes,cubase is ALWAYS clipping if i don't trim the channel volume....
AND it sounds very muddy and not-so-loud,compared for example to other daws or to Scope mixer....I tried to route the master to scope mixer and i feel it sounds better,but that's not important now cause i simply decided to switch to one of the daws that sounds better to my ears (Podium or Ableton).They say all DAWS sound the same,this is IMO absolutely UNTRUE.
Podium (or even VstHost) for example sounds way more open,no clipping,more lively bass,way more pleasing to the ear !
Have you ever had a similare experience,or maybe anybody knows the reason for this ? Bit-rate maybe ?
I also found this
http://www.dpsworld.vibestudio.net/view ... 2c2b60eeb6
that confirms my impression
little headroom in cubase
Re: little headroom in cubase
If you're passing a 24bit signal to a 32bit INT (Scope/SHARC) or 48bit INT (Motorola/Pro Tools) or 56bit INT (DPS24 as in the link you reference) then do you think the signal is 'scaled' to an equivalent volume? No, so the additional headroom comes via the bitrate/format conversion in those cases.
Also 'mixing hot' in Cubase only matters when you're converting to soundcard output or less than 32bit float file output, as the point at which the internal floating point bus is reduced to 24bits is where it clips. Pull the master fader down, or individual tracks, and it's no longer clipping at the output. Simple as that.
And mixing with headroom is a great practice to be in imo unless you're making heavily distorted dubstep, drum&bass, hardcore techno/gabber or hard as nails heavy metal rock.
Also 'mixing hot' in Cubase only matters when you're converting to soundcard output or less than 32bit float file output, as the point at which the internal floating point bus is reduced to 24bits is where it clips. Pull the master fader down, or individual tracks, and it's no longer clipping at the output. Simple as that.
And mixing with headroom is a great practice to be in imo unless you're making heavily distorted dubstep, drum&bass, hardcore techno/gabber or hard as nails heavy metal rock.
Re: little headroom in cubase
I understand that hardware might have "additional headroom", my question was rather "why has cubase so little headroom compared to other daws ?" and i'm not asking this because i want louder tracks,i'm not complaining about that.I'm asking why the sound become so muffled and compressed in cubase,to the point where i become obsessed with meters every time i load a vst or i play guitar on a track...
where in other daws this doesn't happen,and everything sounds fine and deep and open even when it's clipping !
hope it's clear now
cheers
where in other daws this doesn't happen,and everything sounds fine and deep and open even when it's clipping !
hope it's clear now
cheers
Re: little headroom in cubase
I'm not the most brilliant soul in math (so I lean a bit far out of the window...), but one thing is frequently overlooked:
floating point values are able to describe a single(!) data element with astronomical precision, but completely fail to apply that to a continous numeric range.
That's the crucial difference to integer data, which will always preserve the relative integrity of a continous collection of samples.
The programmer shouldn't choose float (conveniently) just for headroom ability or individual 'precision', but check the goal of the processing.
I can easily imagine a scenario where 'making too much use' of floats extended range will not scale back properly at some further point in the processing chain.
And after all at some point the stuff must become integer again, at least before being fed to the output converter...
Imho (and in my ears) bitdepth (of the single signal) is totally overestimated.
People don't dare to move a fader downwards out of fear to 'loose bits' - hell, did they ever convert their favourite track to a 4bit copy ?
Just do it - you'll be amazed how much of a song can be kept within these 4 bits.
Even a 2 bit version can stil be clearly identified.
Try 8, 10, 12, 16, 20 bit - if it's a proper recording (and conversion) you will have something to chew on to tell the last 2 apart.
And I predict you won't be able to tell 22 from 24 bit at all...
I have no idea what Cubase does (not my cup of tea, never been...), but it's important HOW a software is coded, not what theoretical range it's numeric processing covers...
cheers, Tom
floating point values are able to describe a single(!) data element with astronomical precision, but completely fail to apply that to a continous numeric range.
That's the crucial difference to integer data, which will always preserve the relative integrity of a continous collection of samples.
The programmer shouldn't choose float (conveniently) just for headroom ability or individual 'precision', but check the goal of the processing.
I can easily imagine a scenario where 'making too much use' of floats extended range will not scale back properly at some further point in the processing chain.
And after all at some point the stuff must become integer again, at least before being fed to the output converter...
Imho (and in my ears) bitdepth (of the single signal) is totally overestimated.
People don't dare to move a fader downwards out of fear to 'loose bits' - hell, did they ever convert their favourite track to a 4bit copy ?
Just do it - you'll be amazed how much of a song can be kept within these 4 bits.
Even a 2 bit version can stil be clearly identified.
Try 8, 10, 12, 16, 20 bit - if it's a proper recording (and conversion) you will have something to chew on to tell the last 2 apart.
And I predict you won't be able to tell 22 from 24 bit at all...
I have no idea what Cubase does (not my cup of tea, never been...), but it's important HOW a software is coded, not what theoretical range it's numeric processing covers...
cheers, Tom
-
jksuperstar
- Posts: 1638
- Joined: Mon Nov 15, 2010 12:57 pm
Re: little headroom in cubase
I have heard that Ableton has a built-in limiter on the master output. Just so you never overdrive things while you're on stage. Not sure if it's true (I personally send direct outs to my hardware mixers, so I have no intention of testing this scientifically for myself). But it might explain it's loudness and lack of perceivable distortion.Merkury wrote:I understand that hardware might have "additional headroom", my question was rather "why has cubase so little headroom compared to other daws ?" and i'm not asking this because i want louder tracks,i'm not complaining about that.I'm asking why the sound become so muffled and compressed in cubase,to the point where i become obsessed with meters every time i load a vst or i play guitar on a track...
where in other daws this doesn't happen,and everything sounds fine and deep and open even when it's clipping !
Or I can be misinformed and incorrect.
Re: little headroom in cubase
I'm sorry but this is like astrophysics for meastroman wrote:I'm not the most brilliant soul in math (so I lean a bit far out of the window...), but one thing is frequently overlooked:
floating point values are able to describe a single(!) data element with astronomical precision, but completely fail to apply that to a continous numeric range.
That's the crucial difference to integer data, which will always preserve the relative integrity of a continous collection of samples.
The programmer shouldn't choose float (conveniently) just for headroom ability or individual 'precision', but check the goal of the processing.
I can easily imagine a scenario where 'making too much use' of floats extended range will not scale back properly at some further point in the processing chain.
And after all at some point the stuff must become integer again, at least before being fed to the output converter...
Wow that sounds soooo Lo-Fi ,I have to try ASAP 4 bitastroman wrote: Imho (and in my ears) bitdepth (of the single signal) is totally overestimated.
People don't dare to move a fader downwards out of fear to 'loose bits' - hell, did they ever convert their favourite track to a 4bit copy ?
Just do it - you'll be amazed how much of a song can be kept within these 4 bits.
Even a 2 bit version can stil be clearly identified.
Try 8, 10, 12, 16, 20 bit - if it's a proper recording (and conversion) you will have something to chew on to tell the last 2 apart.
And I predict you won't be able to tell 22 from 24 bit at all...
well this says it all ahah it's not my cup of tea anymore as wellastroman wrote:I have no idea what Cubase does (not my cup of tea, never been...)
but i still think it's the best for MIDI But seriously,I don't like having to turn the master down every time i play...it's just useless distraction for my music !
Another example = cubase master clipping -----> route the master to BUS2 (scope mixer)---->no clip at all,more headroom
Instead other daws seems to behave and sound like Scope mixer ! You see what i mean,I'm not masturbating my brain on Bit-depths
Re: little headroom in cubase
Incorrect, someone probably misunderstood that if they clip Live's output bus those 'extra bits' don't get 'limited' in the sense that they're handled like a brickwall limiter would, they get 'hard clipped' as in 'no data exists beyond this point' so the red portion is just dropped. I'm sure you know what hard clipping looks like, and the results will vary depending on the DAC & output section of the soundcard's ability to deal with clipping. Most sub-$1k gear generates a lot of unwanted additional harmonics pushed beyond its limits with hard clipped audio playback, though in some cases people might grow to like this anyway (like the treble rebels that blast 5.25" in-dash factory systems to 4x the ability of the 12w amp in the dash to do anything).jksuperstar wrote:I have heard that Ableton has a built-in limiter on the master output. Just so you never overdrive things while you're on stage. Not sure if it's true (I personally send direct outs to my hardware mixers, so I have no intention of testing this scientifically for myself). But it might explain it's loudness and lack of perceivable distortion.
Or I can be misinformed and incorrect.
Re: little headroom in cubase
The point in my previous post is that the DPS24 may have a different "0dBu" reference, say using the 48bit point as 0Vu/Dbu and allowing for 12bits of headroom beyond that. So when you try to feed it a digital signal from your DAW that comes in at 24bits (or 16bits with some really old adat interfaces) that may not get scaled to all 56bits due to the reference point being set elsewhere.
Ie, what happens when a 24bit signal enters a 48bit or 56bit (in the case of the OP example) bus is entirely up to the developers. While at this point in time most digital devices will handle it the same way (full scale = full scale regardless of the wordlengths they deal in), there are really numerous choices beteween retaining the same relative magnitudes (scale the 24bit signal across all 48/56 bits) or simply populating 24bits worth of information into the 48/56 bit worldlength. I was suggesting that the apparent difference in headroom with the DPS24 is probably due to the signal not being scaled completely to 56bits, but with some padding remaining. In fact the original author mused on this in that thread, and others simply gloated that their magic DPS was somehow greater than 'cpu based audio'.
I do understand that INT based mixing has the advantage that when you mix a low level signal into a high level signal the degradation due to scaling the lower level signal in INT math can actually be less than floating point math (where the extremes suffer from quantizing distortion--more inaccuracy the further you scale) and why we all love our beloved scope (internal dithering is another reason). But I think this is a nuanced discussion that only applies to comparing TDM/Motorola, Sharc/Scope & native mixing, not between multiple DAWs that all use the same wordlength & datatype.
Also it's been repeatedly demonstrated now that Cubase, Logic, Live, DP and Sonar will all sum to nothing when dealing with the same audio files (16bit, 24bit) sent through their summing bus. There are some minor issues with multipoint summing in Live and other apps that used a mixture of 64bit FLT & 32bit FLT or SSE4. Basically overall mix bus is still carroed forward in 32bit FLT, the point to point bus is 64bit FLT which gets converted down to 32bit FLT when sent back to the main bus, So if you apply parallel processing, the last bit (least significant) may get toggled in such a way that you get comb filtering at something like -160dBf. Some people argue that this is 'psychoacustically significat' even with material that's 145dB louder, but I really tend to doubt that unless you're doing several dozen stages of parallel processing with dozens of copies of the same track.
The 'summing' point basically points out that the math IS equivalent because it's relatively well established. What differs between apps is how input & output scaling is handled by plugins, the quality of the built in plugins, how well PDC 'bugs' are handled and what bugs the bussing implementation has. I think Cubase 6 is pretty solid in this regard too, they've finally worked out a lot of their cpu load issues, bus order problems (as of v4) and so on.
Ie, what happens when a 24bit signal enters a 48bit or 56bit (in the case of the OP example) bus is entirely up to the developers. While at this point in time most digital devices will handle it the same way (full scale = full scale regardless of the wordlengths they deal in), there are really numerous choices beteween retaining the same relative magnitudes (scale the 24bit signal across all 48/56 bits) or simply populating 24bits worth of information into the 48/56 bit worldlength. I was suggesting that the apparent difference in headroom with the DPS24 is probably due to the signal not being scaled completely to 56bits, but with some padding remaining. In fact the original author mused on this in that thread, and others simply gloated that their magic DPS was somehow greater than 'cpu based audio'.
I do understand that INT based mixing has the advantage that when you mix a low level signal into a high level signal the degradation due to scaling the lower level signal in INT math can actually be less than floating point math (where the extremes suffer from quantizing distortion--more inaccuracy the further you scale) and why we all love our beloved scope (internal dithering is another reason). But I think this is a nuanced discussion that only applies to comparing TDM/Motorola, Sharc/Scope & native mixing, not between multiple DAWs that all use the same wordlength & datatype.
Also it's been repeatedly demonstrated now that Cubase, Logic, Live, DP and Sonar will all sum to nothing when dealing with the same audio files (16bit, 24bit) sent through their summing bus. There are some minor issues with multipoint summing in Live and other apps that used a mixture of 64bit FLT & 32bit FLT or SSE4. Basically overall mix bus is still carroed forward in 32bit FLT, the point to point bus is 64bit FLT which gets converted down to 32bit FLT when sent back to the main bus, So if you apply parallel processing, the last bit (least significant) may get toggled in such a way that you get comb filtering at something like -160dBf. Some people argue that this is 'psychoacustically significat' even with material that's 145dB louder, but I really tend to doubt that unless you're doing several dozen stages of parallel processing with dozens of copies of the same track.
The 'summing' point basically points out that the math IS equivalent because it's relatively well established. What differs between apps is how input & output scaling is handled by plugins, the quality of the built in plugins, how well PDC 'bugs' are handled and what bugs the bussing implementation has. I think Cubase 6 is pretty solid in this regard too, they've finally worked out a lot of their cpu load issues, bus order problems (as of v4) and so on.