write .wav file shows data in file size but no waveform

[GerdW]

Hi LKcire,

DBL representation for samples in a WAV file only likes sample values in the range of ±1!

This creates a "nicer" wavefile:

(by scaling the samples into the ±1 range…)

[billko]

---

@GerdW wrote:

Hi LKcire,

please stop creating new threads for the very same problem! Keep related things/VIs in just one thread/discussion!

(I merged your threads…)

Why don't you divide your complete VI into several sub-problems?

Why not investigate the WAV-file generation on its own?

See this:

It works for me as expected: a WAV file is generated, with the content I expect to be written…

Two notes:

• While it was suggested to change the samplerate to common values like 44.1kHz this is not needed. "Good" mediaplayers can handle any (reasonable) samplerate! Audacity (V3.0) or MediaplayerClassicHC play that 5kHz waveform nicely!
• Did you notice that red coercion dot at the WriteWaveFile function? LabVIEW doesn't handle your U16 data very well and converts the samples to an DBL array before saving…

---

I think you're on the right track; maybe it's not coercing to anything useful because it expects the data to be in one of the formats listed here.  Perhaps the data need to be converted to i16?

[GerdW]

Thanks Billko,

---

@billko wrote:
I think you're on the right track; maybe it's not coercing to anything useful because it expects the data to be in one of the formats listed here.

---

As usual it's all written in the LabVIEW help… 😄

[billko]

---

@GerdW wrote:

Thanks Billko,

---

@billko wrote:
I think you're on the right track; maybe it's not coercing to anything useful because it expects the data to be in one of the formats listed here.

---

As usual it's all written in the LabVIEW help… 😄

---

So, do you think it should be coerced to i16, or do we have to coerce to i32, subtract 16k, coerce to i16?

[GerdW]

Hi Billko,

---

@billko wrote:

---

@GerdW wrote:

Thanks Billko,

---

@billko wrote:
I think you're on the right track; maybe it's not coercing to anything useful because it expects the data to be in one of the formats listed here.

---

As usual it's all written in the LabVIEW help… 😄

---

So, do you think it should be coerced to i16, or do we have to coerce to i32, subtract 16k, coerce to i16?

---

No need for any coercions here: simply use ToI16 on those U16 data! (This will convert from U16 to I16 data without any changes to the bitpattern…)

[billko]

---

@GerdW wrote:

Hi Billko,

---

@billko wrote:

---

@GerdW wrote:

Thanks Billko,

---

@billko wrote:
I think you're on the right track; maybe it's not coercing to anything useful because it expects the data to be in one of the formats listed here.

---

As usual it's all written in the LabVIEW help… 😄

---

So, do you think it should be coerced to i16, or do we have to coerce to i32, subtract 16k, coerce to i16?

---

No need for any coercions here: simply use ToI16 on those U16 data! (This will convert from U16 to I16 data without any changes to the bitpattern…)

---

I was thinking that values higher than 16k would "wrap around" to become negative numbers if directly coerced, which might not be how the waveform was meant to be interpreted.

[billko]

This is the process I was thinking of:

Coerce to i32:

This is so you can contain all the values of the u16 without wrapping.

Subtract 16k:

"Center" the waveform.

Coerce to i16:

Properly centered waveform as i16.