reading wav files

[Ben Bacarisse]

Thank you for your suggestions.

Beware that simply taking bytes from a file will only give you good
pseudo-random numbers if the file itself is "random". Treating structured
files like WAV files in this way is not obviously going to give you a
good source of randomness. At the very least, I'd skip the header
which is a poor source of entropy. Depending on other factors (what
sounds are in the file and what use you want to make of the random
numbers) I'd consider hashing the sound samples rather than using them
directly.

If your use is a cryptographic one, comp.sci.crypt is a good place to
ask about random numbers.

 

[Bill Reid]

Actually, for the record, it can be anything between 1 and 2^32-1
samples per second.  (Yes, some of us can tell the difference between
200 million and 201 million samples per second!  No, I'm lying.)

Anybody can tell the difference if they use Monster(TM)
speaker wire...

 

[Keith Thompson]

What is the definition of c ?

If c is a signed short, why do you use %d as a format (%d expects an int).
use %hd if c is a short.

Because signed short promotes to signed int. You can use "%hd" to
print a signed short value, but that just means the promoted value is
converted back to signed short; if the argument is an object of type
signed short, that will make no difference.

It might be reasonable to write:

printf("%d\n", (int)c);

if you're not certain how c will be promoted.

 

[bartc]

This is the code

(I tried to run this, but had problems because the code insisted on dynamic
storage even for small objects such as the Riff header and the filename. I
usually get rid of stuff like that when testing (and don't bother with argv
conversion, just hardcode a filename).)

I tried your code on a sample Wav file, and some samples were negative, and
some positive. This seemed to use 8-bits per sample however.

Did you try a different Wav file? Did you dump it to see what the data was
supposed to look like?

Changing the output slightly to include the file offset, lets you match the
program output with the actual contents.

You can try changing the 'short int c' to unsigned to help see what's going
on too (and you don't need %hd as the printf format; %d (or %u for unsigned)
will do).

In fact just reading the data as a series of unsigned char values (ignoring
sample size) might help in seeing the data too.

(BTW if you are really only interested in random values, you seem to be
going to a lot of trouble in analyzing the header info..)

 

[Sarchiapone]

Il Mon, 01 Feb 2010 13:42:07 +0000, bartc ha scritto:

(I tried to run this, but had problems because the code insisted on
dynamic storage even for small objects such as the Riff header and the
filename. I usually get rid of stuff like that when testing (and don't
bother with argv conversion, just hardcode a filename).)

I tried your code on a sample Wav file, and some samples were negative,
and some positive. This seemed to use 8-bits per sample however.

Did you try a different Wav file? Did you dump it to see what the data
was supposed to look like?

I tried, and it gave me different results.

Changing the output slightly to include the file offset, lets you match
the program output with the actual contents.

(BTW if you are really only interested in random values, you seem to be
going to a lot of trouble in analyzing the header info..)

Well, I am completely new to wav file format, so I didn't know where to
start from. Anyway I have discovered that every program manages wav files
in its own way.

 

[Antoninus Twink]

It might be reasonable to write:
printf("%d\n", (int)c);
if you're not certain how c will be promoted.

Come on then Keith, this should be good for a laugh.

What combination of padding bits and trap representations are you
relying on to come up with a situation where signed short int won't get
promoted to signed int?

I don't believe one exists even in theory.

 

[Phil Bradby]

Come on then Keith, this should be good for a laugh.

What combination of padding bits and trap representations are you
relying on to come up with a situation where signed short int won't get
promoted to signed int?

I don't believe one exists even in theory.

I guess Keith (and most others!) will have you killfiled so he won't see
your question... but I'd be interested in the response. From what I
remember from my days poring over K&R it /does/ have to promote to int,
doesn't it??

PB

 

[Andrew Poelstra]

Come on then Keith, this should be good for a laugh.

What combination of padding bits and trap representations are you
relying on to come up with a situation where signed short int won't get
promoted to signed int?

I don't believe one exists even in theory.

If sizeof(int) == sizeof(unsigned short) and the system uses
signed magnitude, and int -0 == ushort 0xFFFF, and -0 is a
trap, and the cast would avoid this while the promotion
would not, for one. Maybe.

 

[Peter Nilsson]

...What combination of padding bits and trap representations
are you relying on to come up with a situation where signed
short int won't get promoted to signed int?

Any trap representation may stop a short value being converted
to an int, but I don't think that was Keith's point. I assume
he meant that, as a style, adding a redundant cast might appease
any lingering doubts for someone who wasn't sure.

 

[Peter Nilsson]

...From what I remember from my days poring over K&R [short]
/does/ have to promote to int, doesn't it??

Yes, in situations where integer promotion applies. This is
because int must be able to represent every value that short
can represent. [That is not necessarily true for unsigned
short though.]

 

[Keith Thompson]

[...]
Any trap representation may stop a short value being converted
to an int, but I don't think that was Keith's point. I assume
he meant that, as a style, adding a redundant cast might appease
any lingering doubts for someone who wasn't sure.

If you know that c is of type short, the cast is not necessary; it
only performs a conversion that would have been performed by the
promotion anyway.

In particular, I was thinking of cases where it's not clear that
c is of type signed short, either if its type is a system-specific
typedef or if the declaration is distant from the statement (yes,
certain development tools can make the latter less relevant) -- or
if the type might change later.

More generally, signed types narrower than int always promote to int,
but unsigned types narrower than int may promote either to int or
to unsigned int. If you have something that you know is unsigned
and narrower than int, you should probably cast it to unsigned int
and use "%u". If the value you're printing has a type that might
be wider than int, things get a bit more complicated, especially
if you can't assume a C99-conforming implementation.