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