wav - RangeError: Maximum call stack size exceeded

[dj-nuo]

Is there an existing issue for this?

• I have searched the existing issues

music-metadata version

11.10.3

Current Behavior

Getting this error when trying to parse these 2 wav files: RangeError: Maximum call stack size exceeded

Code:

const metadata = await parseFile(filePath);

Files (too large to upload):

1. https://drive.google.com/file/d/1vaUpItsEH4aTOtAEU3Ip6whtp5yii_UH/view?usp=sharing
2. https://drive.google.com/file/d/1csJqQWSCTcreIHpIkGjOOmEhXNrxOG4F/view?usp=sharing

Expected Behavior

No response

Attached audio sample?

• I have provided sufficient information to reproduce the issue

[Borewit]

@dj-nuo, both files parse without any issue on my end. Used node version 22.17.0

[dj-nuo]

Yeap, just tested. Can be reproduced with Node < 22.
Anything you can/want to do about this issue in these earlier Node versions?

(my use case requires old Electron version to support MacOS 10.15+, and this Electron comes with Node 18

[Borewit]

Tested with Node version:

• v18.5.0
• v18.20.8
• v20.18.3
• v20.19.6

parsing your files just fine.

I need the issue to be reproducable. It looks like the issue you have is not caused by this library.

You may try to demonstrate it with a minimal reproducible example, which usually helps to narrow down the issue.

[dj-nuo]

Minimal reproduction:

// package.json
{
  "name": "my-electron-app",
  "main": "main.js",
  "scripts": {
    "start": "electron ."
  },
  "devDependencies": {
    "electron": "26.6.10",
    "music-metadata": "11.10.3"
  }
}

// main.js
async function main() {
    const { parseFile } = await import("music-metadata");
    console.log(parseFile);
    const file = 'Alessandro Scellino - Dinner In The Jungle (FS Basic Rhythm Mix) Rune quick edit.wav';
    const metadata = await parseFile(file, { skipCovers: true });
    console.log(metadata);
}

console.log("Hello World");
main();

How to run

npm start

Bug

npm start

> start
> electron .

Hello World
[AsyncFunction: parseFile]
(node:41951) UnhandledPromiseRejectionWarning: RangeError: Maximum call stack size exceeded
    at decodeASCII (file:///Users/aleksej/Downloads/minimal-mm/node_modules/token-types/node_modules/@borewit/text-codec/lib/index.js:101:19)
    at textDecode (file:///Users/aleksej/Downloads/minimal-mm/node_modules/token-types/node_modules/@borewit/text-codec/lib/index.js:30:20)
    at StringType.get (file:///Users/aleksej/Downloads/minimal-mm/node_modules/token-types/lib/index.js:390:16)
    at ListInfoTagValue.get (file:///Users/aleksej/Downloads/minimal-mm/node_modules/music-metadata/lib/riff/RiffChunk.js:26:72)
    at FileTokenizer.readToken (file:///Users/aleksej/Downloads/minimal-mm/node_modules/strtok3/lib/AbstractTokenizer.js:35:22)
    at async WaveParser.parseRiffInfoTags (file:///Users/aleksej/Downloads/minimal-mm/node_modules/music-metadata/lib/wav/WaveParser.js:159:27)
    at async WaveParser.readWaveChunk (file:///Users/aleksej/Downloads/minimal-mm/node_modules/music-metadata/lib/wav/WaveParser.js:62:21)
    at async ParserFactory.parse (file:///Users/aleksej/Downloads/minimal-mm/node_modules/music-metadata/lib/ParserFactory.js:92:9)
    at async parseFile (file:///Users/aleksej/Downloads/minimal-mm/node_modules/music-metadata/lib/index.js:41:20)
    at async main (/Users/aleksej/Downloads/minimal-mm/main.js:8:22)
(Use `Electron --trace-warnings ...` to show where the warning was created)
(node:41951) UnhandledPromiseRejectionWarning: Unhandled promise rejection. This error originated either by throwing inside of an async function without a catch block, or by rejecting a promise which was not handled with .catch(). To terminate the node process on unhandled promise rejection, use the CLI flag `--unhandled-rejections=strict` (see https://nodejs.org/api/cli.html#cli_unhandled_rejections_mode). (rejection id: 1)

[dj-nuo]

@Borewit , I narrowed the issue even further. Minimal reproduction above is only reproducible on Mac (Apple Silicon). Windows & Intel Mac work fine.

Have you been able to reproduce?

[Borewit]

Sorry @dj-nuo , I missed your previous message. I only have Intel based systems around, so I cannot try directly.
But I did some investigation. Using AI I could get to this possible cause:

On Electron 26.6.10 you’re running Node 18.16.1 on V8 11.6.189.22.
Electron Releases

Your crash is happening inside @borewit/text-codec’s decodeASCII, called while music-metadata decodes RIFF INFO strings from a WAV.

What triggers RangeError: Maximum call stack size exceeded here is usually not recursion, it’s this JS pattern:

building a string via String.fromCharCode(...bytes) or String.fromCharCode.apply(null, bytes)

If bytes is large enough, you hit V8’s hard limits around argument count / stack space for a single call, and V8 throws the same Maximum call stack size exceeded RangeError.

To investigate if that is indeed the issue, can you try to run the following code:

// threshold-textDecode-ascii.mjs
// Run: node threshold-textDecode-ascii.mjs
//
// Finds the maximum Uint8Array length that still works with:
//   textDecode(bytes, "ascii")
// and the minimum length that fails with RangeError.
//
// Note: run this under the same runtime that reproduces the issue
// (Electron 26.6.10 main process / its Node/V8).

import { textDecode } from "@borewit/text-codec";

function makeBytes(n) {
  const a = new Uint8Array(n);
  a.fill(65); // 'A'
  return a;
}

function test(n) {
  const bytes = makeBytes(n);
  // actual call under test:
  return textDecode(bytes, "ascii");
}

function findThreshold() {
  let lo = 0;
  let hi = 1024;

  // Exponential search for first failure
  while (true) {
    try {
      test(hi);
      lo = hi;
      hi *= 2;

      // prevent runaway allocations
      if (hi > 200_000_000) {
        return { maxOk: lo, minFail: null };
      }
    } catch (e) {
      if (!(e instanceof RangeError)) throw e;
      break;
    }
  }

  // Binary search between lo (ok) and hi (fail)
  while (hi - lo > 1) {
    const mid = lo + Math.floor((hi - lo) / 2);
    try {
      test(mid);
      lo = mid;
    } catch (e) {
      if (!(e instanceof RangeError)) throw e;
      hi = mid;
    }
  }

  return { maxOk: lo, minFail: hi };
}

console.log("Testing @borewit/text-codec textDecode(..., 'ascii') threshold...");

const t0 = Date.now();
const { maxOk, minFail } = findThreshold();
const dt = Date.now() - t0;

console.log(`max OK size:   ${maxOk.toLocaleString()} bytes`);
if (minFail !== null) console.log(`min FAIL size: ${minFail.toLocaleString()} bytes`);
else console.log("No failure found up to cap.");
console.log(`elapsed: ${dt} ms`);

On my end it outputs:

"C:\Program Files\nodejs\node.exe" "C:\Users\Borewit\IdeaProjects\text-codec\test\limit.js"
Testing @borewit/text-codec textDecode(..., 'ascii') threshold...
max OK size:   125.189 bytes
min FAIL size: 125.190 bytes
elapsed: 71 ms

If the value is lower running this code on Electron 26.6.10 on your ARM based Apple, we narrowed down the issue.

[dj-nuo]

This is what I get on ARM Mac:

Testing @borewit/text-codec textDecode(..., 'ascii') threshold...
max OK size:   105,187 bytes
min FAIL size: 105,188 bytes
elapsed: 54 ms

This is what I get on ARM Windows 11 (as virtual machine using Parallels Desktop), where there is no issue:

Testing @borewit/text-codec textDecode(..., 'ascii') threshold...
max OK size:   124,831 bytes
min FAIL size: 124,832 bytes
elapsed: 254 ms

And this is on Intel Mac:

Testing @borewit/text-codec textDecode(..., 'ascii') threshold...
max OK size:   120,534 bytes
min FAIL size: 120,535 bytes
elapsed: 143 ms

[Borewit]

There is a difference, but it is not huge. I checked length of data being decoded, using your sample files.

There is no calling decodeASCII, provided by #borewit\text-codec, with more then 4 bytes.
That is pretty weird to end up in a call stack size exceeded.

Are you sure you are not parsing multiple files in a loop?

Can you modify node_modules/@borewit/text-codec/lib/index.js:

let n=0;

export function textDecode(bytes, encoding = "utf-8") {
    console.log(`textDecode: n=${n++}, ${bytes.length} bytes, using encoding=${encoding}`);
    switch (encoding.toLowerCase()) {
        case "utf-8":
        case "utf8":
            if (typeof globalThis.TextDecoder !== "undefined") {
                return new globalThis.TextDecoder("utf-8").decode(bytes);
            }
            return decodeUTF8(bytes);
        case "utf-16le":
            return decodeUTF16LE(bytes);
        case "ascii":
            return decodeASCII(bytes);
        case "latin1":
        case "iso-8859-1":
            return decodeLatin1(bytes);
        case "windows-1252":
            return decodeWindows1252(bytes);
        default:
            throw new RangeError(`Encoding '${encoding}' not supported`);
    }
}

And then parse your file Madoona - Everybody (Dan Idjuts edit) (Rune fix).wav

Which should output something like:

textDecode: n=0, 3 bytes, using encoding=latin1
textDecode: n=1, 4 bytes, using encoding=latin1
textDecode: n=2, 4 bytes, using encoding=ascii
textDecode: n=3, 4 bytes, using encoding=ascii
textDecode: n=4, 4 bytes, using encoding=ascii
textDecode: n=5, 4 bytes, using encoding=ascii
textDecode: n=6, 4 bytes, using encoding=ascii
textDecode: n=7, 4 bytes, using encoding=ascii
textDecode: n=8, 4 bytes, using encoding=ascii
textDecode: n=9, 4 bytes, using encoding=ascii
textDecode: n=10, 4 bytes, using encoding=ascii
textDecode: n=11, 4 bytes, using encoding=ascii

[dj-nuo]

Ok, I tried fixing it using LLM and, courtesy of Opus 4.5 in Antigravity, it worked 🙂

This patch fixes issue with both .wav files that I send you, as well as few other .m4a files (that I didn't send you).
New m4a files: https://drive.google.com/file/d/1uNSYS2ijnT2yx45-fXN64MFArDk3XPQR/view?usp=sharing

First: token-types+6.1.1.patch

diff --git a/node_modules/token-types/node_modules/@borewit/text-codec/lib/index.js b/node_modules/token-types/node_modules/@borewit/text-codec/lib/index.js
--- a/node_modules/token-types/node_modules/@borewit/text-codec/lib/index.js
+++ b/node_modules/token-types/node_modules/@borewit/text-codec/lib/index.js
@@ -98,10 +98,18 @@ function decodeUTF16LE(bytes) {
     return out;
 }
 function decodeASCII(bytes) {
-    return String.fromCharCode(...bytes.map((b) => b & 0x7f));
+    let out = "";
+    for (let i = 0; i < bytes.length; i++) {
+        out += String.fromCharCode(bytes[i] & 0x7f);
+    }
+    return out;
 }
 function decodeLatin1(bytes) {
-    return String.fromCharCode(...bytes);
+    let out = "";
+    for (let i = 0; i < bytes.length; i++) {
+        out += String.fromCharCode(bytes[i]);
+    }
+    return out;
 }
 function decodeWindows1252(bytes) {
     let out = "";

Second: @borewit+text-codec+0.2.0.patch

diff --git a/node_modules/@borewit/text-codec/lib/index.js b/node_modules/@borewit/text-codec/lib/index.js
index bc9c9c9..d377d32 100644
--- a/node_modules/@borewit/text-codec/lib/index.js
+++ b/node_modules/@borewit/text-codec/lib/index.js
@@ -96,10 +96,18 @@ function decodeUTF16LE(bytes) {
     return out;
 }
 function decodeASCII(bytes) {
-    return String.fromCharCode(...bytes.map((b) => b & 0x7f));
+    let out = "";
+    for (let i = 0; i < bytes.length; i++) {
+        out += String.fromCharCode(bytes[i] & 0x7f);
+    }
+    return out;
 }
 function decodeLatin1(bytes) {
-    return String.fromCharCode(...bytes);
+    let out = "";
+    for (let i = 0; i < bytes.length; i++) {
+        out += String.fromCharCode(bytes[i]);
+    }
+    return out;
 }
 function decodeWindows1252(bytes) {
     let out = "";

Can you please release the fix as an official package?)
I also didn't run any of your repo tests.

p.s. idk why I didn't try to patch the package when I first got the error, but glad that now the issue will be resolved 🤪

[Borewit]

This patch fixes issue with both .wav files that I send you, as well as few other .m4a files (that I didn't send you).

@dj-nuo Please not not mix issues, raise a new issue.

[Borewit]

Please note PR Borewit/text-codec#25 and https://github.com/Borewit/text-codec/releases/tag/v0.2.1