TrueRTA-for-dummies - Page 4 - AVS Forum
Forum Jump: 
Reply
 
Thread Tools
post #91 of 358 Old 08-11-2007, 05:38 PM
AVS Club Gold
 
SierraMikeBravo's Avatar
 
Join Date: Mar 2007
Location: Topeka, KS
Posts: 1,477
Mentioned: 0 Post(s)
Tagged: 0 Thread(s)
Quoted: 36 Post(s)
Liked: 47
Hey all!

Well, just got done using the true rta fir the first time. I have one question. For some reason, I could not get the pink noise graph to get to 70 dB or higher. My entire graph was hovering around 50-60 dB no matter how much how much I increased the gain on my Denon 4306. As a comparison, I used a SPL to see if I was in the ballpark. The SPL showed 80-90 dB while the true rta showed only 50-60. Is this normal? However, when I used a since wave tone of 200 Hz, it spiked up to around 80 dB on the true rta with no increase in gain on the receiver. I used that as the reference, but is it in the nature of the pink noise signal to display that low on the rta? Doesn't make sense. The loop was fine and flat lined around 105 dB. Anyone know what may be the issue? I am using a ECM 8000 mike with the calibration file from tru rta. Also, and M-Audio PreUSB. I had the "R in" button pressed for the RTA as I using right input and outputs. I

Thanks a bunch!
Shawn

Shawn Byrne
Erskine Group
CEDIA Certified Professional EST II - HAA Level III Certified -THX Certified Professional


To view links or images in signatures your post count must be 0 or greater. You currently have 0 posts.



To view links or images in signatures your post count must be 0 or greater. You currently have 0 posts.
SierraMikeBravo is offline  
Sponsored Links
Advertisement
 
post #92 of 358 Old 08-22-2007, 05:35 PM
Member
 
IncraTL's Avatar
 
Join Date: Dec 2006
Location: Seattle, in the GREAT NW
Posts: 42
Mentioned: 0 Post(s)
Tagged: 0 Thread(s)
Quoted: 0 Post(s)
Liked: 10
Hi:
Thanks for the RTA info . It's well written and detailed and will be quite helpful to me.
Just a quick question, if you don't mind -
I tried to download the free Level 1 RTA and was told I couldn't because my Dell has a Vista operating system. O.K. On 4 December 2006, my father-in-law purchased a level 4 RTA disk, (Version 3), as a Christmas present for me.
Question: Could I use this Level 4 disk on my Dell, (w/ Vista)?

Thanks for your time with this,

George
IncraTL is offline  
post #93 of 358 Old 09-01-2007, 05:18 AM
Senior Member
 
tonyptony's Avatar
 
Join Date: Dec 2004
Posts: 474
Mentioned: 0 Post(s)
Tagged: 0 Thread(s)
Quoted: 0 Post(s)
Liked: 10
I just ordered TrueRTA via credit card for direct download. How long does it take for the process to complete? That is, once I order, how long till I get it?
tonyptony is offline  
post #94 of 358 Old 09-01-2007, 07:53 AM
Advanced Member
 
Kenrosencpa's Avatar
 
Join Date: Feb 2002
Location: Alamo, CA
Posts: 875
Mentioned: 0 Post(s)
Tagged: 0 Thread(s)
Quoted: 0 Post(s)
Liked: 10
Their website say's up to 12 hours. This is a holiday weekend maybe more or less
Kenrosencpa is offline  
post #95 of 358 Old 09-26-2007, 03:34 PM
AAR
Newbie
 
AAR's Avatar
 
Join Date: Sep 2007
Posts: 1
Mentioned: 0 Post(s)
Tagged: 0 Thread(s)
Quoted: 0 Post(s)
Liked: 10
I am a relatively new user of TrueRTA.

The program indicates that the impulse wave is used for "delay testing", yet I cannot find any documentation in the help file as to how to do this. I want to time align (as best possible) the two drivers in a two-way system. Is there a way to derive the step response??

TIA

AAR
AAR is offline  
post #96 of 358 Old 11-11-2007, 08:56 AM
Member
 
bgavin's Avatar
 
Join Date: Nov 2007
Location: Orangevale, CA
Posts: 102
Mentioned: 0 Post(s)
Tagged: 0 Thread(s)
Quoted: 0 Post(s)
Liked: 11
I have found a show-stopper bug in TrueRTA at v3.3.3.

During bass horn testing, I was having data anomalies. As it turns out, TrueRTA is broken. Very repeatably broken.

1 - The program SPL meter does not agree with the captured data points

We measured a Tuba 36S at 1w/1m, and expected 105 SPL. The RTA meter display read 106+, and the peak data point read 105. At first we figured the programm was summing all the data under the curve, not just the peak value.

Bug.

2 - The data export function is entirely corrupt and useless.

I was having erratic results using the Workbench to export data. We use this function to sample 100 Hz as a reference point. We then sample Pink noise and export the data. The Pink data points are increased where 100 Hz matches the sine wave sample. The data are wrong.

Every time I export data, the .TXT file data points change by approximately 2dB. Reimporting the same data points into Workbench raises the graph 2dB. Exporting the same data raises it again, reimporting raises it yet again.

Bug. The exported data points are entirely useless.

I have notified TrueRTA this is a show stopper bug.
bgavin is offline  
post #97 of 358 Old 11-14-2007, 08:42 AM
Member
 
bgavin's Avatar
 
Join Date: Nov 2007
Location: Orangevale, CA
Posts: 102
Mentioned: 0 Post(s)
Tagged: 0 Thread(s)
Quoted: 0 Post(s)
Liked: 11
I called TrueAudio this morning and spoke with Sharon. My email to Support from 11/11 was still sitting in queue, unread. She forwarded the mail to John Murphy along with screen shots and bug attachments. I asked for a confirmation of receipt, so I know he got it.

As usual, she was in denial about there being a bug. As a 35 year veteran of software development, I expected this. I won't accept it, but denial was expected. What is more important is what John Murphy has to say about the bug, and how soon he fixes it.

I build bass horns and pro sound cabs, and the TrueRTA bug has invalidated my measurements. The curve shapes are correct, but the SPL values are all corrupt. Many days of accumulated measurement data are worthless.
bgavin is offline  
post #98 of 358 Old 11-16-2007, 08:31 AM
Member
 
John L. Murphy's Avatar
 
Join Date: Apr 2002
Posts: 23
Mentioned: 0 Post(s)
Tagged: 0 Thread(s)
Quoted: 0 Post(s)
Liked: 10
Hello TrueRTA users!

bgavin reports 2 bugs which I would like to address:


My Summary:

Bug 1: appears to not be a bug at all but just a normal measurement difference.

Bug 2: appears to be valid but is limited to affecting only imported .txt data.



Let me explain:

Bug 1
bgavin reports:
<< 1 - The program SPL meter does not agree with the captured data points

We measured a Tuba 36S at 1w/1m, and expected 105 SPL. The RTA meter display read 106+, and the peak data point read 105. At first we figured the programm was summing all the data under the curve, not just the peak value. >>


This is not a bug, just perhaps an unexpected result. TrueRTA is giving correct readings for both the broadband dB level and the individual narrow-band dB level because these are actually two different measurements. Look at it this way; the narrow-band dB reading will always be lower than the broadband dB level because only the level of one individual frequency "bin" is represented by an individual bar's cursor readout (or exported data point). The broadband dB level (the bar at the far left) represents the energy present in the full frequency spectrum which includes the frequency bin of interest along with all the other frequency bins. Even if the one bin is at, say 105 dB SPL, and the other bins are all at some lower (noise floor or distortion) level the broadband dB SPL reading (as indicated by the large bar at the far left of the plot area and by the on screen numeric display at the top left) will measure at some higher level due to the broadband background noise. This is normal for these types of measurements. Only in the theoretical case where the distortion and noise were infinitely low would the two measurements be the same. For real world measurements there will always be a difference.



Bug 2
bgavin reports:
<< 2 - The data export function is entirely corrupt and useless.
...Every time I export data, the .TXT file data points change by approximately 2dB. Reimporting the same data points into Workbench raises the graph 2dB. Exporting the same data raises it again, reimporting raises it yet again. >>


The data export function actually works just fine. If you have 240 bars of onscreen data you will get 240 data points when you export the data to a .txt file. If you inspect the file you will see that the data points precisely match the individual on-screen bar levels. Your exported data is fine.

However, I have confirmed a problem with data import from .txt files that would explain the reported error. While the exported data precisely matches the on-screen bar readouts, some types of data can be shifted as much as a couple of dB upon import. This shift is most likely related to the way imported .txt data is interpolated into the (much larger) internal data buffers. While a response is represented by about 240 data points on-screen or as an exported .txt file the full data set actually consists of about 32,000 data points. When you save your files in project files (.rta) or single sweep files (.rt1) you are saving and restoring the full 32,000 data points. When data is imported from .txt files it has to be interpolated into the 32,000 data points. Some loss of resolution is to be expected but I think it can be improved. Smooth, broad responses seem to be minimally affected while narrow band measurements (such as single tones) are affected the most.

The screen shot below shows the difference between measured data and the same data data exported/imported to/from a .txt file:





I will investigate this .txt data import anomaly and address it in the next release of TrueRTA. In the mean time it is fortunate that most users do not normally export and import their data. As long as you are storing your data in the normal TrueRTA project file format (filename.rta) or even exporting to single memory files (filename.rt1) you should not be affected by this bug. Again, only data imported from .txt files appears to be affected.

Regards,

John

John L. Murphy
Physicist/Audio Engineer
True Audio

To view links or images in signatures your post count must be 0 or greater. You currently have 0 posts.
John L. Murphy is offline  
post #99 of 358 Old 11-18-2007, 02:39 PM
Member
 
bgavin's Avatar
 
Join Date: Nov 2007
Location: Orangevale, CA
Posts: 102
Mentioned: 0 Post(s)
Tagged: 0 Thread(s)
Quoted: 0 Post(s)
Liked: 11
Quote:
Originally Posted by John L. Murphy View Post

This is not a bug, just perhaps an unexpected result.

I am a 33+ years professional programmer, and the corollary to this is a feature is a bug with useful side effects. This is the sort of denial one expects from Microsoft. It does nothing to correct the problem, so let's please stay focused on the bug.

Here's the first problem restated:
1) TRTA geneartes a 100 Hz sine wave
2) Separate SPL meter reads 105 SPL
3) TRTA on-screen meter reads 106 SPL
4) TRTA on-screen data point reads 105 SPL
5) Export to TXT shows 100 Hz at 105 SPL

This is a point measurement, not broad band. The sine wave is 40dB higher than background. If TRTA is accumulating across the entire spectrum, it is still hearing 100 Hz at 40dB higher intensity than background.

I always calibrate TRTA to the SPL meter.
Do I calibrate TRTA to the Screen data point, or Screen Meter value?
Question: one is wrong, one is correct. Which one?

I calibrate TRTA to the SPL meter with the screen data point. I do this because the exported TXT data point agrees with the SPL meter. I treat the Screen Meter as wrong, because it does not agree with the data points.

The meter issue is mildly annoying but certainly not a show stopper.


*************

Here is the show stopper bug:


Quote:
Originally Posted by John L. Murphy View Post

However, I have confirmed a problem with data import from .txt files that would explain the reported error. While the exported data precisely matches the on-screen bar readouts, some types of data can be shifted as much as a couple of dB upon import.

This is the entire crux of my bug report.
This effect is cumulative, and completely invalidates my test data.
Each export/import of the same data changes the TXT file and the screen data points.

I require ACCURATE data in the import/export function, so shifted as much as a couple of dB upon import is not at all acceptable for my needs.

All of my measurement work centers around the TXT data points.

Quote:
Originally Posted by John L. Murphy View Post

When data is imported from .txt files it has to be interpolated into the 32,000 data points. Some loss of resolution is to be expected but I think it can be improved.

Any loss of resolution for the known TXT data points is not acceptable.

Here is the bug fix: Interpolate the intermediary points between the known TXT data points. After interpolation, verify the results with the TXT points to insure there is no change to the known values.

I would be happy to be your early tester for the resolution of this bug. I cannot wait a year, or whatever, for the next release. If my schedule does not fit yours, I will contact you for a refund, and find a different measuring tool.
bgavin is offline  
post #100 of 358 Old 11-23-2007, 06:30 PM
Member
 
bgavin's Avatar
 
Join Date: Nov 2007
Location: Orangevale, CA
Posts: 102
Mentioned: 0 Post(s)
Tagged: 0 Thread(s)
Quoted: 0 Post(s)
Liked: 11
I have found a critical data error bug in the Level 4 TrueRTA v3.3.3 RTA Octave Resolution display.

The on-screen and exported data points are invalid for all resolutions lower than 1/24 octave.

The user takes a measurement which is present in the Workbench.
When the user selects different RTA Resolution, i.e. 1/3 Octave, 1/6 Octave, the data values change.

The measurement has not changed. TrueRTA is changing the data point SPL values as it changes octave resolution.

This is dead wrong.

The bug is demonstrated by using 80 Hz as the sample frequency because 80 Hz is present in all octave resolutions except for 1 Octave.

In this example, a 100 Hz sine wave measurement was taken at 1/24 octave resolution.
Below are the results at 80 Hz.


1/24 Octave: 35.22 dB
1/12 Octave: 38.11 dB
1/06 Octave: 40.66 dB
1/03 Octave: 43.95 dB
1/01 Octave: 50.47 dB


Exporting the Workbench verifies the onscreen dB values match the text file data.
The 1-octave resolution does not export 80 Hz, so only the screen point was used.

Every SPL data point on both on-screen and exported values are corrupt at all resolutions lower than 1/24.
bgavin is offline  
post #101 of 358 Old 11-23-2007, 09:59 PM
Member
 
bgavin's Avatar
 
Join Date: Nov 2007
Location: Orangevale, CA
Posts: 102
Mentioned: 0 Post(s)
Tagged: 0 Thread(s)
Quoted: 0 Post(s)
Liked: 11
I have found a horrific data portability bug in the Level 4 TrueRTA v3.3.3 RTA.

Transferring the .RTA file from the Measurement laptop to my Office workstation results in corrupted data.

Example:
I spend a whole day taking measurements in the field with my laptop.
When I get home, I transfer all .RTA files to my primary workstation.
I load these files into the identical version of TRTA.

AND ALL THE DATA IS WRONG!!!!!!!!!!!!!

Every single SPL data point is off by approximately -8 to -9dB.


Laptop Trace
Desktop Trace


I wondered why I was losing day after day of field test data. Transferring it to my workstation produces these horrific errors. When I export the files to TEXT, it verifies the data corruption.

This is seriously, seriously lame.
This bug is akin to creating an Excel 2003 sheet at the office, and finding it corrupt on the home version of Excel 2003. This bug makes my TrueRTA data useless on any machine other than the one it was created on.
bgavin is offline  
post #102 of 358 Old 11-27-2007, 07:52 AM
Member
 
jonash72's Avatar
 
Join Date: Nov 2007
Posts: 17
Mentioned: 0 Post(s)
Tagged: 0 Thread(s)
Quoted: 0 Post(s)
Liked: 10
I have a weird issue with my new Laptop and True RTA.

Setup is as follows

Laptop: Compaq nx7300 with Windows Vista installed
Soundcard: M-Audio USB Mobile Pre

I try to do a system Calibration, but I just cant get it to do a correction worth it's meaning.

On my stationary PC, I have Windows XP, and when I try it there with the same soundcard, the same settings, I get a ruler flat line. I move the USB cable over to the Laptop, without doing anything else, and perform a sound cal and it looks nasty. Specifically from say 500Hz and down.

Any ideas?

The things I can think of myself are:

1. Could it be the M-Audio driver for Windows Vista?
2. Could it be the Laptop itself, the USB port or some such?

Any help appreciated.

(I have been thinking about installing XP on the Laptop as well, just to remove one of the "unknown" an dsee if that helps, but I'd rather discuss other options before I do that, obviously...)

Thanks,
Jonas
jonash72 is offline  
post #103 of 358 Old 11-27-2007, 08:23 AM
Member
 
carbuff's Avatar
 
Join Date: Dec 2002
Posts: 115
Mentioned: 0 Post(s)
Tagged: 0 Thread(s)
Quoted: 0 Post(s)
Liked: 11
Quote:
Originally Posted by jonash72 View Post

I have a weird issue with my new Laptop and True RTA.

Setup is as follows

Laptop: Compaq nx7300 with Windows Vista installed
Soundcard: M-Audio USB Mobile Pre

Jonas,

I'm having a very similar problem, you beat me to posting about it.

I have a MobilePre with a Behringer mic. Using either the built-in soundcard or a cheap USB unit that I purchased, I can get flat calibrations. With the MobilePre, I'm not getting a flat calibration. And when I take measurements, whether using the calibration or not, I have huge spikes and peaks (which of course is possible from the room, but moving the mic doesn't help much), so I'm not trusting the results I see.

I'm running Windows XP on my laptop (older Dell unit).

I have another question along these lines also...

I don't use an analog source. I'm using the DACs in the Cary 11a unit that I have to produce all output to my amp. So, in this case, I'm not sure that doing a calibration makes any sense at all? Since I don't care what the analog out side of my soundcard is doing, testing and calibrating a loop doesn't make a lot of sense?

So I've been experimenting with a few things to see what I can do. From my laptop I can drive a digital coax connection to my preamp. So, I have been trying to use trueRTA to calibrate by driving digital into the preamp, and connecting the line-in of my soundcard (any of the 3 I have) to the left channel output of the preamp. In my mind that seems like the starting point that I would want to calibrate, since all of my sources are digital?

Does that approach make sense?

If so, it's not working any better than my above scenario in the sense that I can't get a smooth calibration with this setup either...

Any helpful suggestions appreciated!
carbuff is offline  
post #104 of 358 Old 11-27-2007, 09:10 AM
Member
 
jonash72's Avatar
 
Join Date: Nov 2007
Posts: 17
Mentioned: 0 Post(s)
Tagged: 0 Thread(s)
Quoted: 0 Post(s)
Liked: 10
Quote:
Originally Posted by carbuff View Post

Jonas,

I'm having a very similar problem, you beat me to posting about it.

I have a MobilePre with a Behringer mic. Using either the built-in soundcard or a cheap USB unit that I purchased, I can get flat calibrations. With the MobilePre, I'm not getting a flat calibration. And when I take measurements, whether using the calibration or not, I have huge spikes and peaks (which of course is possible from the room, but moving the mic doesn't help much), so I'm not trusting the results I see.

I'm running Windows XP on my laptop (older Dell unit).

Hmm, well, that would possibly rule out that the Vista driver from M-Audio is to blame.

I am pretty sure I had a very flat system cal on my old laptop which was a Toshiba Portege, with Xp Pro.

The thing is, I am never using TrueRTA's built-in generator, as I always use a pink-noise track on a CD (to also take into account the source units performance). So line-out isn't an issue for me at all really. But the line-in is, specifically the XLR Phantom powered (mic) input. I also use a Behringer ECM8000.

But I have no clue how linear the line-in is on the Mobile-Pre. When I do system cal on the stationary PC, its almost ruler flat to begin with, but as soon as I connect the darn thing to my Laptop, it looks like the Himalayas...

/Jonas
jonash72 is offline  
post #105 of 358 Old 11-27-2007, 11:33 AM
Member
 
carbuff's Avatar
 
Join Date: Dec 2002
Posts: 115
Mentioned: 0 Post(s)
Tagged: 0 Thread(s)
Quoted: 0 Post(s)
Liked: 11
Quote:
Originally Posted by jonash72 View Post

But I have no clue how linear the line-in is on the Mobile-Pre. When I do system cal on the stationary PC, its almost ruler flat to begin with, but as soon as I connect the darn thing to my Laptop, it looks like the Himalayas...
/Jonas

I wonder if the problem is the quality of the power that is provided over the 2 different machines' USB ports?

I will try to plug my MobilePre into my desktop and see how it calibrates. I haven't tried that before.

Also, again, does calibrating the line-out to line-in make sense if you are in-fact using the Microphone input? What are you calibrating in that case?
carbuff is offline  
post #106 of 358 Old 11-27-2007, 12:52 PM
AVS Special Member
 
krabapple's Avatar
 
Join Date: Apr 2003
Location: in a state bordered by Kentucky and Maine
Posts: 5,290
Mentioned: 0 Post(s)
Tagged: 0 Thread(s)
Quoted: 123 Post(s)
Liked: 173
TrueRTA vs RoomEQ wizard -- any reason other than cost to go with one vs the other?
krabapple is offline  
post #107 of 358 Old 11-27-2007, 01:05 PM
AVS Addicted Member
 
krasmuzik's Avatar
 
Join Date: Oct 1999
Location: NewPort, VA
Posts: 11,270
Mentioned: 0 Post(s)
Tagged: 0 Thread(s)
Quoted: 0 Post(s)
Liked: 11
I am not commenting on TrueRTA bugs - been a while since I used it - but I thought it was one of the better RTA's with a goal of measurement and generation precision.

But I think you have a fundamental misunderstanding about acoustic measures.

Are you expecting SPL measures to be spectral density - in which case the frequency resolution does not matter and you would get the same results?

A partial octave measure is something different, it is indeed a lesser SPL if you measure a finer octave fraction of the same source. This is simply because a larger fraction has more frequencies in it. Imagine that you have an orchestra of tuning forks each playing only one frequency. If they all play their frequency together - don't you think it would be louder than if only one frequency was played? Look more closely at the spectrum of a sine wave - it still contains energy at other frequencies! One would have to compute the RTA SPL values from the underlying FFT data to figure out if those increasing numbers are correct or not - but I would expect them to increase as you included more frequencies by increasing the bandwidth of the measure. Even if you had a highly accurate sign wave generator making an electronic measure with a very quiet noise floor - it is a fundamental to windowed DSP that you cannot measure a pure sign wave - to do so would require an infinite measure. You are also measuring the spectrum of the window you used to take a finite measure - and windows vary in terms of frequency spreading and noise floors. This is even more true with real instruments in real rooms - both of which have modal resonances and noise floors - it is impossible to play pure sinewaves even with tuning forks because the pure signal gets corrupted by the room.

This is a feature of acoustics and DSP - it is the way the physics and engineering work - it is not a bug to be fixed! TrueRTA may have real bugs - but that ain't one of them! As a professional I would be PO if the SPL did not change when I vary the octave fraction - a good sign there is a bug!

Anyways if you are needing a tool for professional work - shouldn't you pay for one that has a professional price so you can demand fixes and enhancements on your schedule? Good as TrueRTA may be - you can only expect so much for the Benjamin it cost....


Quote:
Originally Posted by bgavin View Post

I have found a critical data error bug in the Level 4 TrueRTA v3.3.3 RTA Octave Resolution display.

The on-screen and exported data points are invalid for all resolutions lower than 1/24 octave.

The user takes a measurement which is present in the Workbench.
When the user selects different RTA Resolution, i.e. 1/3 Octave, 1/6 Octave, the data values change.

The measurement has not changed. TrueRTA is changing the data point SPL values as it changes octave resolution.

This is dead wrong.

The bug is demonstrated by using 80 Hz as the sample frequency because 80 Hz is present in all octave resolutions except for 1 Octave.

In this example, a 100 Hz sine wave measurement was taken at 1/24 octave resolution.
Below are the results at 80 Hz.


1/24 Octave: 35.22 dB
1/12 Octave: 38.11 dB
1/06 Octave: 40.66 dB
1/03 Octave: 43.95 dB
1/01 Octave: 50.47 dB


Exporting the Workbench verifies the onscreen dB values match the text file data.
The 1-octave resolution does not export 80 Hz, so only the screen point was used.

Every SPL data point on both on-screen and exported values are corrupt at all resolutions lower than 1/24.

krasmuzik is offline  
post #108 of 358 Old 11-27-2007, 01:41 PM
Member
 
jonash72's Avatar
 
Join Date: Nov 2007
Posts: 17
Mentioned: 0 Post(s)
Tagged: 0 Thread(s)
Quoted: 0 Post(s)
Liked: 10
Quote:
Originally Posted by carbuff View Post

I wonder if the problem is the quality of the power that is provided over the 2 different machines' USB ports?

I will try to plug my MobilePre into my desktop and see how it calibrates. I haven't tried that before.

Also, again, does calibrating the line-out to line-in make sense if you are in-fact using the Microphone input? What are you calibrating in that case?

Well, I guess you are right, I mean I would actually like to be able to calibrate only the input, but, I dont think there is a way?!

Actually, when I think about it....could it get WORSE when I do a system cal the way it is described? I mean, let's assume that the output is real nasty, but the input is just fine. So now I get a calibration that will acount for a nasty output, of which i use none. But my measured response will still take into account a nasty output, even if there isn't one...

/Jonas
jonash72 is offline  
post #109 of 358 Old 11-27-2007, 06:48 PM
Member
 
carbuff's Avatar
 
Join Date: Dec 2002
Posts: 115
Mentioned: 0 Post(s)
Tagged: 0 Thread(s)
Quoted: 0 Post(s)
Liked: 11
Quote:
Originally Posted by jonash72 View Post

Well, I guess you are right, I mean I would actually like to be able to calibrate only the input, but, I dont think there is a way?!

Actually, when I think about it....could it get WORSE when I do a system cal the way it is described? I mean, let's assume that the output is real nasty, but the input is just fine. So now I get a calibration that will acount for a nasty output, of which i use none. But my measured response will still take into account a nasty output, even if there isn't one...

/Jonas

That was the rationale that I came to when I decided to try and include my preamp in the calibration loop.

Digital out from PC -> PreAmp Digital In -> PreAmp Analog Line Out -> Analog Line In on PC Soundcard

That seems like the right way to do the calibration to me. But, in the MobilePre, that doesn't include the Mic In circuit, so I'm unsure whether the calibration is doing me any good...

I need to either drag my desktop into my den or move my preamp into my office to connect my MobilePre to the desktop and see if the calibration works any better...
carbuff is offline  
post #110 of 358 Old 11-27-2007, 11:08 PM
Member
 
jonash72's Avatar
 
Join Date: Nov 2007
Posts: 17
Mentioned: 0 Post(s)
Tagged: 0 Thread(s)
Quoted: 0 Post(s)
Liked: 10
Quote:
Originally Posted by carbuff View Post

That was the rationale that I came to when I decided to try and include my preamp in the calibration loop.

Digital out from PC -> PreAmp Digital In -> PreAmp Analog Line Out -> Analog Line In on PC Soundcard

That seems like the right way to do the calibration to me. But, in the MobilePre, that doesn't include the Mic In circuit, so I'm unsure whether the calibration is doing me any good...

I need to either drag my desktop into my den or move my preamp into my office to connect my MobilePre to the desktop and see if the calibration works any better...

I think it may well have something to do with the USB bus power, because when I tried to calibrate without the AC adapter plugged into the wall (we have 220V/50Hz in Sweden) it looked even worse.

I would personally skip the calibration if it didnt look as bad as it does from the beginning.

On my stationary PC, the response through the soundcard is very flat to start with, probbaly within 1dB across the range. With the Laptop, it's not within 10dB.....

/Jonas
jonash72 is offline  
post #111 of 358 Old 11-28-2007, 07:51 AM
Member
 
bgavin's Avatar
 
Join Date: Nov 2007
Location: Orangevale, CA
Posts: 102
Mentioned: 0 Post(s)
Tagged: 0 Thread(s)
Quoted: 0 Post(s)
Liked: 11


This is the octave resolution bug in visual form. I loaded a project into the Workbench and took two screen shots: one at 1/24 and the other at 1/3 octave. The data is the same project in both cases.

One is right, one is wrong. Which one?

Quote:


Let's just refund your purchase and be done with this. How would you like to receive the refund? We can credit your card or send you a check. If you want a credit to your card then please provide a current expiration date for the original card. Please let me know your preference. Life is too short for this sort of nonsense.

John

The author is now pressing me to take a refund. I have declined the refund.

First, a refund gets him off the hook for fixing the bugs. Next and more subtle, it removes my right to continue reporting bugs in TrueRTA because I would no longer be a licensed user.

I replied that I do not want a refund, and that I will be entirely happy when the bugs are fixed. I will continue to report new bugs as I discover them. I have found another bug but not yet reported it. It is a very minor one with the file handling routines for project files. I will post it here when time permits.

It is obvious now the author's ego will not allow him to resolve my complaints. Therefore, the only way to get the bugs fixed will be for other users to test their systems and make bug reports. I am assembling a PDF that details all the bugs and how to test for them. If sufficient owners report these problems, the author will have to investigate and correct them.

All of the above is such a shame... TrueRTA is just exactly what I need once the bugs are fixed.

My test bench is a Dell Inspiron laptop running XP Pro. If you have Vista, all bets are off. IMO, wipe it clean and install XP (I own a computer firm). My USB interface is the Edirol UA-25 which provides phantom power to my Superlux mic, which uses the same capsule and calibration file as the Behringer mic.

This interface produces no more than 0.25v maximum output, so it won't drive a power amp to full power without an intermediate line amplifier. I use a Rane for this. I notice no improvement or degradation when using either a powered USB hub or an external +48v phantom supply. The Edirol works fine.

I use the TRTA signal generator because it allows for very fine control over the output voltage. This is far more sensitive than adjusting knobs. I do all my 8-ohm speaker measurements at 2.83 volts, and the generator dB setting allows me to dial this in exactly on my DVOM.

It is very important to follow ALL the calibration steps outlined here. TrueRTA is quite sensitive to mis-calibration. I suspect the data porting bug detailed above is somehow tied into the calibration file. The response of PC grade sound cards and onboard circuits requires TRTA calibration.

I have access to a Mobile-Pre device, but have not tested it. The Edirol box is smaller and does exactly what I require. If anybody needs assistance, please ask. I have been working TRTA a lot, and will offer whatever assistance is within my range of knowledge.
bgavin is offline  
post #112 of 358 Old 11-28-2007, 08:03 AM
AVS Special Member
 
krabapple's Avatar
 
Join Date: Apr 2003
Location: in a state bordered by Kentucky and Maine
Posts: 5,290
Mentioned: 0 Post(s)
Tagged: 0 Thread(s)
Quoted: 123 Post(s)
Liked: 173
one of the bugs you reported is not a bug, for reasons krazmusic explained. And from John's email it appears there has been some friction between the two of you in the emails you haven't shown.
krabapple is offline  
post #113 of 358 Old 11-28-2007, 10:22 AM
Member
 
John L. Murphy's Avatar
 
Join Date: Apr 2002
Posts: 23
Mentioned: 0 Post(s)
Tagged: 0 Thread(s)
Quoted: 0 Post(s)
Liked: 10
Hello TrueRTA users!

Bruce is reporting measurement results that he thinks are the result of "bugs" in TrueRTA. I will address his complaints one at a time. I take all bug reports seriously as they help to improve the product.

Quote:
Originally Posted by bgavin View Post

I am a 33+ years professional programmer, and the corollary to this is a feature is a bug with useful side effects. This is the sort of denial one expects from Microsoft. It does nothing to correct the problem, so let's please stay focused on the bug.

Here's the first problem restated:
1) TRTA geneartes a 100 Hz sine wave
2) Separate SPL meter reads 105 SPL
3) TRTA on-screen meter reads 106 SPL
4) TRTA on-screen data point reads 105 SPL
5) Export to TXT shows 100 Hz at 105 SPL

This is a point measurement, not broad band. The sine wave is 40dB higher than background. If TRTA is accumulating across the entire spectrum, it is still hearing 100 Hz at 40dB higher intensity than background.

I always calibrate TRTA to the SPL meter.
Do I calibrate TRTA to the Screen data point, or Screen Meter value?
Question: one is wrong, one is correct. Which one?


What Bruce is reporting here as a "bug" is actually normal behavior for any spectrum analyzer. Let me explain...again, and in more detail this time.

There are two distinct measurements being made by TrueRTA. There is a Narrowband measurement and a Broadband measurement. It is normal for them to be different. Sometimes the difference is small and sometimes it is large depending on the signal being measured.

The Broadband measurement is the reading from the TrueRTA SPL meter. This meters all the audio signals from 20 Hz to 20 kHz. The external SPL meter is also making a broadband measurement.

The Narrowband measurement is the reading taken from the individual RTA bar at 100 Hz. This reading only represents the energy within this narrow 1/24th octave wide band of frequencies.

Even though the narrow band at 100 Hz contains most of the measured energy, opening the bandwidth of the measurement to the full audio spectrum will add a slight bit more energy from all the additional frequency bands resulting in a higher SPL reading. This additional energy that is included in the broadband measurement is the difference between the readings of 105 vs. 106 dB SPL. This difference is perfectly normal and fully expected by those experienced with such measurements.

Note: When you perform TrueRTA's SPL calibration TrueRTA's SPL reading will instantly be adjusted to match the SPL of your calibration source. Most often this is a mic calibrator placed over the mic to be calibrated but you can also calibrate from another SPL meter. Just be sure to use an "unweighted" setting on your external meter when using it for calibration.

For those who want a little more depth here is a simple mathematical example showing how the two measurements are different:

Let's say we have one frequency "bin" with a signal level of 1.0 V. Define this level as 0 dB. Adjacent this bin are five bins on either side with "noise" at a signal level of .1 V (-20 dB).

The Narrowband measurement in this case would be the signal level of the single central band or simply 1.0 V or 0 dB. Let's name the Narrowband signal level "N".

N = 1.0 Volts = 0 dB


The Broadband measurement would consist of the combination of all the frequency bins. Let's name the Broadband measurement "B" and calculate it's value.

B = Sqrt(L1*L1 + L2*L2 + L3*L3 + L4*L4 + L5*L5 +L6*L6 +L7*L7 +L8*L8 + L9*L9 +L10*L10 + L11*L11 )

B = Sqrt( 0.1*0.1 + 0.1*0.1 +... + 1.0 +...+ 0.1*0.1 +0.1*0.1)

Where L1, L2 etc. are the signal levels at the individual frequency bins.


B = Sqrt(.01 + .01 + .01 + .01 + .01 + 1.0 + .01 + .01 + .01 + .01 + .01)

(note the five .01 signals on either side of the central 1.0 signal)

B = Sqrt( .05 + 1.0 + .05 )

B = Sqrt( 1.10)

B = 1.0499...

in dB

B = 20* Log (1.0499)

B = 0.414 dB

So in this simplified exmple we see a 0.414 dB rise in signal level for the wideband measurement versus the narrowband, single bin, measurement. The additional frequency bins of a broadband measurement will always increase the signal level.

You could also do a benchtop experiment with a variable width filter that would make the effect of bandwidth on signal level quite clear. Imagine this, you feed a pink noise source through a variable bandwidth filter and play the output signal over your speakers. Turn the volume up to say 90 dB SPL with the full bandwidth pink noise. Next start sweeping the filter (perhaps a crossover) upward from 20 Hz so that you start chopping off the low frequencies. The apparent sound level would decrease as would the reading of an external SPL meter. Narrowing the bandwith has lowered the signal level.

I hope from this it is clear that a single frequency measurement on the RTA will always be somewhat lower than the broadband SPL measurement seen at the SPL meter at the far left. Only in the ideal case where the noise in the adjacent bins was absolutely zero would the two measurements be the same.

Regards,

John

John L. Murphy
Physicist/Audio Engineer
True Audio

To view links or images in signatures your post count must be 0 or greater. You currently have 0 posts.
John L. Murphy is offline  
post #114 of 358 Old 11-28-2007, 11:44 AM
Member
 
John L. Murphy's Avatar
 
Join Date: Apr 2002
Posts: 23
Mentioned: 0 Post(s)
Tagged: 0 Thread(s)
Quoted: 0 Post(s)
Liked: 10
Hello TrueRTA users!

Bruce reports measurement results that he feels are the result of "bugs" in TrueRTA. I will address his complaints one at a time. I take all bug reports seriously as they help to improve the product.

Quote:
Originally Posted by bgavin View Post

I am a 33+ years professional programmer, and the corollary to this is “a feature is a bug with useful side effects.” This is the sort of denial one expects from Microsoft. It does nothing to correct the problem, so let's please stay focused on the bug.

Here’s the first problem restated:
1) TRTA geneartes a 100 Hz sine wave
2) Separate SPL meter reads 105 SPL
3) TRTA on-screen meter reads 106 SPL
4) TRTA on-screen data point reads 105 SPL
5) Export to TXT shows 100 Hz at 105 SPL

This is a point measurement, not broad band. The sine wave is 40dB higher than background. If TRTA is accumulating across the entire spectrum, it is still hearing 100 Hz at 40dB higher intensity than background.

I always calibrate TRTA to the SPL meter.
Do I calibrate TRTA to the Screen data point, or Screen Meter value?
Question: one is wrong, one is correct. Which one?


This is perfectly normal behavior for any spectrum analyzer. Let me try to explain... in more detail this time.

There are two distinct measurements being made by TrueRTA. There is a Narrowband measurement and a Broadband measurement. It is normal for them to be different. Sometimes the difference is small and sometimes it is large depending on the nature of the signal being measured.

The Broadband measurement is the reading from the TrueRTA SPL meter. This meters all the audio signals from 20 Hz to 20 kHz. The external SPL meter is also making a broadband measurement.

The Narrowband measurement is the reading taken from the individual RTA bar at 100 Hz. This reading only represents the energy within this narrow 1/24th octave wide band of frequencies.

Even though the narrow band at 100 Hz contains most of the measured energy, opening the bandwidth of the measurement to the full audio spectrum will add a slight bit more energy from all the additional frequency bands resulting in a higher SPL reading. This additional energy that is included in the broadband measurement is the difference between the readings of 105 vs. 106 dB SPL. This difference is perfectly normal and fully expected by those experienced with such measurements.

Note: When you perform TrueRTA's SPL calibration TrueRTA's SPL reading will instantly be adjusted to match the SPL of your calibration source. Most often this is a mic calibrator placed over the mic to be calibrated but you can also calibrate from another SPL meter. Just be sure to use an "unweighted" setting on your external meter when using it for calibration.

For those who want a little more depth here is a simple mathematical example showing how the two measurements are different:

Let's say we have one frequency "bin" with a signal level of 1.0 V. Define this level as 0 dB. Adjacent this bin are five bins on either side with "noise" at a signal level of .1 V (-20 dB).

The Narrowband measurement in this case would be the signal level of the single central band or simply 1.0 V or 0 dB. Let's name the Narrowband signal level "N".

N = 1.0 Volts = 0 dB

The Broadband measurement would consist of the combination of all the frequency bins. Let's name the Broadband measurement "B" and calculate it's value.

B = Sqrt(L1*L1 + L2*L2 + L3*L3 + L4*L4 + L5*L5 +L6*L6 +L7*L7 +L8*L8 + L9*L9 +L10*L10 + L11*L11 )

B = Sqrt( 0.1*0.1 + 0.1*0.1 +... + 1.0 +...+ 0.1*0.1 +0.1*0.1)

Where L1, L2 etc. are the signal levels at the individual frequency bins.

B = Sqrt(.01 + .01 + .01 + .01 + .01 + 1.0 + .01 + .01 + .01 + .01 + .01)

(note the five .01 signals on either side of the central 1.0 signal)

B = Sqrt( .05 + 1.0 + .05 )

B = Sqrt( 1.10)

B = 1.0499...

in dB

B = 20* Log (1.0499)

B = 0.414 dB

So in this simplified exmple we see a 0.414 dB rise in signal level for the wideband measurement versus the narrowband, single bin, measurement. The additional frequency bins of a broadband measurement will always increase the signal level.

You could also do a benchtop experiment with a variable width filter that would make the effect of bandwidth on signal level quite clear. Imagine this, you feed a pink noise source through a variable bandwidth filter and play the output signal over your speakers. Turn the volume up to say 90 dB SPL with the full bandwidth pink noise. Next start sweeping the filter (perhaps a crossover) upward from 20 Hz so that you start chopping off the low frequencies. The apparent sound level would decrease as would the reading of an external SPL meter. Narrowing the bandwith has lowered the signal level.

I hope from this it is clear that a single frequency measurement on the RTA will always be somewhat lower than the broadband SPL measurement seen at the SPL meter at the far left. Only in the ideal case where the noise in the adjacent bins was absolutely zero would the two measurements be the same.

Regards,

John

John L. Murphy
Physicist/Audio Engineer
True Audio

To view links or images in signatures your post count must be 0 or greater. You currently have 0 posts.
John L. Murphy is offline  
post #115 of 358 Old 11-28-2007, 12:58 PM
Member
 
bgavin's Avatar
 
Join Date: Nov 2007
Location: Orangevale, CA
Posts: 102
Mentioned: 0 Post(s)
Tagged: 0 Thread(s)
Quoted: 0 Post(s)
Liked: 11
Quote:


I will endure no more of your unpleasantness.

Your license to use TrueRTA is hereby officially revoked. The full purchase price of $99.95 has been refunded to your VISA card ending with the digits 0190. You are directed to uninstall TrueRTA from all computers on which you have it is installed.

John

This does nothing to address the 10dB difference between 1/3 and 1/24 octave resolution.

This does nothing to address the data portability bug, where the .RTA data points are altogether different when moved to a different machine.

Yes indeed there is friction. I sent a bug report and asked for the favor of a reply. After a week, I got none, so I called. Sharon told me the bug report was still in the inbox, unread. It was forwarded directly to John.

John claims my mail server rejected many of his attempts. Probably, if his provider is on the black hole list. But.. I provided two email addresses for contact, and when contact was made, it was hostile.

As a customer, I don't like being blown off. I have found serious and repeatable data errors in TrueRTA and have been repeatedly blown off. John has revoked my user license which allows him to glibly ignore these bugs, and simultaneously prevents me from reporting new ones.

All I want is the bugs fixed. Not a bunch of math and hogwash.
bgavin is offline  
post #116 of 358 Old 11-28-2007, 12:58 PM
Member
 
John L. Murphy's Avatar
 
Join Date: Apr 2002
Posts: 23
Mentioned: 0 Post(s)
Tagged: 0 Thread(s)
Quoted: 0 Post(s)
Liked: 10
Here is Bruce's next bug report along with my explanation of why the observed behavior is not really a bug but rather normal behavior for a variable resolution RTA.


Quote:
Originally Posted by bgavin View Post

I have found a critical data error bug in the Level 4 TrueRTA v3.3.3 RTA Octave Resolution display.

The on-screen and exported data points are invalid for all resolutions lower than 1/24 octave.

The user takes a measurement which is present in the Workbench.
When the user selects different RTA Resolution, i.e. 1/3 Octave, 1/6 Octave, the data values change.

The measurement has not changed. TrueRTA is changing the data point SPL values as it changes octave resolution.

This is dead wrong.

The bug is demonstrated by using 80 Hz as the sample frequency because 80 Hz is present in all octave resolutions except for 1 Octave.

In this example, a 100 Hz sine wave measurement was taken at 1/24 octave resolution.
Below are the results at 80 Hz.


1/24 Octave: 35.22 dB
1/12 Octave: 38.11 dB
1/06 Octave: 40.66 dB
1/03 Octave: 43.95 dB
1/01 Octave: 50.47 dB


Exporting the Workbench verifies the onscreen dB values match the text file data.
The 1-octave resolution does not export 80 Hz, so only the screen point was used.

Every SPL data point on both on-screen and exported values are corrupt at all resolutions lower than 1/24.


TrueRTA is giving correct results. As the resolution is increased from 1 octave to 1/24th octave each band is measuring less and less of the everpresent broadband background noise and the level of each bar drops accordingly. The overall effect is that at higher resolutions you can see increasing detail at lower and lower levels. For example, each bar of the 1 octave display bar contains a higher level of energy than an individual bar of the 1/24th octave display. This is reflected in the higher level of the noise floor in the 1 octave measurements.

Bruce is measuring a 100 Hz signal and is surprised that the level of the 80 Hz band goes down as the resolution increases. But this is actually perfectly normal and expected bahavior. The higher resolution measurement reveals a lower noise floor. TrueRTA is reporting the levels of both the 100 Hz signal and the 80 Hz signal correctly.

In the following sequence you can see how a pink noise measurement drops in level as the resolution is increased. Meanwhile, the broadband signal level would be constant and independent of this change in resolution of the analyzer.





This is perfectly normal behavior for any variable resolution spectrum analyzer. TrueRTA is performing just as it should. Any other behavior would be incorrect.

In summary, the shift in the noise floor to lower and lower levels as the resolution of the analyzer is increased is proper behavior for any spectrum analyzer.

Regards,

John

John L. Murphy
Physicist/Audio Engineer
True Audio

To view links or images in signatures your post count must be 0 or greater. You currently have 0 posts.
John L. Murphy is offline  
post #117 of 358 Old 11-28-2007, 01:20 PM
Member
 
bgavin's Avatar
 
Join Date: Nov 2007
Location: Orangevale, CA
Posts: 102
Mentioned: 0 Post(s)
Tagged: 0 Thread(s)
Quoted: 0 Post(s)
Liked: 11


The above is two interpretations of a single trace.
The RTA was calibrated to an external SPL meter reading 92 SPL for a 100 Hz sine wave.

The 1/24 octave sweep correlates with the SPL meter at 100 Hz.
Changing resolution to 1/3 octave boosts the 100 Hz SPL reading on screen to 102 SPL.

If I used the 1/3 octave trace, it would be in error by +10dB.
bgavin is offline  
post #118 of 358 Old 11-28-2007, 01:29 PM
AVS Addicted Member
 
krasmuzik's Avatar
 
Join Date: Oct 1999
Location: NewPort, VA
Posts: 11,270
Mentioned: 0 Post(s)
Tagged: 0 Thread(s)
Quoted: 0 Post(s)
Liked: 11
Good luck finding a spectrum analyzer that defies the laws of physics and DSP that you can use in your professional work.....
krasmuzik is offline  
post #119 of 358 Old 11-28-2007, 02:37 PM
Member
 
jonash72's Avatar
 
Join Date: Nov 2007
Posts: 17
Mentioned: 0 Post(s)
Tagged: 0 Thread(s)
Quoted: 0 Post(s)
Liked: 10
Hmm, I am not sure if I remember the older versions of TrueRTA doing that, I have verified in my own version 3.3.3 that it does shift the amplitudes when switching from say 1/3rd to 1/24.

HOWEVER, I beleive this is the way it is supposed to be. Because when doing a 1/3rd octave analysis, you get 8times the number of bins in your total SPL number vs the 1/24th resolution. So, each bin in the 1/3rd octave analysis will have ALOT more energy recorded and stored, and eventually displayed.

I guess the real question may be:

How do we use TrueRTA to get the real SPL numbers? Or rather, how is this calibration procedure performed.

Personally, I dont give a rats behind about the SPL numbers, as I am only looking at the response curves, but I do see why it would be of some significance to some.

I _think_ there is probably an easy workaround for this, as it should be a fairly simple mathematical excercise to get the correct SPL numbers for any resolution.

So, I am pretty sure that John will either tell us what our problem, or, he will put a new version to download for us all.

/Jonas

Quote:
Originally Posted by bgavin View Post



The above is two interpretations of a single trace.
The RTA was calibrated to an external SPL meter reading 92 SPL for a 100 Hz sine wave.

The 1/24 octave sweep correlates with the SPL meter at 100 Hz.
Changing resolution to 1/3 octave boosts the 100 Hz SPL reading on screen to 102 SPL.

If I used the 1/3 octave trace, it would be in error by +10dB.

jonash72 is offline  
post #120 of 358 Old 11-28-2007, 03:08 PM
Member
 
bgavin's Avatar
 
Join Date: Nov 2007
Location: Orangevale, CA
Posts: 102
Mentioned: 0 Post(s)
Tagged: 0 Thread(s)
Quoted: 0 Post(s)
Liked: 11
Quote:
Originally Posted by jonash72 View Post

HOWEVER, I beleive this is the way it is supposed to be. Because when doing a 1/3rd octave analysis, you get 8times the number of bins in your total SPL number vs the 1/24th resolution. So, each bin in the 1/3rd octave analysis will have ALOT more energy recorded and stored, and eventually displayed.

Question for you: did the sound get 10dB louder by changing chart resolution?

The end result of RTA is not how many bins are filled, nor how many angels dance on the head of a pin. The result is supposed to show you the SPL of the signal level. 1/24 is accurate, 1/3 is inflated +10dB.
bgavin is offline  
Reply Audio theory, Setup and Chat

User Tag List

Thread Tools
Show Printable Version Show Printable Version
Email this Page Email this Page


Forum Jump: 

Posting Rules  
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts

BB code is On
Smilies are On
[IMG] code is On
HTML code is Off
Trackbacks are Off
Pingbacks are Off
Refbacks are Off