Jean-Pierre Côté's dashboard

Jean-Pierre Côté marked one of Chris Liscio's replies in SuperMegaUltraGroovy as useful. Chris Liscio replied to the question "Interchangeability to Snow Leopard".

A comment on the question "Microphone Calibration file format" in SuperMegaUltraGroovy:

That would definitely be the way to go! – Jean-Pierre Côté, on July 15, 2009 14:11

Jean-Pierre Côté started following the question "Intelligibility Measurements?" in SuperMegaUltraGroovy.

Jean-Pierre Côté started following the question "Is it possible to Measure Amplifier frequency response with Fuzzmeasure?" in SuperMegaUltraGroovy.

Jean-Pierre Côté started following the idea "Feature request: Photoshop-like panning" in SuperMegaUltraGroovy.

Jean-Pierre Côté replied on May 04, 2009 22:10 to the problem "v3 : Markers in Impulse graph have a weird behaviour (bug)" in SuperMegaUltraGroovy:

Hey Chris, any news on this bug?

Jean-Pierre Côté started following the question "EDT,T20, T30 in two measurements?" in SuperMegaUltraGroovy.

Jean-Pierre Côté replied on August 31, 2008 14:34 to the question "Strange freq characteristics when unsmoothed" in SuperMegaUltraGroovy:

I’d be interested in seeing your results. Can you load the file somewhere we can dowmnload it?

Jean-Pierre Côté shared an idea in SuperMegaUltraGroovy on July 17, 2008 02:55:

Smoothing and Bark scale

Hi,

It’d be great to add one octave to the list of smoothing resolutions available in the FR graph.

Also, some kind of a psycho-acoustic scale would be even better. I suggest the Bark scale (Zwicker) where the resolutions go like this :

< 150 Hz : 1 oct
150 - 500 : 1/3 oct
500 - 4 kHz : 1/6 oct
> 4 kHz : 1/3 oct

Zwicker’s work is not about JND in frequency, but about the perception of the resulting level from the accumulation of sounds close to one another in frequency (sounds within the same “critical band”). In other words, it doesn’t mean that one won’t hear the difference, in pitch or level, between two notes a minor third apart played by the bass player; nevertheless, on the overall spectrum, when many sounds combine, a frequency response will be perceived as mostly flat when the above resolution reads it as such, even though a coarser resolution would reveal deviations.

What do others think?

Any way to implement this in Fuzz?

For those interested, the paper that is most often referred to about this (the article that started it all I guess) is:

Zwicker, E: Subdivision of the Audible Frequency Range into Critical Bands (Frequenzgruppen), Letters to the editor, JASA, Vol 33, n.2, Feb 1961

Jean-Pierre Côté replied on July 17, 2008 02:25 to the question "THD" in SuperMegaUltraGroovy:

> According to IEC 60268-5 (Sound system equipment Part 5: Loudspeakers), THD must
> be reported along with the frequencies at which they were measured. So, if you want
> to give just one number, you'd probably just take a graph like the one I displayed
> above, and report the value at 1kHz.

Correct. But I’m thinking about a way to make a single number out of, say, the mean value of all frequencies... this would be new (I think), and, though still imprecise, better than the actual 1 kHz value that doesn’t say anything about the low end, for instance.

In any case, if you could make the distortion data exportable, it would make it really useful I think.

Jean-Pierre Côté replied on July 04, 2008 14:31 to the question "THD" in SuperMegaUltraGroovy:

Personally I don’t agree with this “no-horizontal-shift” display. I find it counter intuitive since the trace is not where you actually hear it, i.e. H#2 for 1 kHz is a sound that is clearly heard at 2 kHz, not at 1 kHz...

And for %, I would prefer a single THD number.

This said, your example is very interesting as well. Maybe we could have both ways available (“Harmonic distortion [Farina]”, and “Harmonic distortion [realigned]”)

By extension, would it be possible to also measure non-harmonic distortion (for PCM converters, for instance)?

A comment on the problem "Zoom out bug" in SuperMegaUltraGroovy:

Sounds right. – Jean-Pierre Côté, on July 03, 2008 14:24

Jean-Pierre Côté replied on July 03, 2008 14:21 to the question "v.3.1b1_FFT window size changes Rev Time" in SuperMegaUltraGroovy:

It definitely is a change for the better. The drawback is the extra manipulation involved for the user that makes the time needed substantially longer. So, yes, an “automatic” feature would be appreciated. I’m also thinking about less skilled users who may get confused by this approach ...

BTW, are we still ISO 3382 compliant with this new method?

Jean-Pierre Côté marked one of Chris Liscio's replies in SuperMegaUltraGroovy as useful. Chris Liscio replied to the question "v.3.1b1_FFT window size changes Rev Time".

Jean-Pierre Côté replied on July 02, 2008 16:44 to the question "v.3.1b1_FFT window size changes Rev Time" in SuperMegaUltraGroovy:

I just compared Rev data obtained with v.3 to 3.1b1. It turns out that if I leave the FFT window size to automatic, the REV time data is wrong with this new version. But if I make it longer manually, I get the exact same results now than before, only with more data where SNR is bad (great!).

So the old way was able to adjust the FFT window size for accurate RT calculations...

Jean-Pierre Côté reported a problem in SuperMegaUltraGroovy on July 02, 2008 15:52:

Zoom rectangle

3.1b1 (3010.2.1)
Not necessarily a bug: just a small annoyance.
The new zoom rectangle feature is very sensitive; one sometimes end up in full zooming just because of a “sliding click” while using the zomm tool...
Maybe a threshold?

Jean-Pierre Côté asked a question in SuperMegaUltraGroovy on July 02, 2008 15:38:

v.3.1b1_FFT window size changes Rev Time

3.1b1 (3010.2.1)
This new version of the Rev plugin adjusts the calculated Rev time according to the FFT window size. It seems to me that the default window size ends up being to short for accurate rev time calculations; you have to make it longer manually until the Rev times stop changing. Am I getting it right? Could this be automatic?

Jean-Pierre Côté reported a problem in SuperMegaUltraGroovy on July 02, 2008 15:19:

Zoom out bug

3.1b1 (3010.2.1)
Zooming out in the time domain, you eventually loose the IR’s data (grey window) if you click fast. Revert zooming does not resolve (white window); you have to switch IR and come back to re-initialise the view.

Jean-Pierre Côté replied on July 02, 2008 15:11 to the discussion "FuzzMeasure 3.1b1 Posted" in SuperMegaUltraGroovy:

Wow Chris: This version is something! Much faster on the Rev and Waterfall plugins. And every new thing seems to work just great!

I was just done with the analysis of a lot of data about the acoustics of guitars. One of the main limits was the resolution of the resonances analysis in 1 oct. I don’t know if I must thank you or not: now I have to start again in 1/3 oct!

So I’ll speed it today. Watch out for bug reports!

Jean-Pierre Côté replied on July 02, 2008 02:53 to the question "THD" in SuperMegaUltraGroovy:

Yes, Farina over Müller in this case. But again: Can you add HD % so we would see the graph in an easier readout form, plus the number telling the dist in % = best off all worlds...

About the colours, I prefer the single graph per IR as I often work on files with *many* IR’s and “decomposing” each makes the IR list difficult to deal with. Is it possible to 'desaturate/darken' more? Or you could use dedicated colours (that would never be assigned to any IR’s FR).