Need to understand Wave db versus playback db (I think)

I have a clip I normalized in Audition and imported into sonar. I normalized it to 95% when looking at the wave, I see the widest part is around -1 When imported into sonar, I can barely hear it at all. but it shows it is clipping already. I increase the velocity and I can hear it just fine but it is in the red the whole time. It sounds fine but I am told to keep everything around -3 so what is the relation of the actual wave db and the playback db in Sonar and how to I make a clip to where it is loud enough to hear without clipping I barely understand what I am asking here so if it helps, I can put a video on youtube of what I am seeing to help illustrate.

It almost sounds to me like you have some difference in your playback set up between the 2 software programs.

A track played in Sonar that is anywhere half arsed in the middle of the level spectrum should be loud if your playback is set up properly. Check you haven't turned down a master output buss.

Are both programs accessing your audio interface ASIO drivers?
Sometimes people access there on board sound card for other programs and not the proper interface outputs.
Check SHARE DRIVERS WITH OTHER PROGRAMS , while your at it found in Audio options.

you have, sadly, stumbled upon the single most mis-understood detail of digital audio...
 
there is NO relationship between the numbers reported by Sonar, Audition, or any other digital audio program. None whatsoever. It's a mess!
 
So, what's a person to do?
 
First you need to have a basic understanding of what's going on in both the analog and digital domains.
 
An analog waveform can be described in a number of ways. Humans tend to perceive loudness as a time-weighted average. For reasons I'll skip for now, we can't simply measure, so we use the root-mean-squared (you know it as RMS) value... in terms of how we hear it's perfectly legit.
 
But we can also describe an analog waveform in terms of it's maximum (or minimum) value. While this does not help us 'measure' perceived loudness, it does help us to optimize the gain structure or relative levels in an analog signal path. Unlike our ears, active stages in a circuit care very much about peak amplitude.
 
Happily, in the bad old days of analog only, these two values are inextricibly related. If we can measure one we can calculate the other. And we'll be right every timg<G>!
 
Enter digital audio. You probably already know that when we convert from analog to digital we 'simply' sample the input and represent it as a number. That number represents the instantaneous value, which is the sorta/kinda like saying the peak value.
 
So there is no such thing as RMS with respect to the analog-to-digital conversion, it's always the instantanesous value at that sample point in time.
 
But wait, it gets worse...
 
In an analog circuit if you exceed the peak value that the analog circuit can represent faithfully you get an error, but it's not a 'hard' error. It is the nature of analog circuits that as we cross the maximum level we can faithfully represent we lose only the faithfully part.
 
If I have a transistor that operates linearly up to X volts then the ratio of output to input will be 1:N(theoretically - hey this is a forum post!) from 0 through X. After we cross X things will fall apart a little. We may no longer have a 1:N ratio, or we may increase distortion products... whatever the error it won't be perfect. Eventually, but it's a long way in a well designed circuit, we'll reach the real maximum level (the value of the power supply) and then it will get ugly.
 
In the digital domain there is a maximum value - all bits on or FF - and there is simply no way to go above it. The good news is that (again in an ideal converter) things are PERFECTLY linear all the way up. But... there is no safety zone, no buffer, and if you go beyond FF it gets really ugly really fast!
 
And there's more... There is no standard that suggests a point where we can safely set our nominal operating level.
 
oops - I skipped a step. In analog circuits there is a nominal operating level. It is always well below the maximum operating level. There are two competing standards today:
 
-10 dBV is the 'consumer' level, and it is 10 dB below a 1V reference. That means that if we have a 1V power supply we have 10 dB of headroom, or the difference between the nominal (0VU) and maximum levels. Of course even the lamest of current circuits operates on at least a 3V supply, so we have even more room.
 
+4 dBu is the 'professional' level, and it is 4 dB above a reference level of .7746V. Most professional circuits are designed to operate on +/-15V or even +/-18V the later providing 22 dB of hearroom, which is a lot.
 
Please note that both of these are RMS measurements, not peak.
 
So, getting back on track here... somehow we need to say that our nominal operating level (and it does not matter which one) is equivalent to some number in the digital domain. And we do that by guessing how much headroom we need. Some systems provide 12 dB of headroom, some 18 dB, and some use some other arbitrary number.
 
In the early days it mattered, a lot. Every bit you preserved for headroom took away some of your singal/noise ratio. These days most converters provide more than enough S/N ratio that we can preserve quite a few bits for headroom.
 
One more complication... the human ear, it turns out, is insensitive to certain digital errors, and really sensitive to others. That's a whole nother topic<G>... but be aware that these considerations need to be addressed.
 
phew - all that and I still haven't answered the question... what was the question? 
 
It would seem that if you are using the two programs on the same computer, with the same Digital-to-Analog converter, then there should be no difference between playback in one program vs the other. (all of this before you do any processing!!!) But, within each program the audio data may be represented differently - 16 bit vs 24 bit, fixed point vs floating point, etc. And while there are ways for programs to provide this information in the file header, it isn't always handled properly.
 
An early version of CoolEdit Pro (predecessor to Audition) did not interoperate well with any other program. I don't recall the details, but it was storing all audio data in one format, but reporting it in such a way (not sure who was right anymore) that other programs misinterpreted it.
 
So the first thing you can do is import the audio in a specific format. I don't own Audition so someone else will have to provide the particulars. (And heck, I could be completely wrong, but that would certainly explain the behavior you are seeing!)
 
One other point... you mention normalizing. May I humbly suggest that normalizing is a really bad idea. There is probably a file out there that will benefit from normalization, but I've yet to run across it.
 
Normalizing changes the relationships between the loudest and softest sounds in ways that bear no relationship to the way we hear things. It may be useful as an effect, but as a tool I think it is largely overused, and misused.
 
Here's what I'd do...
 
create three 400 Hz sinewaves in Audition, the first should be -18 dBFS, the next -12 dBFS, and the last 0 dbFS. Import each one into Sonar (with no other processing) and see what the Sonar meters tell you. (we choose 400 Hz cause it's really easy to hear distortion when it happens!)
 
Next, play each one back through your monitors (turn the amp WAY down to avoid damage to your ears or gear). Listen for distortion. Try to determine if either -12 or -18 sounds 'better'.
 
These steps should help you pinpoint your problem areas. If they don't post the results and they may help someone here figure it out.
 

washburn100


Holy crap!
I got through 3/4 of that post, but if I read it all, I'm pretty sure my head would have exploded. Dude, you gotta relax.
Just check your settings. If it is way quieter in Sonar, something is wrong. It should be almost the same.

Really? Sorry, I'll keep my thoughts to myself in the future.. but for now I will suggest that while the OP does point towards settings somewhere, it certainly wouldn't hurt anyone to understand the tools that they use.

HERE's one of the threads that includes a conversation about the AES-17 spec.  - Brings back memories

-D

DonM


Interesting thread here.  Just a couple of comments

First... Bill 73's buddy Western PA Ham here

73s to you! Always fun to run into Ham! Just setting up an HF rig - perhaps I'll find you there?

Second - regarding the difference between multiple digital audio tools measuring DBFS and DBu values in the same file...  I did a series of tests years ago that I posted here between Sonar, Sound Forge and I think Samplitude. As I recall meter ballistics was largely at the core of the differentials.  I remember we tried to set the meters at parity in Sound Forge and Sonar to no avail.  I think even Ron Kuper jumped in at one point to describe how the energy measurements were taking place.  I did a cursory search and couldn't turn up the thread - I'll try again if time permits

I remember that! At the time I tried to argue that, ideally anyway, ballistics should not play a part in a peak reading meter. Of course in the analog world they do, especially with mechanical metering, but even an electronic meter has timing issues.
 
I remember repeating your experiment with Sonar, Sound Forge, and Wavelab. If I was really careful to constrain the files to a specific format I did get repeatable measurements in all three. That's when I learned that I had to be careful<G>!
 
I haven't thought about it in a long time because right now I use Sonar X1 and Sound Forge 9 and when I move audio clips back and forth everything behaves as it is supposed to. I know, very limited test case.
 
I have been dealing with it on another front - designing the analog stages for a digital audio product - and it's been frustrating. The converters we are using have a max input voltage of 3.3V (and we had to resort to trickery to get them that high) so I have to compress a 36V peak-to-peak signal down to 3.3V, single ended no less. As luck would have it our inputs operate at either +4dBu or -10dBV, but our outputs operate only at -10dBV, and while it isn't ideal, it turns out that the 3.3V swing covers the consumer level, as long as you don't have a ton of dynamic range or a really high crest factor.
 
People's expectation being what they are we're going to leave it alone. I'm still not 100% certain that's the right solution, but adding gain at that point creates a world of additional challenges, and frankly, the headphone amplifier at least sounds awesome (it swings the entire 36V, or rather it can).
 
Anyway, with respect to the OP, assuming that it is only one computer/audio interface, it really does sound like something got scrambled in the file header, e.g. a 16 bit word is being improperly interpreted as a 24 bit word, and he lost 8 bits of level.
 
If I had Audition I'd be sorely tempted to experiment...

wst3

I remember that! At the time I tried to argue that, ideally anyway, ballistics should not play a part in a peak reading meter. 

Hmmm - Why not?  'splain this one here.  


I am assuming for the moment since I don't have a DAW open that Meter Ballistics should report peak differences if the measurement occurs between peak samples - maybe that isn't possible if the measurement rate can't fall in between samples - I would then understand  why my assumption is wrong.


But, if my memory is correct,  I have a thread somewhere with screen captures showing peak metering in SF and Sonar (probably S6) with a difference of more than 1db of peak measurement.  


I'll try this later today.


Understood trying to get a 3.3v signal to behave with a low crest factor - hopefully you're not dealing with classical music content - which is 90% of what I do - big crest factors there


Best


-D

I have tested on a number of occasions, and I have always gotten corresponding meter values going back and forth between Sonar and Sound Forge (or other programs).

So I suspect that if people are finding different peak values when converting between programs, it's simply either because gain was inadvertently changed somewhere (such as by pan laws or trim), or because a sample rate conversion was done.

And if any other DAW's peak meters are measuring anything other than the actual peak value of individual samples, it's news to me.

But it doesn't make sense to speculate. If someone believes a .wav file is treated differently by different programs, then just post that file and we can test it in our DAWs - and also examine the raw data inside the .wav file to determine the correct peak levels.

bitflipper: I can't download your file. I get 0 bytes. So I generated a similar one in audition, 32 bit 1kHz mono -6 dBFS peak and didn't get the same stats as you in Audition. Do you have some silence in there? All 4 of the RMS measures on mine are exactly -6 dB. --Oh, I see your minimum is -94.87 so yeah, you've got some quiet in there.

I then imported it into Sonar X1. With the 0 dB pan law, Sonar shows it as -6 dB peak. With the -3 dB pan law, Sonar shows it as -9 dB. That is as it should be, right? I did it with both mono and stereo track interleave. Did you verify your pan law?

Nothing at the link for me either...

I was taking a shower this afternoon and thought .... "Pan Laws could matter" and just checked in here. Good catch.

Sometimes my best thinking happens in the shower where I don't have a laptop.

-D

A file that when opened in say, wave Lab upon analyzing shows as -2Db peak and say 21Db average RMS is this what you are referring too when you say embedded? Of course if you pull the fader down it will output to the master buss at a much lower level, this is so obvious that I can't think this is what you are getting at?

A decibel (dB) is not a property - it's a unit of measurement.

It is a logarithmic representation of a ratio between two things. If used with no suffix (dB), it's used to compare two levels. If used with a suffix (dBu or dBV in analog electronics, dB SPL in acoustics, dbFS in digital audio) it compares a single level to a predefined level specified by the suffix. 

A fader, trim control or most any other means (limiting and normalization being two exceptions) of adding/subtracting gain doesn't set the "absolute" dBFS level (the level compared to full scale). It just adds or reduces gain compared to whatever was there. 

The meters show either peak or average (RMS) level dBFS. And a file stores samples relative to a standard level that can be expressed as dBFS.

IOW, the fader uses dB and the meters/file uses dBFS. They are not quite the same thing - the fader doesn't "set" the dBFS output level but adds or subtracts from what was there. So putting a fader at -3dB doesn't mean your signal will output at -3dBFS; it means it will output at 3dB lower than whatever it was.

Firstly wst3is incorrect. I get very consistent performance when monitoring levels between Audtion and most other DAW's (Not Sonar though)

Dave I thought you understood the reason why Sonar shows levels 3db lower than what Audition makes them. When you make a test tone in Audition set at -6db FS for example it the very tops of the sinewave eg the peak value of that wave that reaches -6db FS. Sonar RMS meters are simply showing the true rms value of a sine wave which is 3 db down from peak hence -9db. The rms meters in Sonar are not much use at all. They end up being right down on the scale and not telling you very much.

(You should be making stereo test signals as well and playing them back on stereo tracks too This removes the pan law discrepancies, they should not be involved. Using mono test signals brings the pan law into effect and adds confusion) FYI Studio One (and FL Studio) shows a -6db FX signal as -6db FS on their meters. So they are obviously reading the peak of the wave as they should.

Hi drewfx1 Well that could sort of explain it for sure. I always thought it was due to Sonar rms meter being a true 3db down from peak. (As per your sine/sqare wave concept)

But what is interesting though is that if I make a test tone say at -6db FS for either a sine wave or square wave, in Studio One the level is the same and still displayed at -6db.