[Fix] RawAudio.toBlob() ignores TypedArray byteOffset/length (#1704)#1712
Open
yushuosun wants to merge 1 commit into
Open
[Fix] RawAudio.toBlob() ignores TypedArray byteOffset/length (#1704)#1712yushuosun wants to merge 1 commit into
yushuosun wants to merge 1 commit into
Conversation
encodeWAV() sized the WAV data chunk from each view's length but built the Blob payload from chunk.buffer, the entire underlying ArrayBuffer. For views with a non-zero byteOffset or a length shorter than the buffer (e.g. the output of Float32Array.subarray()), the header and payload disagreed and decoders played the wrong window. Emit Uint8Array views that honor each chunk's byteOffset/byteLength.
There was a problem hiding this comment.
Pull request overview
Fixes incorrect WAV payload generation in RawAudio.toBlob()/encodeWAV() when audio chunks are TypedArray views (e.g., Float32Array.subarray(...)) with non-zero byteOffset or shortened byteLength, ensuring the WAV header and data payload refer to the same sample window.
Changes:
- Update
encodeWAV()to append per-chunk byte-accurate views (Uint8Arrayoverbuffer + byteOffset/byteLength) instead of the full backingArrayBuffer.
💡 Add Copilot custom instructions for smarter, more guided reviews. Learn how to get started.
| view.setUint32(40, totalLength * 4, true); | ||
|
|
||
| return new Blob([buffer, ...chunks.map((chunk) => /** @type {ArrayBuffer} */ (chunk.buffer))], { | ||
| return new Blob([buffer, ...chunks.map((chunk) => new Uint8Array(chunk.buffer, chunk.byteOffset, chunk.byteLength))], { |
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Motivation
RawAudio.toBlob()produces a WAV whose audio is wrong (e.g. leading silence / only the first N samples) when the audio is aTypedArrayview with a non-zerobyteOffsetor a length shorter than its backing buffer — anything coming fromFloat32Array.subarray(...), for example (#1704).Root cause
In
packages/transformers/src/utils/audio.js,encodeWAV()writes the WAV data-chunk size from each view's length (chunk.length), but builds theBlobpayload fromchunk.buffer— the entire underlyingArrayBuffer, ignoring the view'sbyteOffset/byteLength. Header and payload then disagree, and decoders honor the header, reading the wrong window of samples.Modifications
packages/transformers/src/utils/audio.js(encodeWAV): build the payload fromUint8Arrayviews that respect each chunk'sbyteOffset/byteLength, instead of passing the wholechunk.buffer.Duplicate-check
gh api 'repos/huggingface/transformers.js/pulls?state=open&per_page=100' --paginategrepped for1704→ no open PR references it.