See perlfunc:binmode for how to set a filehandle into binary mode.

While your at it, you should look at unpack for a better way of processing your binary data than doing it with ord.

 
open "< FH";
binmode FH;
[download]

while (read(FH, $buf, 512)) {
       do something;
}
[download]

Then of course you can't use the usual file operators to read your data (but you shouldn't be doing that with a binary file anyway, even on *nix -- hopefully someone with more *nix experience can point out the pitfalls there).

You can use the usual file operators. There is nothing wrong with using them to read binary data. In fact, it can be quite handy as long as you understand what you are doing.

Usually, you'll want to change $/, the input record separator, before you do so. By default, $/ is a newline which is unlikely to be a meaningful delimiter in your binary data. A null, "\0", is often used to delimit variable length records though. If you have fixed length records or even if you just want to read chunks of a specific length in, you can do that by setting $/ to a reference. For example,

$/ = \16384;
[download]

would result in 16Kb block reads. Another useful value to set $/ to for binary data (as well as for text) is undef. Setting it to undef results in the whole file being slurped in a single read.

-sauoq
"My two cents aren't worth a dime.";

Oh, I just knew I wasn't being as helpful as I thought.

"Of course you can use regular file operators on a binmode file" I said as I slapped myself silly reading your reply. "Why, I've done it a hundred times myself!" And I'd forgotten about how useful the input record seperator can be, especially setting it to undef. I think that using

$/=\<a number>;
[download]

would have made things a lot easier sometimes too.

I have fallen prey to the fallacy of assuming that my habit is actually a recommended practice. When I'm dealing with a "binary file" I almost always use read, which makes it clear to me later what I was intending to do with it. On that somewhat flimsy notion, I beg forgiveness for misleading comments.

I have spent a couple of hours attempting to recreate problems I could swear I have had with null bytes (\x0) in files but have been unable to do -- please ignore that part of my answer as well.

And use $n = unpack 'v', $twobytes; or maybe yet unlikely, $n = unpack 'n', $twobytes; to extract the 2 byte integer. 'v' is for Little Endian, default on Intel, while 'n' is for Big Endian.

From your description, unpack would be perfect for your purposes.

For example, if your file has 3 16-bit integers, 2 32-bit integers and 4 1-byte ascii fields, getting them into seperate scalars would be as simple as

my ($int16_1, $int16_2, $int16_3, $int32_1, $int32_2, $c_1, $c_2, $c3,
+ $c_4) =
    unpack'S3 L2 C4', $scalar_18_bytes;
[download]

And there are format specifiers for just about every conceivable sort of datatype, size and -endian that you are likely to encounter.

---

Nah! Your thinking of Simon Templar, originally played by Roger Moore and later by Ian Ogilvy

Do you still recommend unpack as opposed to ord.

The answer is a qualified "yes". I'll get to the qualification in bit.

Ostensibly, once you have stripped the header from your binary data, extracting your 16-bit, big-endian values from string would be a simple as

my @ADsamples = unpack 'n*', $binaryData;
[download]

Which will 'do the right thing' with big-endian 16 bit data regardless of the architecture that it runs on.

However, there is a caveat as I mention a the top. The 'n' upack format specifier is for unsigned 16-bit values. There is no equivalent for big-endian, signed 16-bit data.

The upshot of this is that if your original data has the msb of the original sample is set, once this is sign extended, the resultant will be a negative value. Treating this as an unsigned value will result in large positive values!

This may not be a problem as you maybe oring out the bits that you need and ignoring the machinations of the sign extension. Otherwise, getting the negative values back is fairly trivial.

@signed = map{ $_ > 32767 ? $_ - 65536 : $_ } @unsigned;
[download]

So long as your aware of it, no problem.

That does bring up one other matter though,related to your use of ord. Depending on how you're breaking out the values from your sting, and which version of Perl you are using, ord has a trap waiting for the unwary using it to manipulate non-character data, namely utf.

In recent version of Perl (>5.6.1 I think but I'm not certain), ord can return values >255. Additionally, depending on what function you use and what regex (if any) you use, attempting to break a scalar into chars will not necessarially render bytes. split/./, $binaryData; is going to attempt to treat your data as variable-length chars if it discovers anything in the data that looks like a ucs char. This also holds true for  my @bytes = /./g; for instance unless you take precations to prevent it.

You may already be aware of this and taking the appropriate steps, but as I fell into the trap myself very recently, I thought it worth mentioning.

---

Nah! You're thinking of Simon Templar, originally played (on UKTV) by Roger Moore and later by Ian Ogilvy