reading wav files

Discussion in 'C Programming' started by Sarchiapone, Jan 30, 2010.

  1. 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

    If your use is a cryptographic one, comp.sci.crypt is a good place to
    ask about random numbers.
    Ben Bacarisse, Jan 31, 2010
    1. Advertisements

  2. Sarchiapone

    Bill Reid Guest

    Anybody can tell the difference if they use Monster(TM)
    speaker wire...
    Bill Reid, Jan 31, 2010
    1. Advertisements

  3. 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.
    Keith Thompson, Jan 31, 2010
  4. Sarchiapone

    bartc Guest

    (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..)
    bartc, Feb 1, 2010
  5. Sarchiapone

    Sarchiapone Guest

    Il Mon, 01 Feb 2010 13:42:07 +0000, bartc ha scritto:
    I tried, and it gave me different results.
    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.
    Sarchiapone, Feb 1, 2010
  6. 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.
    Antoninus Twink, Feb 1, 2010
  7. Sarchiapone

    Phil Bradby Guest

    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??

    Phil Bradby, Feb 1, 2010
  8. 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.

    Andrew Poelstra, Feb 1, 2010
  9. 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, Feb 1, 2010
  10. 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.]
    Peter Nilsson, Feb 1, 2010
  11. 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.
    Keith Thompson, Feb 1, 2010
    1. Advertisements

Ask a Question

Want to reply to this thread or ask your own question?

You'll need to choose a username for the site, which only take a couple of moments (here). After that, you can post your question and our members will help you out.