I noticed something funny with mpg123-decoder. Out of 226 MP3 files used by my app, a handful (6%) return sampleRate values that are way out of range.

-1282162537
-1289759728
-1295419197
-1308997852
-1316526638
-1321404159
5402816
5402816
823350018
839105538
841392158
848656542
873308273
894697243

The same files always return the same invalid values if I reload the page. There are no differences between the files besides being recordings of different notes – they were all VBR encoded at the same time and settings with LAME (in Reaper), and all have the same number of samples.

Here are a couple files that have the invalid values along with a couple that aren't affected: Example MP3s for mpg123-decoder sampleRate issue.zip

This doesn't affect my app, because I know the sample rate ahead of time so I can hard-code it. But I wanted to at least leave a record of what I found.

Environment: Electron 17.0.1, renderer process, with nodeIntegrationInWorker: true

I have found an issue trying to decode an Opus file using OggOpusDecoderWebWorker. I am getting the error as follows:

TypeError: Cannot read properties of null (reading 'decodeFrames')

I only need to decode a single file, so I am sing await (I know it is a bad idea, I have read the best practices guide in the docs).

import { OggOpusDecoder, OggOpusDecoderWebWorker } from 'ogg-opus-decoder';
class ... {

    public decode = async (path: string): Promise<AudioBuffer> => {
        try {
            const decoder = new OggOpusDecoderWebWorker();
            await decoder.ready;

            let response = await fs.readFileSync(path);

            const { channelData, samplesDecoded, sampleRate } = await decoder.decodeFile(new Uint8Array(response));
            response = null;
            const buffer = this.context.createBuffer(channelData.length, samplesDecoded, sampleRate);

            channelData.map((channel, index) => {
                buffer.copyToChannel(channel, index);
            });

            decoder.free();

            return buffer;
        } catch (error) {
            throw new Error(`opus decoder was unable to decode the file at ${path}: ${error}`)
        }
    }
}

Curiously OggOpusDecoder (without the web worker) works fine.

I am running into a similar issue with the mpeg decoder web worker (works without the worker), saying that URL scheme must be of type file, but I can open another issue if needed, maybe it's something in Electron's part or I am doing something wrong so I think one issue will suffice for now?

Thanks for your assistance.

Kinda nitpicky, but caused me a little pain. The "Demo" link on the opus-decoder page leads to a demo of ogg-opus-decoder, which is not the same thing. In particular, it doesn't support multichannel decoding, which is the one thing I wanted to test of opus-decoder.

All mp3 files that I decode with mpg123-decoder are consistently cut off about 15%-25% into the file. Files of the same length, bitrate, channel count, etc. seem to be decoded to the same point, but that point varies based on all those attributes (just not the contents of the file, it seems).

MP3 file permutations I've tried:

• Short files (2s) and long files (over a minute)
• Stereo, mono
• CBR, VBR
• 48kHz, 44.1kHz, 11025 Hz

Other things I've tried:

• Both my fork (#6) and the unmodified library
• Updating mpg123 submodule to 1.29.1

With DevTools, I verified that the full file is being passed to MPEGDecoder.decode - the byte length of the data argument length matches the file's size in bytes. Then it loops through each frame. Oddly, the first frame is always 0 samples. Then there are a series of 1152-sample decoded frames, then it ends. So it's looping through the entire source file, but only decoding up to ~1/4 of it.

I've hit a wall with trying to figure out what's going on here. Any ideas?

Hi,

When errors are thrown, the .catch() promise doesn't get resolved. Let me know if you need any more details to reproduce or if this is what you'd expect.

Thanks

Hi,

I'm having some difficulties with the opus decoder, would you be able to answer a few questions over email?

You can contact me at [email protected] if this is ok?

Thanks

So I noticed your speedy work on adding multichannel support. It works great with the test file we added here. Awesome work.

I have a few files closer to my use case that fail in the demo. They were created using this script. The third one is actually a snippet of the aforementioned test file, chopped out by that script. They all play fine with ffplay and Reaper (screenshots are from Reaper), but fail in the demo.

Broken1

Broken2

Broken3

broken.zip

In my tests, I check the time elapsed between decoded frames and compare it to the length of the real decoded audio. I am getting longer audio buffers than the total elapsed time. (Elapsed time = real-time, i.e. live recording + encoding + network latency + decoding.)

The reason I checked in the first place is b/c my app has a creeping latency I could not otherwise debug or buffer. The tests seem to prove the audio is actually getting longer (not latency).

I don't know if the source of this bug is the decoder or the encoder. I will have to do some tests to determine. What do you use to encode ogg?

Whipped up some typings for Typescript. 😊

I've never packaged typings with an NPM package before, but I think I did it right. The types work great when copied into my app as ambient typings, but VS Code doesn't recognize them when using npm link to link to the package. Could be something on my end, though.

This update adds web worker support to ogg-opus-decoder and mpg123-decoder. When loaded as a web worker, one can asynchronously load audio files, like this:

const worker = new Worker('/path/to/ogg-opus-decoder.min.js');

worker.addEventListener('message', (msg) => {
  const { channelData, samplesDecoded, sampleRate, audioId } = msg.data;
  const audioBuffer = new AudioBuffer({
    numberOfChannels: channelData.length,
    length: samplesDecoded,
    sampleRate,
  });
  // do something with the AudioBuffer
});

worker.postMessage({
  command: 'decode',
  compressedData: opusFileArrayBuffer,
  audioId: "example_sound" 
}, [mpegData]);

README files have been updated with info on how to use libraries as Web Workers. ogg-opus-decoder is being used as a Worker in production across many devices with great success. mpg123-decoder is only decoding about 150-200ms of my 2-3 second MP3 clips, and I'm not sure why, but the web worker aspect is working well – it has the same issue when called as an NPM module. Still working on that... but I wanted to post this so that you can merge it in if you like!

Closes #5.

Greetings, I have this module working in a single web page, from an encoder directly to the decoder, nice. But when I have piped the same encoded ogg chunks over a network (i.e. through a node stream) the decoder does nothing with the data (no onDecode events fired), and after several attempts issues up the error Could not enqueue bytes for decoding. You may also have invalid Ogg Opus file. The second part is not true; I have verified the chunks are exactly the same both sides of the network. I really doubt this is an issue with the decoder, but I have to check. Also the error is claimed to be uncaught, despite all attempts, and seems to be uncatchable this side of wasm. I have tried checking for the decoder to be ready, freeing it, etc.

Hello and thanks for this awesome lib!

ogg-opus-decoder works fine in Chrome and Firefox, but not in Safari. It throws a CompileError: WebAssembly.Module doesn't parse at byte 0

Is there anything I can do to get around this, or is it really a Safari limitation?

Thanks anyway!

This library would benefit from a more modular / plugin architecture so that the common code can be reused across decoders.

• Tree shaking common code used across modules for smaller build size
• Simpler code structure (less duplicated scaffolding code, easier to maintain)
• Common interface for new audio decoders to implement

New library layout might look like:

• @wasm-audio-decoders/decoder-api -> contains the shared scaffolding code for Web Worker / general decoding API.
• @wasm-audio-decoders/mpeg
• @wasm-audio-decoders/opus
• @wasm-audio-decoders/ogg-opus
• @wasm-audio-decoders/flac
• @wasm-audio-decoders/ogg-flac
• @wasm-audio-decoders/vorbis
• @wasm-audio-decoders/ogg-vorbis

Add builds that support Web Assembly SIMD. This should significantly speed up decoding.

• Must be backwards compatible with browsers that don't support this feature, since it relatively new.
  • Could use feature detection and fall back to the non-SIMD build if not available.
• Update configure options to allow any SIMD optimized code to be added during pre-processing.
• The deinterleave function may be able to be optimized to use SIMD to more quickly iterate over the data, potentially by creating a custom function for this build. https://github.com/WebAssembly/simd/blob/master/proposals/simd/SIMD.md