No he doesn't. His bursts are in 1/3rd octave spacing, completely useless for the purpose. I chose 1/24 oct for a good reason.Nothing new under the sun ... Keele has similar stuff online ...
And probably they're not repetitive, let alone patterned, so even more useless.
Is that why post4 link is 445Mb?
It took less than 11 minutes to download.
Is post4 the result of opening up and running post1 file?
It took less than 11 minutes to download.
Is post4 the result of opening up and running post1 file?
Is that why post4 link is 445Mb?
It took less than 11 minutes to download.
Is post4 the result of opening up and running post1 file?
Yes.
I compiled the mkburst program with OpenBSD 5.1. Works after only a few modifications:
- you define "const HSIZE=sizeof(header)". This is not allowed in ISO-C++98 (don't know if it is in ISO-C++11). Do "const dword HSIZE..." instead
- you rely on "unsigned int" having 2 bytes and "unsigned long" having 4 bytes. This is no good assumption. Almost every system has a special type which guarantees this. On OpenBSD (and I believe the other BSDs) it is "u_int16_t" and "u_int32_t", Linux is IIRC "uint16_t" and "uint32_t"
- a usual problem of DOS- and Windows-users: there are modern operating systems out there which distinguish between upper-case and lower-case. I changed the file tail "WAV" to "wav". This is not necessary for compilation.
You have to compile with g++ instead of gcc (assuming GNU Compiler), or linker errors will occur.
- you define "const HSIZE=sizeof(header)". This is not allowed in ISO-C++98 (don't know if it is in ISO-C++11). Do "const dword HSIZE..." instead
- you rely on "unsigned int" having 2 bytes and "unsigned long" having 4 bytes. This is no good assumption. Almost every system has a special type which guarantees this. On OpenBSD (and I believe the other BSDs) it is "u_int16_t" and "u_int32_t", Linux is IIRC "uint16_t" and "uint32_t"
- a usual problem of DOS- and Windows-users: there are modern operating systems out there which distinguish between upper-case and lower-case. I changed the file tail "WAV" to "wav". This is not necessary for compilation.
You have to compile with g++ instead of gcc (assuming GNU Compiler), or linker errors will occur.
No he doesn't. His bursts are in 1/3rd octave spacing, completely useless for the purpose. I chose 1/24 oct for a good reason.
And probably they're not repetitive, let alone patterned, so even more useless.
yes Keele´s stuff is more aimed to find driver´s limits (important too) , sorry I didn´t read all your instructions
a more visual approach is to use the Java-based online calculator by Hunecke :
hunecke.de | Loudspeakers Calculator
Test: Stereoplay, Englisch
(nice overview and how to use it - you may need Google translation for this german site - So finden Sie die optimale Lautsprecher-Position - stereoplay)
in rectangular rooms this tool is close to what you can measure
by moving speakers/subs and listener position with the mouse you can minimize modal problems quickly
btw deep suckouts are nasty too , not as offensive as peaks but it robs the energy out of the music and the thrill is lost
best regards
ps - in the english speaking part of the world this Java modal calcoolator *g* seems to be not recognized yet , but it was available online many years ago! (the older offline-version were replaced)
Thanks for these notes and the port, Cpt.Bat. I fiddled with GCC/G++ lately under windows as well as under very early Linux (ca 1996) but alway missed the Borland frontend and the debuggers which all was probably the best at the time, basicly the first true IDE for PC based stuff (that's why Borland got so big with TurboPascal and later C).I compiled the mkburst program with OpenBSD 5.1. Works after only a few modifications:
- you define "const HSIZE=sizeof(header)". This is not allowed in ISO-C++98 (don't know if it is in ISO-C++11). Do "const dword HSIZE..." instead
- you rely on "unsigned int" having 2 bytes and "unsigned long" having 4 bytes. This is no good assumption. Almost every system has a special type which guarantees this. On OpenBSD (and I believe the other BSDs) it is "u_int16_t" and "u_int32_t", Linux is IIRC "uint16_t" and "uint32_t"
- a usual problem of DOS- and Windows-users: there are modern operating systems out there which distinguish between upper-case and lower-case. I changed the file tail "WAV" to "wav". This is not necessary for compilation.
You have to compile with g++ instead of gcc (assuming GNU Compiler), or linker errors will occur.
Windows with MingW-GCC is a little more complicated here. The MingW-GCC calls g++ by itself, but then a strange error occurs, which seems to be related with the PATH variable.
This different behaviour of GCC on each platform is one of the reasons why the BSDs move to LLVM/Clang.
You can compile it as ISO-C (renaming file to *.c will do this for you), but you need to add -std=c99 and remove the defaults in function burst(), resulting in much more complicated calls to this function.
This different behaviour of GCC on each platform is one of the reasons why the BSDs move to LLVM/Clang.
You can compile it as ISO-C (renaming file to *.c will do this for you), but you need to add -std=c99 and remove the defaults in function burst(), resulting in much more complicated calls to this function.
- Status
- Not open for further replies.
- Home
- General Interest
- Room Acoustics & Mods
- Low Frequency Sine-Burst Test Signals for Room and Loudspeaker Evaluation