Wave's WIR Impulse response convertion to WAV

[kvaca]

First of all, test tone was generated inside REAPER by a JS tone generator, and did not have any detectable noise floor whatsoever (i checked - complete silence down to -180dB).

OK, that changes everything, I have assumed similar noise floor like Wavelabs test tone gen.which gives only -144db...I apologies
but still your test tells exactly nothing about plugins resampling quality which is very important if you work at 44,1kHz and use included Waves IRs /96kHz/

Finally, you yourself have (correctly) pointed out that noise in the impulse itself would not have manifested as noise in the signal, because the impulse response only filters, it doesn't add anything.

completely not true: it exhibits same noise as original file, when only single sample/dirac/ is processed...like you hopefully did...or even worse it translate into ugly fake reverb, when countinous audio is processed...
to sum it up-any noise inside IRs alwys adds artifacts to your audio and I have NEVER stated that it doesn't add anything

[woggle]

wow it is almost as if I gave the OP useful information and then some dickhead muddied the waters with 10 year old data that may or may not be correct

[kvaca]

wow it is almost as if I gave the OP useful information and then some dickhead muddied the waters with 10 year old data that may or may not be correct

bravo, it seems you are the bosshead who greatly helped OP to batch covert wir files for use in his preferred convolution plugin...

[woggle]

wow it is almost as if I gave the OP useful information and then some dickhead muddied the waters with 10 year old data that may or may not be correct

bravo, it seems you are the bosshead who greatly helped OP to batch covert wir files for use in his preferred convolution plugin...

hey, KVR and you're a complete c**t pretending to be knowledgable

[kvaca]

figured i'd add 2¢ here since the info is already on the internet.
the file format is 32bit float little endian.
the header is described here: http://freeverb3vst.osdn.jp/tips/tips.shtml
if you were to import a file in say Adobe Audition, you'd need to "import raw" → 32 bit IEEE float, little endian, 1 channel for files with "m", 2 for "s", read offset 40 bytes (skip the header), and then when it opens, normalise the file to 0dB (100%)

alongside the .wir-s, the .xps-s contain metadata for e.g. normalisation etc.

I can confirm it works in Wavelab,too...batch processing of multiple opened files is also possible
many thanks for usefull info

[Burillo]

First of all, test tone was generated inside REAPER by a JS tone generator, and did not have any detectable noise floor whatsoever (i checked - complete silence down to -180dB).

OK, that changes everything, I have assumed similar noise floor like Wavelabs test tone gen.which gives only -144db...I apologies
but still your test tells exactly nothing about plugins resampling quality which is very important if you work at 44,1kHz and use included Waves IRs /96kHz/

that wasn't the question that was asked, so i did not attempt to provide an answer. however, i would expect that resampling works at the same bit depth the actual reverberation does. i can test this specific aspect later if you like.

Finally, you yourself have (correctly) pointed out that noise in the impulse itself would not have manifested as noise in the signal, because the impulse response only filters, it doesn't add anything.

completely not true: it exhibits same noise as original file, when only single sample/dirac/ is processed...like you hopefully did...or even worse it translate into ugly fake reverb, when countinous audio is processed...
to sum it up-any noise inside IRs alwys adds artifacts to your audio and I have NEVER stated that it doesn't add anything

you're both right and wrong at the same time.

when i'm talking about "adding" stuff, i mean that quite literally - adding frequencies that weren't there in the source signal (i.e. adding harmonics/distortion, or adding noise). convolving a signal with an impulse response, in technical sense, does neither.

the reason you get impulse noise floor from a Dirac pulse test is because Dirac is essentially a single-sample sweep across the entire frequency range. IOW, doing a Dirac pulse test will give you both processing noise floor (because there's processing - duh!) and impulse response noise floor (because you sweep across all frequencies, hence you get results for all frequencies - that includes noise frequencies), combined.

my sine-wave test, on the other hand, takes impulse's own noise floor out of the equation completely, and only focuses on processing noise floor. there's no sweep across the entire frequency range, so impulse's own noise floor does not affect the result in any way - we only see the processing noise floor. since convolution doesn't add anything (meaning, no harmonics, no noise), if you get a sine wave in, you will get a sine wave out (ignoring processing noise floor, of course).

the original problem, as claimed, was that IR1's processing noise floor is very high. this is what i have tested, and this appears to clearly not be true. now you've shifted your goalpost from "IR1's processing noise floor is high" to "IR1's impulse response resampling has high noise floor", which is an entirely different claim - the former has to do with convolution process itself, while the latter has to do with noise in impulse responses, not in the processing.

i've answered the first question - it's a definitive "no". i can make a few more tests and answer the second one too.

[kvaca]

First of all, test tone was generated inside REAPER by a JS tone generator, and did not have any detectable noise floor whatsoever (i checked - complete silence down to -180dB).

OK, that changes everything, I have assumed similar noise floor like Wavelabs test tone gen.which gives only -144db...I apologies
but still your test tells exactly nothing about plugins resampling quality which is very important if you work at 44,1kHz and use included Waves IRs /96kHz/

that wasn't the question that was asked, so i did not attempt to provide an answer. however, i would expect that resampling works at the same bit depth the actual reverberation does. i can test this specific aspect later if you like.

Finally, you yourself have (correctly) pointed out that noise in the impulse itself would not have manifested as noise in the signal, because the impulse response only filters, it doesn't add anything.

completely not true: it exhibits same noise as original file, when only single sample/dirac/ is processed...like you hopefully did...or even worse it translate into ugly fake reverb, when countinous audio is processed...
to sum it up-any noise inside IRs alwys adds artifacts to your audio and I have NEVER stated that it doesn't add anything

you're both right and wrong at the same time.

when i'm talking about "adding" stuff, i mean that quite literally - adding frequencies that weren't there in the source signal (i.e. adding harmonics/distortion, or adding noise). convolving a signal with an impulse response, in technical sense, does neither.

the reason you get impulse noise floor from a Dirac pulse test is because Dirac is essentially a single-sample sweep across the entire frequency range. IOW, doing a Dirac pulse test will give you both processing noise floor (because there's processing - duh!) and impulse response noise floor (because you sweep across all frequencies, hence you get results for all frequencies - that includes noise frequencies), combined.

my sine-wave test, on the other hand, takes impulse's own noise floor out of the equation completely, and only focuses on processing noise floor. there's no sweep across the entire frequency range, so impulse's own noise floor does not affect the result in any way - we only see the processing noise floor. since convolution doesn't add anything (meaning, no harmonics, no noise), if you get a sine wave in, you will get a sine wave out (ignoring processing noise floor, of course).

the original problem, as claimed, was that IR1's processing noise floor is very high. this is what i have tested, and this appears to clearly not be true. now you've shifted your goalpost from "IR1's processing noise floor is high" to "IR1's impulse response resampling has high noise floor", which is an entirely different claim - the former has to do with convolution process itself, while the latter has to do with noise in impulse responses, not in the processing.

i've answered the first question - it's a definitive "no". i can make a few more tests and answer the second one too.

I think OP got his answer so any debate is now becoming useless at least for him,
when I have tested mentioned plugins Waves was easily the worst of a bunch, so Im glad to hear they have improved quality of dsp /without any info or without correcting corresponding data in their latest OM, which confused me a bit/ but still they maintained same old limits which render their plugin as unusable for me even today...
maybe you shloud also test resampling engine to know the artifacts you can avoid when there is known how to convert IRs from wir files to wav and do a better reasampling in some specialized plugin, but I dont care so its up to you, have a nice day

[simon.a.billington]

shooting a sine wave through IR1 reveals what appears to be 24-bit (-144dB) dithered down into pretty much inaudibility (and that's with three impulses active - direct, early and tail - single impulse noise floor is even lower):


IR1-noise.jpg

So, apparently, you're wrong about IR1's high noise floor - it's perfectly fine.

As I was suspecting. While you were correct in assuming that the internal maths doesn't necessarily have to change, its almost a given. That's the whole point in updating the code to include extra precision.

I don't know how aware you guys with programming and how it works, but I do have some pretty good knowledge having studied it at university. Basically, an algorithm is an algorithm.It almost never has anything to do with the datas size specifically (32/64bit), unless its doing something very intentional with it like upsampling or downsampling or bit crushing, which is really just a form of downsampling.

It's like the old algebra back at school. We can put in a decimal number, or we can put in a whole number, the results of passing numbers through that equation will still be reliable. It just either has extra precision or it doesn't and that is defined by the type of numbers we put in, not the algorithm itself.

For easy code maintenance the precision of numbers is usually defined separately, at the top of the code. To update the precision comes as simple as a Find & Replace function. Find 32-bit declaration, replace it with 64-bit. In terms of the algorithm nothing else needs to be changed and you will have your calculations at higher resolution than they were before.

That's why there is this huge misnomer behind "old code" being not as good. Older plugins may not be as feature rich or as flexible, but many of them become quite iconic sounding, at least to the engineers using them. "Good", in this context, is a subjective term that only has relevance to the person using it.

[Burillo]

I don't know how aware you guys with programming and how it works, but I do have some pretty good knowledge having studied it at university.

i'll give you one better: i am a professional software developer. i don't specifically work with DSP, but i do have some rudimentary knowledge in that area.

Basically, an algorithm is an algorithm.It almost never has anything to do with the datas size specifically (32/64bit)

no. when you work with audio data, any changes you do will only have so much precision. if you're working with 16-bit data, you'll have 16-bit precision. to not have processing noise floor is to have infinite precision, and we all know there is no such thing. some algorithms will only work with integer math (for example, if they rely on integer over/underflow behavior), some algorithms will only work with floating point math (because they require a lot of divisions, for example - with integer math you're quickly losing precision that way), some will work with both.

For easy code maintenance the precision of numbers is usually defined separately, at the top of the code. To update the precision comes as simple as a Find & Replace function. Find 32-bit declaration, replace it with 64-bit. In terms of the algorithm nothing else needs to be changed and you will have your calculations at higher resolution than they were before.

if only it were that simple... the reality is, DSP code is often times voodoo magic that's doing some clever tricks to shave off a few CPU cycles. you don't have to go as far as to look at John Carmack's inverse square root algorithm (wiki is your friend) to see the lengths people will go. try updating that to 64-bit math

That's why there is this huge misnomer behind "old code" being not as good.

no, that's not why people say "old code is not good". it has to do with techniques of the craft. for example, back in the early days of digital, curves on digital EQ plugins weren't commonly decramped, so the EQ curve in the high end was getting warped. oversampling was also not commonly used, and that means aliasing galore on any algorithm that generates harmonics. CPU load budget was also lower (and there were no high performance vector instructions), so developers had to be content with less precise models of gear, if they chose analog modeling route at all (as opposed to just sticking a simple waveshaper in place of "a tube").

that is why people use "old code" as a pejorative - because it's from a simpler time, and isn't as sophisticated as modern techniques that are now staples.

[simon.a.billington]

I think you misunderstood me just a little or perhaps I didn't explain myself properly. Its okay, it happens.

In terms of this..

Basically, an algorithm is an algorithm.It almost never has anything to do with the datas size specifically (32/64bit)

What I meant is that the numbers and the algorithms are two different entities usually. Here's a primitive example, sqrt(a^2 + b^2) = c. This "algorithm" will work regardless of what kind of number you put through it 32 bit or 64-bit. The algorithm is usually separate from the numbers. In most cases the numbers are being read from the audio stream anyway. Even if you were using constants, like Pi, then it would be considered unwise and bad practice to be hardcoding that into your algorithm. It's common practice to declare it as a constant at top of the code somewhere, for easy maintenance.

That's what I was referring to. But sure there are exceptions. Especially with performance optimisations with which I have very minimal experience in.

For easy code maintenance the precision of numbers is usually defined separately, at the top of the code. To update the precision comes as simple as a Find & Replace function. Find 32-bit declaration, replace it with 64-bit. In terms of the algorithm nothing else needs to be changed and you will have your calculations at higher resolution than they were before.

And yes, I was both generalising and simplifying here a little. I was just trying to paint a picture that was easy for most people to grasp.

Waves are no slouches when it comes to maintaining their code, though. They often get their compatibility updates faster than many over developers. So it has me suspecting it is because their code is much easier to maintain, owing to their whole underlying code infrastructure. Change it once in the shared library and the update is reflected across all of the plugins.

Yet there is still usually other housekeeping stuff that needs to be done.

That's why there is this huge misnomer behind "old code" being not as good.

no, that's not why people say "old code is not good". it has to do with techniques of the craft. for example, back in the early days of digital, curves on digital EQ plugins weren't commonly decramped, so the EQ curve in the high end was getting warped. oversampling was also not commonly used, and that means aliasing galore on any algorithm that generates harmonics. CPU load budget was also lower (and there were no high performance vector instructions), so developers had to be content with less precise models of gear, if they chose analog modeling route at all (as opposed to just sticking a simple waveshaper in place of "a tube").

Yeah all this is true. To be honest, I never notice it much of a problem because I often work at 96k. Which is probably why my experiences vary to others that don't. But if you're working at 48k and have plugin that x2 oversamples, then effectively its working at 96k anyway. In fact there is even a little bit more overhead up converting and down converting.

I once ran an experiment. I tested my project's CPU performance at both 48 and 96k, I noticed a very marginal difference. I'm guessing this is all owed to the oversampling many devs are now doing, at least for lower sample rates. This was not in any way a thorough and exhaustive test, but it did make me think that working at 48k to save on CPU cycles is fast becoming a futile practice in this latest generation of plugins.

Either way, the worst of "old code" is that its more like having device with old components. Just look how coveted all the old vintage devices are, even the digital ones. It still functions, it still does it job, and it often imparts a character than many find desirable. But it may not be for everyone.

[Dewdman42]

I'd like to know also if anyone has successfully translated WIR to WAV. I own both IR-1 and IR-L. Would love to use the Waves IR's in Reverberate3 though, which has quite a bit of awesome flexibility, but a limited set of real room IR's.

It looks like Freeverb3 has reverse engineered the file format? So Freeverb3 can read WIR files directly then? I wonder how hard it would be to use their code to write a quite translator to WAV?

[Dewdman42]

Actually never mind. Apparently Reverberate3 can already read WIR!

[AKJ]

Just use this free and open source tool:

https://github.com/opcode81/wir2wav

[cturner]

Courtesy an initial test to confirm that Reverberate 3 could load WIR files directly, it seems also that Waves Vinyl has some interesting impulses some might find useful.

[Dewdman42]

Thanks for the reference to the python script though...