[Uni-verse] Acoustic Material Database

[Emil Brink]

Lauri Savioja wrote:
> Hi Emil and Ludde,
> 
> I agree with both of you :-). In the long-term we should have some
> more advanced format, but making a reader for a CSV is not a big
> effort and with it we could get easily to test the system. Ludde, your
> XML looks a nice format!
> 
> Please, find attached a CSV version of the xls-file. It contains eight
> octave bands instead of 10. Emil, you can assume that the figure for
> 32 is the same as for 63 and for 16k the same as for 8k. This is a
> crude approximation but it seems that there is no data for the extreme
> bands. In the case some value is missing you should apply the same
> copying principle as for 32 and 16k bands :-).

Okay, thanks. I've been looking at this now, and am in the process of
getting my Pyton material databasing client to parse the file. I think
I over-did it, and extrapolated to fill in missing values, rather than
just copying. Perhaps that makes it worse, and copying is the right
to do. I'll change that.

One more question on the data format, since I'm still very much a
novice in this field: the available 8 values (which I extend to 10)
is only for one property, like "reflection", is it not? As defined
(or at least understood by me), the acoustic materials need 10 values
for each of three properties (reflect, trans, and diffuse) to be
fully specified. Should I simply duplicate the values into all three
properties? Or am I missing something altogether?

> I hope this helps.

It certainly does, thanks.

> BTW, the material file contains more than 2000 entries. For an
> architect it is not too convenient to select the correct one from a
> list ... Maybe we should make a heavily reduced set for the demo
> containing some tens of materials, or how do you feel?

As an outsider, I think some kind of simplification is needed, if the
selection is going to be based on name. Picking from a list could work,
but would probably be best served by a slightly more hierarchical
organization of the materials. As you said, picking from a flat list of
2,000 entries is not very convenient.

Also, typing in the name from memory is not optimal either, since I
certainly can't imagine anyone not deeply into the field being happy
memorizing names such as "Vollziegelmauerwerk, Vollziegel
handgestrichen, Format (207 x 100 x 50) mm, Kalk-Zementmrtel vollfugig,
vert. Fuge 15 mm, hor. Fuge 10 mm, Luftraumtiefe  30 mm". :)

Not sure how to fix this, perhaps copying some suitable data hoped to
be representative into a new much smaller database, using short names
("stone", "brick", "concrete" and so on) could work and also be clear
enough to work well during a demo? Just an idea.

Regards,

/Emil