Offset and length were out of bounds for the array or count is greater than the number of elements from index to the end of the source collection.

[JayH77]

Hi,

I am trying to convert a WAV file to MP3 (this works fine for MP3 to MP3) using the following code:

using (var reader = new NAudio.Wave.AudioFileReader(Server.MapPath(my_upload_path))) { using (var writer = new NAudio.Lame.LameMP3FileWriter(Server.MapPath(my_converted_path), reader.WaveFormat, 64)) { reader.CopyTo(writer); } }

But I'm getting the following error:

System.ArgumentException: Offset and length were out of bounds for the array or count is greater than the number of elements from index to the end of the source collection. at System.IO.BinaryReader.Read(Byte[] buffer, Int32 index, Int32 count) at NAudio.Wave.WaveFormat.FromFormatChunk(BinaryReader br, Int32 formatChunkLength) at NAudio.FileFormats.Wav.WaveFileChunkReader.ReadWaveHeader(Stream stream) at NAudio.Wave.WaveFileReader..ctor(Stream inputStream, Boolean ownInput) at NAudio.Wave.WaveFileReader..ctor(String waveFile) at NAudio.Wave.AudioFileReader.CreateReaderStream(String fileName) at NAudio.Wave.AudioFileReader..ctor(String fileName) at portal.UserControls.ModalAssessmentAudio.ConvertAudioFileUsingLame() at portal.UserControls.ModalAssessmentAudio.ProcessAudioFile()]

[markheath]

Seems like there might be something unusual about your WAV file. Can you load it with WaveFileReader

[nrobert]

I got the same behaviour with a WAV file, for both AudioFileReader and WaveFileReader

What I found is that the "bits per sample" value of my file is not set (my Mac OS Finder app doesn't display it), and when I open the file with Audacity and export it as a WAV again, I got the value (16) and the new WAV file can be opened so it looks like it is linked to this value.

[nrobert]

Ok, after cloning the repo and digging into the sources, the exception that I got comes from here: https://github.com/naudio/NAudio/blob/master/NAudio/Wave/WaveFormats/WaveFormatExtraData.cs#L43

The byte array size seems to be arbitrary set to 100 at the beginning: https://github.com/naudio/NAudio/blob/master/NAudio/Wave/WaveFormats/WaveFormatExtraData.cs#L16

And in my case, my content length is 466.

@markheath , what should be the best approach for this one? Setting a bigger arbitrary value (see your comment below):

try with 100 bytes for now, increase if necessary

Or should be enlarge the size of the byte[] with a test (but there is still the size definition in the MarshalAs that should be taken into account):

internal void ReadExtraData(BinaryReader reader)
{
    if (this.extraSize > 0)
    {
        if (extraSize > extraData.Length)
        {
            extraData = new byte[extraSize];
        }

        reader.Read(extraData, 0, extraSize);
    }
}

[markheath]

Yes, a bit of a shame - the read extra data should definitely check and at the very least throw a better exception. Obviously as you point out, the marshalling part might not work, but would depend on what you were doing with it - are you passing it through to ACM methods for format conversion? What is the actual compression type you are using?

[nrobert]

In my case, I was just trying to cut the file.

So I'm opening it with using (WaveFileReader reader = new WaveFileReader(inPath))

[markheath]

I mean, what is the underlying WaveFormat format tag? Normal PCM WAV files don't have extra data like this, so you are obviously looking at an unusual compression format or maybe a corrupt WAV file

[nrobert]

Sorry for the misunderstanding. I could listen to the file with VLC so doesn't seems corrupted.

Here are the info I got from afinfo tool on my Mac

File type ID: WAVE Num Tracks: 1

Data format: 2 ch, 8000 Hz, 0x6D730011 (0x00000000) 0 bits/channel, 2048 bytes/packet, 2041 frames/packet, 0 bytes/frame no channel layout. estimated duration: 27.043250 sec audio bytes: 217088 audio packets: 106 bit rate: 64219 bits per second packet size upper bound: 2048 maximum packet size: 2048 audio data file offset: 512 optimized

[rjschnorenberg]

We received a file from a customer with this exact same issue, it was created by a G L87 digital voice recorder, the fmt chunk is padded with zeroes to make the entire header exactly 512 bytes.