WAV_FORMAT_PCM versus WAV_FORMAT_EXTENSIBLE

[G29]

I tried opening a wav file created in SoX 14.4.2 and got an unsupported format error on load.

The original file was generated by REW as a 32-bit 192kHz white noise file that was converted to a raw format by SoX and back again to wav.

It appears SoX is specifying the type as WAV_FORMAT_EXTENSIBLE instead of WAV_FORMAT_PCM.

I used "soxi -V4" to dump the wav header information (in both source and reconstituted files) and the difference appears to be WAV_FORMAT_PCM vs WAV_FORMAT_ENTSIBLE (e.g. signed, 32-bit, 192kHz, bitrate, etc. all the same sans the hearer size and extensible section - 36 bytes larger).

Does anyone know how to force SoX to generate the WAV_FORMAT_PCM format or
if there is a tool to convert EXTENSIBLE to PCM or
if there is a way for REW to load the WAV_FORMAT_EXTENSIBLE file ?

Thanks much.

 

[John Mulcahy]

I'll see if I can add support for the extensible format in the next build.

 

[G29]

I'll see if I can add support for the extensible format in the next build.

John,

Thanks much, that would be very helpful.

 

[ddude003]

It seems that SoX via ffmpeg will set the header to WAV_FORMAT_EXTENSIBLE if it contains a sampling rate greater than 48000... No way around it unless you hack the source code...

 

[G29]

It seems that SoX via ffmpeg will set the header to WAV_FORMAT_EXTENSIBLE if it contains a sampling rate greater than 48000... No way around it unless you hack the source code...

According to some of the online docs, the EXTENSIBLE type is for higher sample rates, larger bitdepths, higher channel counts, etc.

For my initial test files, I used soxi to find the data size, chopped off the head of each file leaving just the (n-byte) data portion and then did a binary diff. Both files' data sections were identical so one could possible reconstitute the header and remove the first chunk as a kluge.

 

[ddude003]

Well sure you could kludge the wave file itself and who knows what an app or util would do if it found a WAV_FORMAT_PCM file that was actually a WAV_FORMAT_EXTENSIBLE because higher sample rates, larger bit depths, higher channel counts, yada, yada... I thought you were looking for a SoX solution... Luke, hack the source... These aren't the bits your looking for...

/* We use the known constant frame size for the codec if known, otherwise
* fall back on using AVCodecContext.frame_size, which is not as reliable
* for indicating packet duration. */
frame_size = av_get_audio_frame_duration(enc, enc->block_align);

waveformatextensible = (enc->channels > 2 && enc->channel_layout) ||
enc->sample_rate > 48000 ||
enc->codec_id == AV_CODEC_ID_EAC3 ||
av_get_bits_per_sample(enc->codec_id) > 16;

 

[John Mulcahy]

SoX is behaving correctly per the WAV spec, but support for WAV_FORMAT_EXTENSIBLE can be patchy amongst apps generally and those that don't support Extensible will be happy with PCM (or sometimes Float if the data is float, but again can be patchy) as the format code.

 

[G29]

John,

THANKS MUCH FOR THE UPDATE !!!