Go Back   Cockos Incorporated Forums > Projects > Deprecated REAPER issue tracker > Closed Issue

0dB should not trigger peak overload indicator Issue Tools
issueid=3280 03-12-2011 06:27 PM
Human being with feelings
0dB should not trigger peak overload indicator
The 0dB point on a VU meter should not be considered an 'overload' condition and should not trigger the red indicator on the peak meter of a track

If the peak volume of a track goes over 0dB, it triggers the 'overload' indicator on a track and the peak is highlighted in red. This is extremely useful to quickly find problems in recording and playback levels.

It is also desirable to make tracks as close to 0dB as possible - and the Normalize function on a track does just this, by lowering the track volume so that the highest peak in the track is exactly 0dB.

Unfortunately, 0dB is considered by Reaper to be an 'overload' situation, and so all normalized tracks will trigger the overload indicator, making it useless.

I would recommend changing the overload indicator algorithm to only trigger when a track is > 0dB and not >= 0dB.
Issue Details
Issue Type Closed Issue
Project Deprecated REAPER issue tracker
Category GUI and graphics
Status Live With It For Now
Priority 8
Affected Version 3.73
Closed Version (none)
Yes votes 5
No votes 5
Assigned Users (none)
Tags (none)

03-13-2011 02:42 PM
Human being with feelings
 
If there is a discussion thread for this I will explain why I completely disagree with the premise of the FR/bug.
Reply
03-13-2011 04:05 PM
Human being with feelings
 
There is nothing beyond zero Db. When using integers (either 16 or 24 bit) 0 Db means that all bits are set to 1 for a given sample. So, you cannot go over 0 Db (unless you use 32 or 64 bit floating point, like on individual tracks... the master fader should never go beyond 0 Db).
There is a sort of "standard" that when there are at least three samples at 0 Db this can be considered an Over situation (I think this standard is by Sony but am not sure about that).
So, the point is to understand if, in Reaper the red light lights up when you have even a single sample at 0 Db (and thus that would be only a zero Db indicator) or if the red light lights up according to that (or any other) standard, and so it would be an Over indicator.
By what you say, this cannot be derived since, when you normalize at 0 Db you could teorethically have many "adjacent" samples at 0 Db, and that would trigger an Over situation on any system (and, by the way, that is correct).
So, I think this is not a Reaper issue and should not be changed.
Reply
03-13-2011 04:26 PM
Human being with feelings
 
Thanks for filling in the theory behind the definition of 0dB. I won't dispute any of it but to be honest it's kind of irrelevant.

The fact remains that the way the peak VU overload indicator works at the moment is not useful when considered in context. It doesn't really matter whether there is nothing beyond 0dB in theory, because Reaper shows values greater than 0 in its meters (as does every other VU meter I have used before), and these would indicate clipping in real life, and one would normally want to avoid this.

Maybe the VU overload is fine and it's the normalize function that's broken, but I personally like being able to set the faders precisely to get a 0dB peak track mix, and I want a fast visual queue to know which channel is clipping. Right now Reaper doesn't give me that and it's been annoying me as I start using more and more tracks - it's not high priority but it's a request for change I would love Cockos to consider.
Reply
03-13-2011 10:51 PM
Human being with feelings
 
when i import a mastered song from a cd or import a sound from a sample bank, unless i pull the gains down it shows clip signal
Reply
03-14-2011 07:18 AM
Human being with feelings
 
I disagree with it. 0 dBFS should get marked as "clipped". Not a bug.

Maybe it would be cool to define how many contiguous 0 dBFS samples will trigger the overload indicator. I guess right now it's 1 sample?
Reply
04-27-2011 05:45 PM
Human being with feelings
 
So let's just agree and say that 0db is considered 'clipped' in the digital realm, I don't necessarily agree (one point at 0db does not a clipping make :-) ) but I don't mind.

The problem remains that when you 'normalise' a track or section, it finds the largest point and scales the sample to make that 0db and therefore triggers the clip indicator every time. This is extremely annoying and I propose that instead any operation that does some sort of 'normalise' will instead scale the largest value to 0db 'minus one bit' so that it falls one below the clip line.

Is that more palatable to everyone?
Reply
04-27-2011 06:36 PM
Human being with feelings
 
I would agree with the request or bug. For me, it's weird to import an audio CD that you know isn't clipped, but the meter indicates that it is with the red indicator. This behavior doesn't happen in the other daws, or at least the ones I've worked with. It kinda makes you think that the mastered wav file your playing back is distorted, when in reality it isn't.

Edit: +1 to what Dstruct said.
Reply
04-27-2011 07:00 PM
Human being with feelings
 
Quote:
Originally Posted by Dstruct
I disagree with it. 0 dBFS should get marked as "clipped". Not a bug.

Maybe it would be cool to define how many contiguous 0 dBFS samples will trigger the overload indicator. I guess right now it's 1 sample?
+1 for a configurable clipping indicator. I remember in the 90's some sony DAT showed a clipping or overload state a few db before 0dbfs for a certain amount of consecutive samples IIRC.
Reply
05-08-2011 12:04 AM
Human being with feelings
 
I'm still not quit understanding this. Are some of you saying that if an exact 0dBFS wav, or sine wav, and not one sample over, is clipped, and should be shown clipped by an red overload indicator?

Here's a 0db Sine wav at exactly 0db. Is it clipped? No

Reply
05-08-2011 05:59 AM
j79 j79 is offline
Human being with feelings
 
That argument only holds if you assume that there always is a sample at the exact point on the sinewave where the amplitude is maximal...and that assumption would be wrong.
Reply
05-08-2011 07:08 AM
Human being with feelings
 
^ exactly
Reply
05-08-2011 07:14 AM
Human being with feelings
 
however - to resolve this two things should exist

1) Sample peak metering that registers an 'over' as 3 consecutive samples above 0dBfs (which is the standard I believe)
2) Oversampled peak metering that registers an 'over' when the reconstructed analogue signal would peak above 0dB - ie. meters that register 'signal' not samples
Reply
05-09-2011 01:58 PM
Human being with feelings
 
Ok,
I do agree with you guys. It's not a bug. This should be changed to a feature request, right? And the request should include any kind of change to be an option, that way it wouldn't in anyway effect the current way.
Agreed?

I found this older discussion thread here.
http://forum.cockos.com/showthread.php?t=26596
Reply
05-12-2011 09:25 PM
Human being with feelings
 
Quote:
Originally Posted by WyattRice
Ok,
I do agree with you guys. It's not a bug. This should be changed to a feature request, right? And the request should include any kind of change to be an option, that way it wouldn't in anyway effect the current way.
Agreed?

I found this older discussion thread here.
http://forum.cockos.com/showthread.php?t=26596
Reading that old thread I have to say it supports my original report that this is a bug in Reaper. In addition, I think previous posts here would agree there is a bug somewhere.

- if the Normalise function in Reaper is generating audio containing more than 3 consecutive samples over 0dBFS and that's why Reaper reports a clip every single time you use Normalise, then there's a bug in the Normalise function

- if the clip function is not looking either for 3 consecutive samples over, or at the interpolated wave going over, then it's a bug in the clip function.

Given reports that both the Normalise function and importing normalised audio from other apps results in Reaper reporting a clip, I think there is a bug in the clip function.
Reply
05-13-2011 10:34 AM
Super Moderator (no feelings)
 
My 2c: Whether that's a bug or not depends a bit on your opinion on when a clip indicator should indicate and why. First off, the actual clip indicator is the little number showing the maximum peak level, plus signs tell me I might have messed up.

The other question is when the background of that number (which is different from a classic "overload LED") should turn red in order to drag your attention to that particular clip/peak indicator. An indicator that lights up just on the border of bad so it has a miniscule warning character or beyond and after the fact, merely indicating the obvious?

As you know, that LED served much more as a warning light than as a "catastrophe happened" indicator in the analog world, there was a margin beyond that point and how much it flickered also indicated how much of that margin you used. In the digital world, an overload indicator light has changed its role, it often shouldn't come on at all like a hypothetical "engine dead" light in a plane and this little tweak gives it a super-tiny little bit of this purpose the old OL LEDs had back, by not overly trying to simulate one (and also not overly trying to be an annoying warning light).

The price is that you can't go 0dB flat without triggering that function but comparing the tasks and occasions where you need 0dBFS flat output vs. occasions where you benefit from that little "outlandishness" this seems to be a low price to me and I can only beg you to live with it. :)
Reply
05-16-2011 01:48 AM
Human being with feelings
 
Quote:
Originally Posted by Ollie
...

The price is that you can't go 0dB flat without triggering that function but comparing the tasks and occasions where you need 0dBFS flat output vs. occasions where you benefit from that little "outlandishness" this seems to be a low price to me and I can only beg you to live with it. :)
I'm happy to live with the clip the way it is, if you fix the Normalise function in Reaper and all the other external tools that keep making the d4mn clip light come on whenever they are used :-)

I guess the workaround is to normalise and then reduce manually by 0.1db or something. Not catastrophic - just really annoying!
Reply
05-16-2011 05:32 PM
Human being with feelings
 
Are we talking about the beta 4 version, or is this in version 3?
Reply
Reply

Issue Tools
Subscribe to this issue

All times are GMT -7. The time now is 02:40 AM.


Powered by vBulletin® Version 3.8.11
Copyright ©2000 - 2020, vBulletin Solutions Inc.