|
How to find the coordinates of the starting point of a waveform (stored in two columns of data: first column-time; second column-g)? The technique needs to be able to discard the noise sometime which may be before the real start point.
Thank you for your start ideal and coding techniques!
|
|
|
|
|
If you mean a file made up by lines (separated by a '\n') each containing two numbers separated by a delimiter, with some spurious character at beginning, you typically need to read the file line by line, then parse each line to identify the presence of certain structural elements (digits, signs, separators etc.)
Once you decide that the line looks OK, you can start to convert the (sub)strings into numbers.
Another technique can make use of a circular buffer.
You read the file to fill in the buffer, check the buffer contents if matching some "prerequisite" (as above), do the required conversion then discard the already read characters, and refill the buffer.
2 bugs found.
> recompile ...
65534 bugs found.
|
|
|
|
|
Thanks. This is about data processing of a seismic wave stored in a file containing two columns of data: the fist column is the time: 0, 0.0001, 0.0002, 0.0003, ...; the second column is the wave amplitude: 0.00, 0.0001, 0.00015, ...; the zero's or noise in the beginning for some time, then real wave onset come and the wave started.
I need to detect the wave onset. Too bad I can not draw a picture for you here. For example, a paper here provide a way to find this onset, but too complex. Here is the link for the paper: http://www-geo.phys.ualberta.ca/~doug/papers/First-break_timing.pdf[^]
I am looking a simple, better method.
Thanks
|
|
|
|
|
mrby123 wrote: Too bad I can not draw a picture for you here.
But you can show the relevant parts of the file, yes?
"One man's wage rise is another man's price increase." - Harold Wilson
"Fireproof doesn't mean the fire will never come. It means when the fire comes that you will be able to withstand it." - Michael Simmons
"Man who follows car will be exhausted." - Confucius
|
|
|
|
|
|
Your problem is about parsing a data file that represents a waveform, correct?
"One man's wage rise is another man's price increase." - Harold Wilson
"Fireproof doesn't mean the fire will never come. It means when the fire comes that you will be able to withstand it." - Michael Simmons
"Man who follows car will be exhausted." - Confucius
|
|
|
|
|
Not exactly, it is about to find the onset of the waveform like that in the paper in the link.
|
|
|
|
|
mrby123 wrote: ...it is about to find the onset of the waveform...
But you are using a data file as input for this, correct?
"One man's wage rise is another man's price increase." - Harold Wilson
"Fireproof doesn't mean the fire will never come. It means when the fire comes that you will be able to withstand it." - Michael Simmons
"Man who follows car will be exhausted." - Confucius
|
|
|
|
|
|
Ok, so the problem boils down to something like:
FILE *pFile = fopen(...);
double dTime, dAmp;
while (fscanf("%f %f\n", &dTime, &dAmp) != EOF)
{
}
"One man's wage rise is another man's price increase." - Harold Wilson
"Fireproof doesn't mean the fire will never come. It means when the fire comes that you will be able to withstand it." - Michael Simmons
"Man who follows car will be exhausted." - Confucius
|
|
|
|
|
Thanks. You are right on the issue. Now the key I am looking for is the technique to detect the onset. What is the
robust criterion to determine the onset of the wave, while the noise in the data will not confuse the determination?
Thanks for smart thought.
|
|
|
|
|
mrby123 wrote: Thanks. You are right on the issue.
Which is what I was trying to get at three posts ago.
mrby123 wrote: Now the key I am looking for is the technique to detect the onset. What is the
robust criterion to determine the onset of the wave, while the noise in the data will not confuse the determination?
Only you can determine what is noise and what is not. When you are dealing with floating-point numbers, you can't check a number being exactly equal to 0. You'll have to compare against something like epsilon.
"One man's wage rise is another man's price increase." - Harold Wilson
"Fireproof doesn't mean the fire will never come. It means when the fire comes that you will be able to withstand it." - Michael Simmons
"Man who follows car will be exhausted." - Confucius
|
|
|
|
|
Can you please elaborate your question?
if i understood it correctly,(since you said you want to discard noise) you must be trying to strip the silence in the .Wav file and create a new .wav file.
please be clear.
--------------------------------------------
Suggestion to the members:
Please prefix your main thread subject with [SOLVED] if it is solved.
thanks.
chandu.
|
|
|
|
|
|
My two cents.
To determine starting point you need to state what charateristic of the waveform changes at the start point - frequency or amplitude of signal.
For e.g. for seismic waveforms, i assume that there will be a rapid increase of amplitude of the signal at the start of the event. In this case you can determine rate of change of amplitude of a window of data. The window must be moved over the complete set. The first window in which the rate of change is above a certain threshold would contain the starting point of the waveform.
[Edit]
assuming you are not looking for actual code, you may have better luck posting this question in 'Algorithms' section.
|
|
|
|
|
|
We have a large application built using VC6 (SP6) which also involves MFC, running on WinXP SP3.
Now, when I tried to display the Print Property Sheet, available through the PrintDlgEx() function, and the LPPRINTDLGEX structure, I found that my CommDlg.h did not contain these definitions. For that purpose, I searched the 'Net and downloaded the last Platform SDK (February 2003 edition), which is supposed to work for VC6. I installed the SDK, updated the directory paths in the VC6 environment (keeping them at the top), but it still simply refuses to recognize these structures & functions, giving the C2065 (Undeclared identifier) conpiler errors.
Including Windows.h, commdlg.h has no effect. However, when the line #include "Windows.h" is placed above the #include "Stdafx.h" line, then the nature of errors changes, and we are redirected to the error line in afxwin32.h - MFC apps should not include Windows.h!!
Could anybody guide us here?
Thanks !
modified on Wednesday, May 5, 2010 6:33 AM
|
|
|
|
|
You probably need to define macros to tell the SDK that you want to use these features. Have a look at this page[^].
LPPRINTDLGEX was available in Windows 2000 and later, so you want to have these #defines BEFORE you #include any Windows SDK or MFC headers:
#define _WIN32_WINNT 0x0500
#define WINVER 0x0500
Java, Basic, who cares - it's all a bunch of tree-hugging hippy cr*p
CodeProject MVP for 2010 - who'd'a thunk it!
|
|
|
|
|
If you will look at commdlg.h, you'll notice the #if preprocessor directives scattered throughout the file. They are looking at WINVER and _WIN32_WINNT.
"One man's wage rise is another man's price increase." - Harold Wilson
"Fireproof doesn't mean the fire will never come. It means when the fire comes that you will be able to withstand it." - Michael Simmons
"Man who follows car will be exhausted." - Confucius
|
|
|
|
|
Thank you for your replies.
I'm sorry I failed to mention that I had tried defining these macros, both in the "App"View.cpp file, as well as in the stdafx.h file.
Now, upon your suggestion, I tried defining them in the "app"view.cpp file before including the stdafx file, as well as at the top of the stdafx.h file, but to no avail. It simply refuses to recognize this structure & function.
Interestingly, when I use the Page Setup dialog, it correctly displays the dialog, and when its definition is checked, it is the one located in the commdlg.h from the Platform SDK. So, this means that the path is ok, but it definitely has something to do with these macros. What about the STDMETHOD macro ? I don't understand this one, I'm afraid, and what it's supposed to do...
Would be very grateful for any further investigation into this issue!! 
modified on Wednesday, April 28, 2010 2:15 AM
|
|
|
|
|
STDMETHOD is a COM definition, used to declare a method corrctly so it can be called through COM.
I would suggest you look at what comes out of the pre-processor (use the /P option for CL, the C++ compiler) to see what you're missing...
To make sure your SDK is OK, I would suggest putting the following in a C++ file (say a.cpp) and compiling it on the command-line with the command CL -I Path to your Platform SDK Include directory -C a.cpp.
#define WINVER 0x0500
#include <Windows.h>
#include <CommDlg.h>
LPPRINTDLGEX pPrintDlg;
If this doesn't compile correctly, there's something wrong with your SDK.
Java, Basic, who cares - it's all a bunch of tree-hugging hippy cr*p
CodeProject MVP for 2010 - who'd'a thunk it!
|
|
|
|
|
When compiling the above cpp file, it gave the error message that it was unable to find "excpt.h" , which was included in Windows.h. Upon search, this file was found to be located in the following path within the PSDK: "..\Platform SDK\Include\Win64\CRT" . When this path was also added to the command line options, it complied fine.
When we look at the directory structure of the include files in this PSDK, it is rather different from that of VC98, especially w.r.t. to the MFC files. The MFC folder in the PSDK include directory doesn't contain any significant (no. of) files. These files are rather found under the Win64 directory.
What to do? 
|
|
|
|
|
The PSDK does not contain MFC or ATL or standard include files. You need to have the compilers include directories in the include path *as well* as the PSDKs directories, but after the PSDKs directories in the INCLUDE/LIB search paths.
Java, Basic, who cares - it's all a bunch of tree-hugging hippy cr*p
CodeProject MVP for 2010 - who'd'a thunk it!
|
|
|
|
|
They're all there....
As I said, everything else is working fine..It's even recognizing the Page Setup dialog function & structure in the same file (CommDlg.h) in the PSDK path), but just refuses to recognize the print property sheet function & structure....some (#if) conditions not being met ?
|
|
|
|
|
Pass your code through just the compiler's pre-processor (use the /P option). That will spit out a file containing the pre-processed text. you should be able to find which bits of commdlg.h are/are not being included in the program text, so can see (by comparison with the .h file) which #if is causing the bit of code you want to be omitted.
Java, Basic, who cares - it's all a bunch of tree-hugging hippy cr*p
CodeProject MVP for 2010 - who'd'a thunk it!
|
|
|
|
General 
News 
Suggestion 
Question 
Bug 
Answer 
Joke 
Praise 
Rant 
Admin 
Submit an article or tip
