From: Jack O'Quin (joq_at_io.com)
Date: 06/17/03 10:47 EDT
Subject: Re: [Jamin] level and metering From: "Jack O'Quin" <joq@io.com> Message-ID: <87brww222l.fsf@sulphur.joq.us> Date: 17 Jun 2003 09:47:30 -0500 R Parker <rtp405@yahoo.com> writes: > I'd like to reach some conclusions regarding levels, > metering and clipping. I cooked a fairly hot output > level from JAMin, routed it to Ardour and then monitor > Ardour outputs--I want to hear what's being printed. > My testing seems to indicate that if JAMin -1db then > Ardour -1db. Good. > The meters in Ardour ride way up in the red very near > 0db, see hyp-ard.jpg. That screen shot shows a wav > view that appears alarmingly close to the threshold. > It's cause for concern. Attached is a Rezound screen > shot where clip indication is turned on and no clips > are indicated, see screenshot-rezound.jpg. This > metering into the red causes me to become alarmed but > in fact it seems to be a design choice. There seem to be different points of view in digital audio metering regarding when to go in the red. Ultimately, the output medium can only hold numbers up to a certain magnitude. But, some applications like to flash red as a warning when they get within several dB of the limit. This is confusing, because they often impose different thresholds. > Is there a way to scientifically measure what's been > produced. I don't understand digital audio. I recall > that there's a dynamic range for 16bit 44100 files > that's near -37000 to +37000. > > Do those numbers represent samples? > > If samples, then +37001 would be a clip? Data represented as 16-bit signed two's-complement integers have a range from -32768 to +32767. Could these be the numbers you're remembering? Anything over +32767 or under -32768 would be a digital over. But, I am ignorant of the "red book" standard for CD audio. Perhaps some code points are reserved for other use. Internally, JACK, ardour and JAMin represent data using 32-bit floating point numbers. These are not limited to the values that can be represented on a CD (but, see below). > Do we have a tool that analyzes files and determines > that there are samples exceeding 37000 samples? I don't know. There's probably something. And, at least for testing purposes, we should probably use it. If there's not anything handy, we can cobble together a simple jack client. Or, maybe Steve's meterbridge can (or could) serve as a double-check. > I think these are important issues that need to be > explained in our documentation. For example, when my > studio business partner Dana walked in on the test > session and observed the Ardour input levels he said, > "you're in the red." That means he thought I was > clipping. I said, "no, it's OK." Well, my response > isn't going to assure a paying client that everything > is fine. In fact I fail to assure myself. I think the red indicates when and how much the limiter is squashing your output. IIUC, the limiter will not allow *any* out-of-range data in the output. I believe the "limit" slider selects how far *below* 0dBFS the output will be clamped, usually a fraction of a dB. Question: what float range is the limiter enforcing? (-1.0 .. +1.0)? > I think the solution is to proove that everything is > OK. Does this make sense to you guys or am I becoming > to anal? In software development, anal is good. :-) It's just in "real life" that it becomes a problem. ;-) Regards, -- Jack O'Quin Austin, Texas, USA ------------------------------------------------------- This SF.Net email is sponsored by: INetU Attention Web Developers & Consultants: Become An INetU Hosting Partner. Refer Dedicated Servers. We Manage Them. You Get 10% Monthly Commission! INetU Dedicated Managed Hosting http://www.inetu.net/partner/index.php _______________________________________________ Jamin-devel mailing list Jamin-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/jamin-devel
This archive was generated by hypermail 2.1.7 : 10/28/03 09:33 EST