[question] How do I get sample bit width values from a wave file？

[SilvaQ]

@therewasaguy

How do I get sample values from a wave file?

[thijstriemstra]

There's not a specific api for this yet, pr is welcome. You can use wavesurfer.backend.ac.sampleRate.

[thijstriemstra]

Oh you asked for bit width, not sample rate. There is no API for this, see https://stackoverflow.com/questions/70071519/how-to-get-sample-rate-bit-depth-and-number-of-channels-with-web-audio-api and w3c/webcodecs#24

WebAudio has been around for 10 years and I'm always amazed at how incomplete it is.

[SilvaQ]

Hi, I am very glad to see your reply. I am honored to discuss and ask questions with you。

As for bitsperSample, all the data marked by our company are strictly required to be in wav format。

Fortunately, wav files have a fixed header format。

and i found that the original data we requested was still within the range that we could control, so I tried to parse the header information to check whether this value could be obtained, and found that it was OK：

                const dv =new DataView(arraybuffer)
                if(dv.getUint32(0,false) === 1380533830){
                    console.log("RIFF file")
                    const bitsPerSample = dv.getInt16(34,true)
                    console.log(bitsPerSample)
                }else{
                    console.log("not RIFF file")
                }

I hope you can also check to see if there is any lack of consideration in my practice.

If my idea works, I hope we can bind RIff-related parameters to wavesurfer. We also do more custom operations with these values when drawing the waveform.

For example, if we want to set a maximum peak, the audio area above that peak will be considered problematic.(In our scenario, if max amplitude was 3k, amplitude beyond the peak of the audio segment would be invalid for us and would be clipped in the future)

Therefore, we need to draw peak reference lines like audition to assist the annotators in accurately locating the invalid segments。

[SilvaQ]

The conversion formula I use is:

amplitude = peak * Math.pow(2, bitsPerSample - 1 ) // bitsPerSample -1 because we have a plus or minus, it takes one bit

[SilvaQ]

Do you think it is acceptable for us to extend the RIFF field and only add the metadata information to.wav for the time being, and separate the logic to provide more header structure information in the future?

[thijstriemstra]

extend the RIFF field and only add the metadata information to.wav for the time being, and separate the logic to provide more header structure information in the future?

Sounds good.

[SilvaQ]

We have arraybuffer but we delete it when we run out of memory probably because it saves memory, it always ends up being null。

I thought about adding audio headers in the same way as above, but since I haven't seen any format other than wav, it feels a bit rushed。

So I'm assuming that whatever audio is, it's not going to have a very large header, either 100 bytes or 1Mb, and whoever needs it knows how big it is and knows how to parse it, right ?

So if we put all buffers together, just like backends, who needs what can get and use it according to their own needs. In my opinion, it is best at this stage.

With these concerns in mind, I suggest that we attach a buffers object to the wavesurfer instance to store all possible buffers. For example, arraybuffers will also move here.

At the same time, the header size can be customized, such as fileHeaderBufferSize. After loading the file, the buffer is intercepted according to fileHeaderBufferSize and stored in the fileHeaderBuffer field under this buffers.

I wrote a pseudo code. Take a look：

wavesurfer
{
  backends:....
  buffers:{
    arrayBuffer: ....
    HeaderBuffer: .....  // buffer size depends on headerBufferSize param
    other buffers.....
  }
  params:{
    ...
    headerBufferSize: 100; // defaul only 100 byte   filedata[0:100]
  }
}

@thijstriemstra

Do you think it is acceptable? If it is acceptable, I will submit PR according to this plan。

[thijstriemstra]

So if we put all buffers together, just like backends, who needs what can get and use it according to their own needs. In my opinion, it is best at this stage.

It's probably easier to give feedback on a pull request. Wavesurfer.js does have performance issues with large files and as long as this change doesn't make things worse it should be ok.

[thijstriemstra]

** I will submit PR according to this plan**

Did this get submitted?

[SilvaQ]

@thijstriemstra
I have been busy recently and have no plan to submit PR. If I have time, I will give priority to it. If other partners have time, they can go first