Difficulty "Search/Split" string from "Read Binary File"

[Vik_K]

My long story short...:

I have an ".act" extension file that contains a signal (time-domain). I'm trying to read it, and perform an FFT on it. The item has a header... but it is useless, and I can't import the ACT as is. Someone has succeeded in importing files by first converting them to wav files, as I'm doing it now.

IT'S BEEN ATTACHED HERE WITH THE EXTENSION CHANGED TO .txt...

https://forums.ni.com/t5/LabVIEW/Raw-PCM-to-WAV/td-p/2739674

My issue now is that I want to search the file I'm importing for a combination "02 03 04" in HEX, that I noticed in the body. I can import the file, and my probe shows the (ugly) ASCII characters, but the Search/Split can't match the combination within the body (I'm 100% sure it's there, there's multiple).

Thanks in advance...

[JÞB]

you are searching for

"3032203033203034" literal

Set your search string display style to hex (right click on the string)

alternatly in normal display or password display.  enter the ascii codes directly by holding alt and entering the decimal value as 4 digits <%04d>  e.g Alt + 0020 for STX

Alt+0222 gets this Þ

[Bob_Schor]

If you have a Binary file (meaning the byte values do not represent text that can be read and interpreted "naturally" by a human), then I strongly recommend that you do not give it the extension .txt, which strongly suggests that it contains Ascii Text, i.e lines made up of bytes from 0x40 to 0xFE, with the combination 0x0A 0x0D (<CR><LF>) happening "frequently", and certain other characters having special meaning (like 0x00, <NUL> and 0x7F, <DEL>.

I recall, about a decade ago, finding a utility that "knew" about a number of file formats (maybe including .wav) and did the file conversion for you.  I've also "rolled my own" reading routines by knowing the format of the file I'm trying to read.  For example, a Dbl Array is usually stored by having a 4-byte U32 length followed by that many Dbls.  It is a bit tedious to read/parse binary files, but LabVIEW actually makes it easier, especially when earlier elements of the file (like the Array #-of-elements quantity) tell you how to read the next piece.  For example, I once inherited some code that saved data in an extremely convoluted mixed-together format consisting of a mix of text data, numeric (usually spacing or size) data, and arrays of numeric data.  There was size information embedded in the file, but you need to read the size, read a few more entries, then use the size information to read other features.  Here is a small piece of a sub-VI I wrote to read and decode this header, put together by stringing (no pun intended) the data elements + size/count elements:

Bob Schor

[Vik_K]

Hello Bob,

Thank you for your response. However, I posted the file as a TXT so that you can download/view it. ACT extensions are not permitted to be uploaded.

Regards,

Vik

[Vik_K]

Hi -

Thank you for your response. Turns out my work wasn't far off being correct, I was simply interpreting it as wrong, and I kept overwriting files instead of appending them... AH!

Now, I have to figure out how to sum or average waveforms from separate files...

[Vik_K · Accepted solution]

SOLUTION:

Apparently, it was already within. Terribly sorry for wasting anyone's time. Foremost, I was misinterpreting the output, and it didn't help that I was overwriting the output files instead of appending them (writing them as a function of variables, not subsequent entries, and therefore the filename is a formula). So, I thought I was failing to output file 1, instead I was reading the last output.