C++ reading 16bit Wav file

前端 未结 5 972
感情败类
感情败类 2021-01-07 05:11

I\'m having trouble reading in a 16bit .wav file. I have read in the header information, however, the conversion does not seem to work.

For example, in Matlab if I r

5条回答
  •  礼貌的吻别
    2021-01-07 05:44

    (First of all about little-endian/big-endian-ness. WAV is just a container format, the data encoded in it can be in countless format. Most of the codecs are lossless (MPEG Layer-3 aka MP3, yes, the stream can be "packaged" into a WAV, various CCITT and other codecs). You assume that you deal with some kind of PCM format, where you see the actual wave in RAW format, no lossless transformation was done on it. The endianness depends on the codec, which produced the stream. Is the endianness of format params guaranteed in RIFF WAV files?)

    It's also a question if the one PCM sample is in linear scale sampled integer or there some scaling, log scale or other transformation behind it. Regular PCM wav files I encountered were simple linear scale samples, but I'm not working in the audio recording or producing industry.

    So a path to your solution:

    1. Make sure that you are dealing with regular 16 bit PCM encoded RIFF WAV file.
    2. While reading the stream, always read two bytes (char) at a time and convert the two chars into a 16 bit short. People showed this before me.
    3. The wave form you show clearly suggest that you either not estimated the frequency well (or you just have one mono channel instead of a stereo). Because the sampling rate (44.1kHz, 22KHz, 11KHz, 8kHz, etc) is just as important as the resolution (8 bit, 16 bit, 24 bit, etc). Maybe in the first case you had a stereo data. You can read it in as mono, you may not notice it. In the second case if you have mono data, then you'll run out of samples half way into reading the data. That's what it seems to happen according to your graphs. Talking about the other cause: the lower sampling resolutions (and 16 bit is also lower) often paired with lower sampling rates. So if your input data is the recording time, and you think you have a 22kHz data, but it's actually just 11kHz, then again you'll run out half way through from the actual samples and read in memory garbage. So either one of these.

    Make sure that you interpret and treat your loop iterator variable and the size well. It seems that size tells how many bytes you have. You'll have exactly half as much short integer samples. Notice, that Bjorn's solution correctly increments i by 2 because of that.

提交回复
热议问题