Importing longer audiofiles fails

[julianpoemp]

Procedure

Drag & Drop an longer audiofile (longer than 10 minutes) to the Drag&Drop field. After few seconds the website is broken and Chrome shows the message "Oh nein! Fehler beim Anzeigen dieser Webseite". If I try it using Firefox, it works.

Additional Informations

Browser: Chrome 56.0.2924.87 (64-bit) Operating System: MacOS 10.12.3 Audiofile Samplerate: 22050 Audiofile Duration: ca. 23 Minutes (or ca. 14 Minutes and 44100 SR) Audiofile Bitrate: 16

[raphywink]

Just redid all the wav file handling code of the EMU-webApp. Could you maybe send me the file that broke Chrome? Just so I can test if it now works. Thanks...

[raphywink]

Ok... so waiting for this: https://github.com/IPS-LMU/EMU-webApp/blob/master/app/scripts/services/Wavparserservice.js#L204 promise to resolve on the fraubovary_17_flaubert.wav file (ca. 56 mins long) causes Chrome to crash! How does OCTRA parse a wav file that long because using the normal "AudioContext" is not a feasible solution (as the files are resampled to the system default)?

[raphywink]

@MJochim: https://gitlab.lrz.de/ips-lmu/browser-signal-processing/blob/master/browser-signal-processing/browser-api/format-conversion.ts#L48 OCTRA seems to be using this to decode the audio data. If that is the case, you are not specifying the correct length of the OfflineAudioContext() as it is set to a constant 4096 samples. Funnily enough it doesn't seem to bother the decodeAudioData() function what the length is set to... but that might change as the API changes...

I just tested OCTRA and it seems to decode the audio file without problems... although you are using the same method as we are... WTF?

[julianpoemp]

I used the audiofile "2007_05_10_PC145USB.wav" (22050 S, 16bit, 23minutes). If you wish I can send you this file.

I'm using AudioContext and it works fine. Because of the resampling of wav files I use parts of the browser-signal-processing package:

1. A function to get the original sample rate from the wave file:

   private getSampleRate(buf: ArrayBuffer): number {
       let bufferPart = buf.slice(24, 28);
       let bufferView = new Uint32Array(bufferPart);
   
       return bufferView[ 0 ];
   }

2. The function "decodeAudioFile(file:ArrayBuffer, sampleRate:number):Promise" to get the Audiobuffer according to the original Sample Rate.

This works under the condition that the audio files are 16bit wave files.

I tried this with longer audio files and it all works fine. thanks @MJochim

[raphywink]

I take everything back... it is not the decoding that is the problem it is a conversion that we do post decoding that causes Chrome to crash... will take a closer look at it tomorrow...

[MJochim]

@raphywink I have never taken the length parameter of the OfflineAudioContext constructor to mean the size of any AudioBuffer the context might give me. I rather thought of it as something like a processing page size for the context.

Reading the spec does not completely clear the issue for me. However I do not think I used it wrongly because decodeAudioData is a method of a BaseAudioContext, which is a parent class of OfflineAudioContext, and which has no such thing as the length attribute that OfflineAudioContext has. It would therefore be odd for decodeAudioData to rely on the attribute.