Problem reading WAVEFORMATEX


#1

I’ve noticed that reading WAVEFORMATEX audio files, the execution falls inside this else:
See juce_WavAudioFormat.cpp near line 205.

if (format == 3)
  usesFloatingPointData = true;
 else if (format != 1)
   bytesPerFrame = 0;

'cause my format is -2.

So the next chunk I get lengthInSamples equal to 0.

else if (chunkType == chunkName ("data"))
{
   // get the data chunk's position 
  dataLength = length;
  dataChunkStart = input->getPosition();
  lengthInSamples = (bytesPerFrame > 0) ? (dataLength / bytesPerFrame) : 0;

  hasGotData = true;
}

#2

Yes, well that’s what it does if it doesn’t recognise the format. What sort of format is -2 anyway?


#3

It was a WAVEX file created with libsndfile. MS WAVE with WAVEFORMATEX.

With Audition and other editor no problem for reading.

http://msdn2.microsoft.com/en-us/library/ms790436.aspx


#4

Ah, I’ve not looked at that stuff yet. Probably not too hard to add support for.


#5

Has WAVEFORMATEXTENSIBLE file support been added to JUCE? I’m using JUCE version 1.45.

I’m having problems with a 5.1 .wav file with a waveformatextensible header, but not a file with a waveformatex header. The code below just assumes that the header is waveformatex, not waveformatextensible. (my question continued below)

//=========================== playback classes ================================
usb_playback_t::usb_playback_t(audio_file_t& file)
:m_sample_stream(0)
,m_chunksSent(0) // # chunks queued for USB transmission
,m_chunksXmitted(0) // # chunks xmitted down USB channel
,m_q(new chunk_queue_t()) // chunk queue manager
,m_num_chunks(20) // max # of chunk buffers managed by queue
,m_zipsSent(0) // statistic: # ZIP chunks xmitted
,m_current_channel(0)
{
m_sample_stream = sample_stream_t::createInstance(file); //somehow this populates the datasize.

The wave file class, in the Juce Library has a wav_header_t which is WAVEFORMATEX, not WAVEFORMATEXTENSIBLE.
The member “data_size” is set improperly when the file type is WAVEFORMATEXTENSIBLE. It’s set to the “channel mask” value.

virtual bool openForRead() {
if (parent::openForRead()) {
wav_header_t header;

data_size = header.data_size;

I’m wondering if you can confirm this is a bug, and can confirm if this has been fixed in a later version of JUCE.
Our channels are playing back out of order, and I believe it’s because the m_seek_start member variable is 0x2C an offset which points to the middle of the GUID field of the header of the wave file
when there’s a waveformatextensible header. The surrounds come out the L,R.
With a waveformatex header (same audio data), the data size is 0X774ec4 (valid value, not bogus value)
and the m_seek_start is still 0x2C, which points to the byte right before the first valid sample in the wave file (on the final ‘00’ in ‘d’ ‘a’ ‘t’ ‘a’ 4E 77 00 00)


#6

when I hack up the source code and do this in wave_file.cpp, (line 50)

m_seek_start = 0x44; //tell();

the channels come out in the correct order. so this is definitely part of my problem.

Please let me know if there’s a bugfix.


#7

I don’t fully understand your question, but it’s almost certainly something that was fixed years ago. I really can’t help with problems in v1.45, I’m afraid.


#8