Login / Register
 
Before posting your measurement results
New Reply
Subscribe
Jens Eklund
Thread Starter
#61
7th December 2012
Old 7th December 2012
  #61
Lives for gear
 
Jens Eklund's Avatar
 
Joined: Oct 2009
Location: Stockholm
Posts: 4,688

Thread Starter
Jens Eklund is offline
Quote:
Originally Posted by DanDan View Post
Simply not true.




DD

Are you going to start again?
#62
7th December 2012
Old 7th December 2012
  #62
Gear nut
 
Joined: Sep 2006
Location: Waterloo, ON
Posts: 125

liscio is offline
Wow, lots of flailing about in here.

So, there are two fundamental issues you guys seem to be talking about here. One is the audio capture not giving you a 'strong enough' peak, and the other is the exported data from FuzzMeasure.

As for the first issue, it's a red herring. You can push that level so hard that you're theoretically "perfectly captured" by the system, and you still won't get "high enough" impulse responses in certain situations. Think about a 'perfect' subwoofer that can reproduce 0Hz to 100Hz, but it cuts off after 100Hz. The resulting impulse response from the deconvolution will not have a peak of 0dB, because there's missing energy from the 100Hz->nyquist range.

So, let's try to address the second one, because that's what matters to you folks most.

When at 16-bit, yes—the output will get truncated once it falls into the noise floor. That problem is "solved" by changing to 24- or 32-bit exports. However, when viewed by other packages, it seems to create trouble because they apparently don't have vertical scale controls? So, there's another way…

The simplest thing to do is to just Normalize the impulse response in FuzzMeasure before it is exported. Just choose Measurement > Normalize from the main menu (or right-click the measurement record and choose 'Normalize'). Once that measurement is normalized, exported signals will also be normalized to 0dB peaks. That way, you can still export at 16-bit with no worries about truncation.

Now, normalizing the measurement will not always do what you want in the graphs. If you're viewing the impulse as an Envelope Time Curve, you can end up with the peak above 0dB. In that case, you should right-click the ETC graph and choose Normalize in the context menu. Alternatively, choose Impulse > Normalize from the main menu.

Hope this helps!
__________________
http://www.SuperMegaUltraGroovy.com
Acoustic Measurement Software for Mac OS X. http://www.FuzzMeasure.com
#63
7th December 2012
Old 7th December 2012
  #63
Gear Guru
 
DanDan's Avatar
 
Joined: Aug 2003
Location: Cork Ireland
Posts: 10,950

DanDan is offline
Quote

Jens, those statements are both yours and they directly contradict each other. I contributed nothing.

Quote:
Why would you want to look at an un-normalized ETC?
Why or why not? I suppose it gives some indication of the quality of level setting. e.g. A 0dBFS not normalised ETC strongly suggests clipping as things stand. It is an option or an action in the two popular softwares. A choice. I don't think we can critique Toyota if people chose to drive around in third gear.

Quote:
Well, anyway; whatever levels are reported within the applications for various plots is not really relevant. It´s the low level of the recorded/exported IR file that is causing the problems seen.
EDI I think it is necessary for the software to show internal levels, but I do agree that we should recommend Normalise before Export.
I am thinking 24 Bit also, assuming that REW, the popular one, can import these without truncation.

EDIT, synchronous posting... Thank you Chris, absolutely helps, exactly what I had guessed and assumed. But at tad more succinct! I hope John has a thought or two for us also.

DD

Last edited by DanDan; 7th December 2012 at 04:18 PM.. Reason: To eliminate the need for more posts!
Jens Eklund
Thread Starter
#64
7th December 2012
Old 7th December 2012
  #64
Lives for gear
 
Jens Eklund's Avatar
 
Joined: Oct 2009
Location: Stockholm
Posts: 4,688

Thread Starter
Jens Eklund is offline
Quote:
Originally Posted by liscio View Post
Wow, lots of flailing about in here.

So, there are two fundamental issues you guys seem to be talking about here. One is the audio capture not giving you a 'strong enough' peak, and the other is the exported data from FuzzMeasure.

As for the first issue, it's a red herring. You can push that level so hard that you're theoretically "perfectly captured" by the system, and you still won't get "high enough" impulse responses in certain situations. Think about a 'perfect' subwoofer that can reproduce 0Hz to 100Hz, but it cuts off after 100Hz. The resulting impulse response from the deconvolution will not have a peak of 0dB, because there's missing energy from the 100Hz->nyquist range.

So, let's try to address the second one, because that's what matters to you folks most.

When at 16-bit, yes—the output will get truncated once it falls into the noise floor. That problem is "solved" by changing to 24- or 32-bit exports. However, when viewed by other packages, it seems to create trouble because they apparently don't have vertical scale controls? So, there's another way…

The simplest thing to do is to just Normalize the impulse response in FuzzMeasure before it is exported. Just choose Measurement > Normalize from the main menu (or right-click the measurement record and choose 'Normalize'). Once that measurement is normalized, exported signals will also be normalized to 0dB peaks. That way, you can still export at 16-bit with no worries about truncation.

Now, normalizing the measurement will not always do what you want in the graphs. If you're viewing the impulse as an Envelope Time Curve, you can end up with the peak above 0dB. In that case, you should right-click the ETC graph and choose Normalize in the context menu. Alternatively, choose Impulse > Normalize from the main menu.

Hope this helps!
Hi Chris and thanks for joining in despite rough weather.

So, just to make sure; if the level indicator in Fuzz says -1 dBFS (or whatever), the level of the recorded file is also -1 dBFS? If people just learn to set the levels properly there´s no issue in other words, even if recording at 16 bits (but even if recording at 24 bits, you still want to get away from the noise floor of the AD so proper gain structure is never a bad thing).

I don´t know how REW behaves in this regard but ARTA indicates what gets recorded.


EDIT:
Quote:
Originally Posted by DanDan View Post
I am thinking 24 Bit also, assuming that REW, the popular one, can import these without truncation.
Please read my posts:
Before posting your measurement results
Jens Eklund
Thread Starter
#65
7th December 2012
Old 7th December 2012
  #65
Lives for gear
 
Jens Eklund's Avatar
 
Joined: Oct 2009
Location: Stockholm
Posts: 4,688

Thread Starter
Jens Eklund is offline
Quote:
Originally Posted by DanDan View Post
Jens, those statements are both yours and they directly contradict each other. I contributed nothing.
?
#66
7th December 2012
Old 7th December 2012
  #66
Gear Guru
 
DanDan's Avatar
 
Joined: Aug 2003
Location: Cork Ireland
Posts: 10,950

DanDan is offline
Bugs

Quote:
So just because I´ve spotted a potential bug in an application; I need to somehow state that all other similar application might also have bugs ...

One could get in to the possible difference between potentially spotting a bug, and spotting a potential bug.

There is a the vastly more popular commonly used application REW. It exhibits the same level behaviour as FM. Omitting the vastly prominent one and singling out the much rarer and unfamiliar one, and suggesting it has a global 'problem' seemed both unfair and untrue to me. I posted here to clarify that from my point of view, using FM and REW, there is nothing I would call 'bug' or 'problem' in either.

DD
Jens Eklund
Thread Starter
#67
7th December 2012
Old 7th December 2012
  #67
Lives for gear
 
Jens Eklund's Avatar
 
Joined: Oct 2009
Location: Stockholm
Posts: 4,688

Thread Starter
Jens Eklund is offline
Quote:
Originally Posted by DanDan View Post
There is a the vastly more popular commonly used application REW. It exhibits the same level behaviour as FM. Omitting the vastly prominent one and singling out the much rarer and unfamiliar one, and suggesting it has a global 'problem' seemed both unfair and untrue to me. I posted here to clarify that from my point of view, using FM and REW, there is nothing I would call 'bug' or 'problem' in either.

DD
I guess time will tell.
#68
7th December 2012
Old 7th December 2012
  #68
Gear nut
 
Joined: Sep 2006
Location: Waterloo, ON
Posts: 125

liscio is offline
Quote:
Originally Posted by Jens Eklund View Post
Hi Chris and thanks for joining in despite rough weather.

So, just to make sure; if the level indicator in Fuzz says -1 dBFS (or whatever), the level of the recorded file is also -1 dBFS? If people just learn to set the levels properly there´s no issue in other words, even if recording at 16 bits (but even if recording at 24 bits, you still want to get away from the noise floor of the AD so proper gain structure is never a bad thing).

I don´t know how REW behaves in this regard but ARTA indicates what gets recorded.
The level indicator in FuzzMeasure should be showing the right thing, yes. It's just that the nature of the swept sine won't necessarily give you an impulse peak at 0dB because of what the impulse "represents".

I put a set of videos together a short while ago to help folks figure out the whole process of setting levels here:

FuzzMeasure Basics - YouTube

It seems to be helping me weed out a lot of basic setup problems lately.
#69
7th December 2012
Old 7th December 2012
  #69
Gear maniac
 
Joined: May 2009
Posts: 160

JohnPM is offline
Hi, a few comments on REW bit depths etc.

JavaSound on Windows and OS X only supports 16-bit sample depth, so the raw audio data captured and generated by REW when using the Java drivers on Windows and on OS X, are 16-bit.

When using ASIO on Windows 24-bit data is supported provided the ASIO control panel is set for 24-bit or higher resolution.

The bit depth and sample rate REW is using is shown at the bottom left of the main window.

REW converts audio data to 32-bit floats as it is captured. Processing is done in 64-bit doubles. The calculated impulse response is stored as 32-bit floats.

Exported impulse responses convert the 32-bit float IR data to fixed point data in the bit depth selected in the export dialog (16, 24 or 32-bit). For impulse response export from REW I recommend ticking the option to normalise the output to ensure the exported IR captures the full dynamic range available in the impulse for the the export bit depth selected.

Imported impulse response are converted to 32-bit float as they are loaded, their underlying precision depends on the bit depth the WAV or AIFF being imported was stored with.

The most common mistake when moving impulse responses between applications is exporting the data without normalising it and compounding that by using a 16-bit format for the export. That throws away a lot of resolution, which will be apparent when looking at the imported IR and plots derived from it, such as ETC and waterfalls.
__________________
REW Author
Jens Eklund
Thread Starter
#70
7th December 2012
Old 7th December 2012
  #70
Lives for gear
 
Jens Eklund's Avatar
 
Joined: Oct 2009
Location: Stockholm
Posts: 4,688

Thread Starter
Jens Eklund is offline
Quote:
Originally Posted by JohnPM View Post
Hi, a few comments on REW bit depths etc.

JavaSound on Windows and OS X only supports 16-bit sample depth, so the raw audio data captured and generated by REW when using the Java drivers on Windows and on OS X, are 16-bit.

When using ASIO on Windows 24-bit data is supported provided the ASIO control panel is set for 24-bit or higher resolution.

The bit depth and sample rate REW is using is shown at the bottom left of the main window.

REW converts audio data to 32-bit floats as it is captured. Processing is done in 64-bit doubles. The calculated impulse response is stored as 32-bit floats.

Exported impulse responses convert the 32-bit float IR data to fixed point data in the bit depth selected in the export dialog (16, 24 or 32-bit). For impulse response export from REW I recommend ticking the option to normalise the output to ensure the exported IR captures the full dynamic range available in the impulse for the the export bit depth selected.

Imported impulse response are converted to 32-bit float as they are loaded, their underlying precision depends on the bit depth the WAV or AIFF being imported was stored with.

The most common mistake when moving impulse responses between applications is exporting the data without normalising it and compounding that by using a 16-bit format for the export. That throws away a lot of resolution, which will be apparent when looking at the imported IR and plots derived from it, such as ETC and waterfalls.

Hi John and thanks for joining despite the storm.


Quick note on why I choose to not recommend normalizing when exporting IRs from REW (post 24 in this thread):

Apparently, a lot of users struggle with setting appropriate gain structure, so I´ve decided to suggest not to normalize the IR at export since if done, I (or others) would not be able to spot this potential problem (low rec level) and since I suggest 24 bit export, the bit depth will still be sufficient not to cause major issues when using the exported files even is low rec levels.

In normal use, normalization prior to export (especially if 16 bit resolution) would naturally be the best option.


Sincerely Jens Eklund
Jens Eklund
Thread Starter
#71
7th December 2012
Old 7th December 2012
  #71
Lives for gear
 
Jens Eklund's Avatar
 
Joined: Oct 2009
Location: Stockholm
Posts: 4,688

Thread Starter
Jens Eklund is offline
Quote:
Originally Posted by liscio View Post
The level indicator in FuzzMeasure should be showing the right thing, yes. It's just that the nature of the swept sine won't necessarily give you an impulse peak at 0dB because of what the impulse "represents".
Do you mind telling us more?

When I record IRs (log sweeps) using ARTA, the peak level indicated by ARTA is the same as the peak dBFS level of the actual IR file.
#72
8th December 2012
Old 8th December 2012
  #72
Gear nut
 
Joined: Sep 2006
Location: Waterloo, ON
Posts: 125

liscio is offline
Quote:
Originally Posted by Jens Eklund View Post
Do you mind telling us more?

When I record IRs (log sweeps) using ARTA, the peak level indicated by ARTA is the same as the peak dBFS level of the actual IR file.
Their math must be different than mine somewhere, if that's the case. Consider the following digital connections:

Output of FuzzMeasure -> Input of AU Lab
Output of AU Lab -> Input of FuzzMeasure

AU Lab is an audio development tool from Apple that allows you to test Audio Units (AUs), which are analogous to VSTs or RTAS plug-ins on other platforms. Using a "virtual audio device" called SoundFlower, I can digitally route to and from AU Lab, and insert digital filters, reverbs, distortions, etc. in between.

Still with me?

If I have no filters enabled, and run a sweep, the level meter clips because the values are reaching 1.0/-1.0 (or 0dBFS). I get a perfect impulse response as the output. 0dB across the magnitude response graph, and a 0dB peak in the log squared impulse response. This is my Green record in the screenshot.

If I enable a high-pass filter with the Fc at 6900Hz, and what looks like a -48dB/oct slope, the level meter also clips when the sweep hits 6900Hz. However, there's a lot of "missing energy" below 6900Hz, so the impulse response is not going to peak at the level that the recording peaked at. This is my Red record in the screenshot.

Here is a screenshot showing the results of my test: Screen Shot 2012-12-08 at 9.03.47 AM.png

In conclusion, the peak of the filter measurement is at -3.5dBFS, despite the measurement hitting 0dBFS.

Does this help at all?
#73
8th December 2012
Old 8th December 2012
  #73
Gear Guru
 
DanDan's Avatar
 
Joined: Aug 2003
Location: Cork Ireland
Posts: 10,950

DanDan is offline
Facts

Thanks to John and Chris for accepting my invitation to come on here. EDIT, jeez Chris Synchronous posting!
Perhaps you would confirm for me:

My simple understanding of an IR file is that the original sweep is subtracted from the combined sound in the room.
i.e. Sweep +Speaker/Room Response MINUS Sweep = IR

If the total hits 0dBFS, it seems natural that the level would be lower with the Sweep energy removed. Any IR files I have looked at in audio software were tiny.

It does appear that ARTA does things different to FM and REW.
Perhaps it's author would explain.


DD
Jens Eklund
Thread Starter
#74
8th December 2012
Old 8th December 2012
  #74
Lives for gear
 
Jens Eklund's Avatar
 
Joined: Oct 2009
Location: Stockholm
Posts: 4,688

Thread Starter
Jens Eklund is offline
Quote:
Originally Posted by liscio View Post
Their math must be different than mine somewhere, if that's the case. Consider the following digital connections:

Output of FuzzMeasure -> Input of AU Lab
Output of AU Lab -> Input of FuzzMeasure

AU Lab is an audio development tool from Apple that allows you to test Audio Units (AUs), which are analogous to VSTs or RTAS plug-ins on other platforms. Using a "virtual audio device" called SoundFlower, I can digitally route to and from AU Lab, and insert digital filters, reverbs, distortions, etc. in between.

Still with me?

If I have no filters enabled, and run a sweep, the level meter clips because the values are reaching 1.0/-1.0 (or 0dBFS). I get a perfect impulse response as the output. 0dB across the magnitude response graph, and a 0dB peak in the log squared impulse response. This is my Green record in the screenshot.

If I enable a high-pass filter with the Fc at 6900Hz, and what looks like a -48dB/oct slope, the level meter also clips when the sweep hits 6900Hz. However, there's a lot of "missing energy" below 6900Hz, so the impulse response is not going to peak at the level that the recording peaked at. This is my Red record in the screenshot.

Here is a screenshot showing the results of my test: Screen Shot 2012-12-08 at 9.03.47 AM.png

In conclusion, the peak of the filter measurement is at -3.5dBFS, despite the measurement hitting 0dBFS.

Does this help at all?
I´m interested primarily of the peak level of the actual IR file (since if too low and 16 bits, problems appear as demonstrated above).

So if you record to FM at -1 dBFS peak level (assuming the level meter in FM is correct or by using another level meter), and then export this file; what peak level will the exported IR have?

The problem I see here, is that the majority of users seem to end up with a peak level of about -20 dBFS or lower, and this is too low if exporting at 16 bit since the decay will be "cut off" as demonstrated above. It is possible that most users are not very good at setting the rec level but I would be surprised if it was as bad as seen here.
Jens Eklund
Thread Starter
#75
8th December 2012
Old 8th December 2012
  #75
Lives for gear
 
Jens Eklund's Avatar
 
Joined: Oct 2009
Location: Stockholm
Posts: 4,688

Thread Starter
Jens Eklund is offline
I also think we can exclude that there’s something happening at export since if you look at the second FM waterfall plot in this post:
Finished treating room - graphs good enough?

You see the same “cut off” of the decay that has been observed elsewhere (probably due to truncation of low level signals), so the recording level was presumably low when the file was recorded.
#76
8th December 2012
Old 8th December 2012
  #76
Gear nut
 
Joined: Sep 2006
Location: Waterloo, ON
Posts: 125

liscio is offline
Quote:
Originally Posted by Jens Eklund View Post
So if you record to FM at -1 dBFS peak level (assuming the level meter in FM is correct or by using another level meter), and then export this file; what peak level will the exported IR have?
It depends on the content of the IR.

Quote:
The problem I see here, is that the majority of users seem to end up with a peak level of about -20 dBFS or lower, and this is too low if exporting at 16 bit since the decay will be "cut off" as demonstrated above. It is possible that most users are not very good at setting the rec level but I would be surprised if it was as bad as seen here.
Right, but we can't control what the user is measuring enough to guarantee they won't be creating an impulse that peaks at -10 or -20dBFS. Doesn't matter whether they clip or not.

Users simply need to normalize before export, or export w/ 24- or 32-bit depths, when they are transacting files with other users. That's pretty much the best way to support exchanging data with other packages without losing anything.

As for the 2nd waterfall you're showing, I'm not sure I understand what you mean by the decay getting 'cut off'. There might be two things at play here…
#77
8th December 2012
Old 8th December 2012
  #77
Gear maniac
 
Joined: May 2009
Posts: 160

JohnPM is offline
It is worth remembering that the effect the system has on a signal passing through it is the convolution of the signal and the impulse response. If the impulse response is a single sample at unity the signal will be passed through unchanged. If the captured sweep is at the same level as the test signal and has suffered no loss of bandwidth the impulse response would have unit amplitude, which would be 0dB FS, even if (for example) stimulus and response were both at -40dB. The system is the same whatever level of signal is passing through it (within its linear range) so the impulse response, which represents what the system does to signals passing through it, is not changed by the level of the signals used to measure it.

Life gets more complicated when measuring bandwidth limited systems, especially those with very limited bandwidths such as subwoofers. Even if such a system perfectly preserves the stimulus amplitude over its operating bandwidth (unity gain) its impulse response peak value will be much less than unity due to the width of the response, which increases as its bandwidth reduces. Because of that, subwoofer impulse responses can have very low peak values even when the stimulus and response levels are close to full scale. That is why I recommend that impulse responses are normalised before export.
#78
9th December 2012
Old 9th December 2012
  #78
Lives for gear
 
jim1961's Avatar
 
Joined: May 2012
Location: Texas
Posts: 1,094

jim1961 is offline
I dont know if you guys have any interest, but while your going through different measurement softwares if someone wants to tackle Daytons Omnimic, which is what I have/use, id be glad to supply data. I dont really follow the details in this discussion when describing file type descriptions and such. My ETC files are ETO file types and my FR are FRD files. Dont know if that is something that can be imported into some other software of not.

Let me know if anyone wants to see them.
Jens Eklund
Thread Starter
#79
10th December 2012
Old 10th December 2012
  #79
Lives for gear
 
Jens Eklund's Avatar
 
Joined: Oct 2009
Location: Stockholm
Posts: 4,688

Thread Starter
Jens Eklund is offline
Shure, why not.

Export the IR files as standard audio files (wav/aiff etc.) in 24 bit without normalization and note the peak level indicated by the application when recorded.
#80
10th December 2012
Old 10th December 2012
  #80
Gear Guru
 
Glenn Kuras's Avatar
 
Joined: Jul 2005
Location: Atlanta, GA
Posts: 16,612

Glenn Kuras is offline
Thanks Jim that will save me from testing it out.
#81
10th December 2012
Old 10th December 2012
  #81
Lives for gear
 
jim1961's Avatar
 
Joined: May 2012
Location: Texas
Posts: 1,094

jim1961 is offline
Quote:
Originally Posted by Jens Eklund View Post
Shure, why not.

Export the IR files as standard audio files (wav/aiff etc.) in 24 bit without normalization and note the peak level indicated by the application when recorded.
Treat me as a complete idiot when it comes to this aspect of things

I dont really understand what your asking me to do or how to do it.

The Omnimic software doesnt have an export feature per say. When you say "IR" files, please clarify what you mean. Like said before, the saved files for ETC are ETO.

----- ----- -----

Assuming I am up to the task here, I am using a V2 mic with V4.00 software for clarification of what exactly I am testing.
#82
10th December 2012
Old 10th December 2012
  #82
Lives for gear
 
SörenHjalmarsson's Avatar
 
Joined: Jul 2010
Location: Skövde, Sweden
Posts: 1,263

Send a message via Skype™ to SörenHjalmarsson
SörenHjalmarsson is offline
Quote:
Originally Posted by jim1961 View Post
When you say "IR" files, please clarify what you mean.
The Impulse Response.
#83
10th December 2012
Old 10th December 2012
  #83
Lives for gear
 
jim1961's Avatar
 
Joined: May 2012
Location: Texas
Posts: 1,094

jim1961 is offline
Quote:
Originally Posted by SörenHjalmarsson View Post
The Impulse Response.
I dont have any files called "IR" files, thus the question remains.
Jens Eklund
Thread Starter
#84
10th December 2012
Old 10th December 2012
  #84
Lives for gear
 
Jens Eklund's Avatar
 
Joined: Oct 2009
Location: Stockholm
Posts: 4,688

Thread Starter
Jens Eklund is offline
Quote:
Originally Posted by jim1961 View Post
Treat me as a complete idiot when it comes to this aspect of things

I dont really understand what your asking me to do or how to do it.

The Omnimic software doesnt have an export feature per say. When you say "IR" files, please clarify what you mean. Like said before, the saved files for ETC are ETO.

----- ----- -----

Assuming I am up to the task here, I am using a V2 mic with V4.00 software for clarification of what exactly I am testing.

If the software cannot export the data in any way (sounds a bit odd though); it´s the end of that road.

I don´t have access to that software and I´ve only checked the “manual” quickly, but unless you can somehow export the IR (Impulse Response) file; the data sourced using this software will only be accessible by this application.
#85
10th December 2012
Old 10th December 2012
  #85
Lives for gear
 
jim1961's Avatar
 
Joined: May 2012
Location: Texas
Posts: 1,094

jim1961 is offline
Quote:
Originally Posted by Jens Eklund View Post
If the software cannot export the data in any way (sounds a bit odd though); it´s the end of that road.

I don´t have access to that software and I´ve only checked the “manual” quickly, but unless you can somehow export the IR (Impulse Response) file; the data sourced using this software will only be accessible by this application.
OK, I got a feature that says: "Save IR as wav file". This?
Jens Eklund
Thread Starter
#86
10th December 2012
Old 10th December 2012
  #86
Lives for gear
 
Jens Eklund's Avatar
 
Joined: Oct 2009
Location: Stockholm
Posts: 4,688

Thread Starter
Jens Eklund is offline
Quote:
Originally Posted by jim1961 View Post
The ETO files created by saved ETC graphs are not helpful then? Or the FRD files for saved FR graphs?
Probably not.
#87
10th December 2012
Old 10th December 2012
  #87
Lives for gear
 
jim1961's Avatar
 
Joined: May 2012
Location: Texas
Posts: 1,094

jim1961 is offline
Quote:
Originally Posted by Jens Eklund View Post
Probably not.
OK, I got a feature that says: "Save IR as wav file". This?

(Changed my above response after just discovering this feature)
Jens Eklund
Thread Starter
#88
10th December 2012
Old 10th December 2012
  #88
Lives for gear
 
Jens Eklund's Avatar
 
Joined: Oct 2009
Location: Stockholm
Posts: 4,688

Thread Starter
Jens Eklund is offline
Quote:
Originally Posted by jim1961 View Post
OK, I got a feature that says: "Save IR as wav file". This?

(Changed my above response after just discovering this feature)
Yes.
#89
10th December 2012
Old 10th December 2012
  #89
Lives for gear
 
jim1961's Avatar
 
Joined: May 2012
Location: Texas
Posts: 1,094

jim1961 is offline
Quote:
Originally Posted by Jens Eklund View Post
Yes.
Out of time today, will set things up again tomorrow. Dont know if these are 24 bit like you asked or unnormalized. Once I get the file, then what?
Jens Eklund
Thread Starter
#90
10th December 2012
Old 10th December 2012
  #90
Lives for gear
 
Jens Eklund's Avatar
 
Joined: Oct 2009
Location: Stockholm
Posts: 4,688

Thread Starter
Jens Eklund is offline
Quote:
Originally Posted by jim1961 View Post
Out of time today, will set things up again tomorrow. Dont know if these are 24 bit like you asked or unnormalized. Once I get the file, then what?
Please don´t go into trouble for my sake. I´m primarily interested in the behavior of FM regarding rec/process/export levels, but if you want to add to the knowledge base, feel free to do so. If so;

Check the indicated recording level by your apps input level indicator and record an IR, preferably a loop back at close to 0 dBFS peak (according to the level indicator in the measurement software). Note the exact peak value of the recording reported by the app. Export as 24/32 bit wav/aiff (or other standard sound file format) and if possible, do not normalize the file prior to export.
New Reply Submit Thread to Facebook Facebook  Submit Thread to Twitter Twitter  Submit Thread to LinkedIn LinkedIn  Submit Thread to Google+ Google+ 
 
Thread Tools
Search this Thread
Search this Thread:

Advanced Search
Similar Threads
Thread
Thread Starter / Forum
Replies
Dannibal / Post Production forum!
9
LaChunkyStudio / Post Production forum!
1
Dissdnt_penguin / So many guitars, so little time!
19
GeorgeSkoufalos / Post Production forum!
2
evangelista / Post Production forum!
0

Forum Jump

SEO by vBSEO ©2011, Crawlability, Inc.