Usually we use data[44:] to eliminate the header information of wav files, and then assume the rest data is PCM. This may not always be true.
For the wav header of a PCMWAVEFORMAT, we can usually understand that a structure as follows is at the front, and then followed by pure PCM, the format is as follows:
typedef struct _wave
{
char w_fileid[4];
uint32 w_chunksize;
char w_waveid[4];
char w_fmtid[4];
uint32 w_fmtchunksize;
uint16 w_fmttag;
uint16 w_nchannels;
uint32 w_samplespersec;
uint32 w_navgbytespersec;
uint16 w_nblockalign;
uint16 w_nbitspersample;
char w_datachunkid[4];
uint32 w_datachunksize;
} t_wave;
The above formats are compatible with all wav formats.
Where w_fileid is a fixed string RIFF, 4 bytes, and the next 4 bytes w_chunksize is the size of the entire file. The next four bytes are fixed WAVE.
However, in the modern wav file, in addition to the 44 bytes, there are many extended formats. Although these formats are also standard wav, the formats are slightly different.
We can take an mp3 audio file and transcode it to a wav file through ffmpeg, and then use ffprobe to inspect the format information, the output may be as follows:
$ ffprobe -show_format sample-argcv-audio.wav
ffprobe version 4.4.1 Copyright (c) 2007-2021 the FFmpeg developers
....
[FORMAT]
filename=sample-argcv-audio.wav
nb_streams=1
nb_programs=0
format_name=wav
format_long_name=WAV / WAVE (Waveform Audio)
start_time=N/A
duration=17.728000
size=567374
bit_rate=256035
probe_score=99
TAG:encoder=Lavf58.29.100
[/FORMAT]
Among them, we can see that there is a note TAG:encoder=Lavf58.29.100, which is actually not something that can be generated by a classic structure.
If we describe it in the same way, it might be possible to split this wav file in a format like the following.
typedef struct _wave_chunk {
char c_desc[4];
uint32 c_size;
char *data;
} t_wave_chunk;
typedef struct _wave
{
char w_fileid[4];
uint32 w_chunksize;
char w_waveid[4];
t_wave_chunk *w_chunks;
} t_wave;
The first 12 bytes are still the overall description. After that is an ordered set of subchunks. Subchunks will obey the following rules:
- desc (4 bytes),
- length (4 bytes，uint32 le),
- and data (length bytes)
If we parse sample-argcv-audio.wav, it looks like this:
RIFF (w_fileid, 4 bytes)
567366 (w_chunksize, uint32 le 4 bytes)
WAVE (w_waveid, 4 bytes)
: subchunk1 ( data[12:36] )
'fmt ' (w_fmtid, also c_desc, 4 bytes)
16 (w_fmtchunksize, also c_size, 4 bytes)
data (w_fmttag, w_nchannels, ... w_nbitspersample and so on，16 bytes in total)
: subchunk2 ( data[36:70] )
'LIST' (c_desc, 4 bytes)
26 (c_size, 4 bytes)
data (INFOISFT...Lavf58.29.100... 26 bytes in total)
: subchunk3 ( data[70:567374])
'data' (w_datachunkid, also c_desc, 4 bytes)
567296 (w_datachunksize, also c_size, 4 bytes)
data (data[78:567374]... 567296 bytes in total, which is the PCM data part we actually need)
EOF
Note: Different files may have other formats, but always conform to the subchunk organization as above. But the PCM we want is always in the data subchunk highlighted above.
As the above description, if we want to obtain the PCM signals correctly, we need to read the content of subchunk3 after removing the first 8 descriptions. That is, we need to cut off the first 78 bytes instead of 44 bytes to get the correct PCM.
In the naive format, subchunk2 does not exist, then 36 + 8 = 44, which is exactly the backward compatible format.
Here is a simple implementation in golang:
func WavGetDataChunkRange(fileName string) (int, int, error) {
fp, err := os.Open(fileName)
if err != nil {
return 0, 0, err
}
defer fp.Close()
sc := bufio.NewReader(fp)
sc.Discard(12)
buf := make([]byte, 4)
readBuf := func() error {
if n, e := sc.Read(buf); e != nil {
return e
} else if n != 4 {
return io.EOF
}
return nil
}
headerSize := 12
for {
if e := readBuf(); e != nil {
return 0, 0, e
}
log.Infof("@%v: desc: %v", headerSize, string(buf))
isData := strings.ToLower(string(buf)) == "data"
if e := readBuf(); e != nil {
return 0, 0, e
}
length := int(binary.LittleEndian.Uint32(buf))
log.Infof("length: %v", length)
if isData {
return headerSize + 8, headerSize + 8 + length, nil
}
sc.Discard(length)
headerSize += 8 + length
}
}
Sample Output:
@12: desc: fmt
length: 16
@36: desc: LIST
length: 26
@70: desc: data
length: 567296
input chunk from: 78 to 567374, err: <nil>
For the returned result, we can get data[78: 567374]. Specifically in the current format, it is data[78:], which is the correct PCM data block supposed to find.
References
