Keep original audio and color profile evidence

Keep the original question attached to the evidence

A 0:00 duration label does not reveal a WAV’s codec or prove that two lengths are the only problem. The recording author’s original goal was lossless recovery, while the available evidence omitted the file itself. Preserve that gap when deciding whether the strictly bounded T317 repair fits the actual recording.

A request for an embedded profile name is similarly concrete. Recover declared ICC descriptions and the exact profile rather than replacing a missing declaration with an EXIF/model label or a guessed sRGB value. T318 records absent profiles as absent.

Write assumptions before interpreting bytes

For WAV, the required assertion is that first data is final and its remaining bytes are complete PCM. It cannot be inferred merely because the tail divides by blockAlign. A final zero in mono 8-bit PCM can be one more sample; choosing padding changes the declared frame count but preserves the file bytes.

For ICC, a complete tag directory is evidence of declarations and raw spans. Unknown tag contents remain opaque and exportable. Color hints, rendering, calibration and transform conformance need their own review.

Keep claims tied to their actual proof
Recorded finding	Supported claim	Remaining question
Matching PCM SHA256	Existing sample bytes were preserved	Were all EOF bytes truly recorded audio?
Two permitted length patches	No other original WAV byte changed	Does the target player accept this PCM profile?
Exact recovered ICC SHA256	Export matches the supplied or embedded profile	Can the chosen CMM use it correctly?
All MLUC records retained	Every declared localized string is available	Which color declaration does the renderer use?

Make the complete output the review artifact

The WAV JSON contains all prefix offsets, sizes, original padding and hashes, plus the exact two patch spans. The ICC ZIP contains every original recovered profile, full JSON and all protected CSV rows. Summary tables are useful for navigation, but cell and row limits must not be mistaken for complete evidence.

A formula-leading original name remains exact in JSON. The CSV adds spreadsheet protection rather than altering the raw declaration. Controlled profile paths keep original untrusted names out of archive member paths; source names remain provenance fields.

Retain the original files alongside the full downloads.
Compare original sizes/SHA256 before relying on a repaired or exported file.
Check the precise refusal or uncertainty instead of filling gaps with a guessed successful result.

Treat library disagreements as scoped evidence

A LittleCMS tag-directory limit is a library boundary, not proof that all larger inventories lack useful declarations. Retain every bounded raw tag and report the reader limitation. Likewise, an embedded ICC profile and a PNG cICP hint can coexist without proving which one a renderer chooses.

Keep cancellation and recovery tied to the same source bytes. A fresh successful run should produce the same complete artifacts; an interrupted run should publish none. This makes local repair and recovery reviewable without turning format inspection into an unsupported recording or color-quality guarantee.

References

Original recording recovery question
Original author selftext read and preserved on 2026-10-07: about 90 MB, 0:00 in Resolve/Logic, playable in VLC. No original file or codec supplied, so this narrow PCM repair is not a promise for that recording.
Original task: obtain the embedded profile name
Full question and original-author comment read on 2026-10-07. Actual ProPhoto RGB bytes and caption-name need support recovering profile declarations; EXIF/model or built-in sRGB fallback is not the same result.
Original task: read a usable description from ICC bytes
Full original question and author follow-up read on 2026-10-07. The author confirms their final extraction via ExifTool; this implementation instead exports and reads bounded profiles locally.
FFmpeg WAV ignore_length documentation
Section 3.29 read on 2026-10-07. It describes unfinished lengths and the risk that nonaudio chunks after data are treated as audio; no automatic tail detection is inferred.
Microsoft RIFF chunk structure
Read on 2026-10-07: FOURCC, lengths and word padding establish the byte spans, rather than a fixed header search.
ICC embedding technical note
JPEG numbered ICC_PROFILE APP2 and PNG iCCP sections read on 2026-10-07; they define actual piece reconstruction, not keyword or substring guessing.
ICC profile header, directory and localized text specification
Sections 7.2–7.4 and 10.13 read on 2026-10-07. Raw directory spans and complete MLUC records are preserved; no transform-conformance certification is claimed.
PNG iCCP and cICP color declarations
Sections 11.3.2.3 and 11.3.2.6 read on 2026-10-07. An embedded ICC profile alone does not establish which declaration a renderer uses.
LittleCMS 2.19 internal tag-directory ceiling
Official MAX_TABLE_TAG=100 definition read on 2026-10-07; real 100/101-tag library proof distinguishes directory inventory from CMM compatibility.

Tools in this category

Expand a tool to see its steps, options and supported formats, then open its workspace.

Repair WAV length fieldsPatch only the RIFF and data lengths of a confirmed final PCM recording, preserving every existing sample and prefix byte.

Select an unfinished classic PCM WAV. Explicitly confirm that its first data chunk is final and that all remaining bytes are complete audio frames. Repair only the two length fields; download the original-size WAV and a complete byte-preservation report.

Steps

Keep the original recording and check that it matches the stated classic PCM profile.
Select it and explicitly confirm final data/EOF audio. Choose final zero padding only with evidence.
Run the repair, then compare original/output lengths, PCM SHA256 and both patch spans.
Download repaired.wav and the complete JSON; evaluate the recording in your intended player.

Available options

I confirm that first data is final and all remaining bytes are complete PCM audio: Off by default
One actual final zero is padding for odd-length PCM, not an audio sample: Off by default

Capabilities and limits

One original, at most 100 MiB. Source filename at most 512 UTF-16 units. At most 1,000 prefix chunks, including fmt; unknown prefix chunks and their padding are preserved as opaque original bytes.
Little-endian classic RIFF/WAVE only: integer PCM tag 1, 8/16/24/32 bits, 1–8 channels, sample rate 1–384,000 Hz. One fmt before the first data chunk; fmt is exactly 16 bytes or 18 bytes with cbSize=0. Frame alignment and byte rate must match these fields.
The final-data confirmation defaults off. This is a required user assertion, not automatic detection. Aligned trailing metadata may look like audio and cannot be distinguished here. Missing samples, wrong sample rate, empty data and incomplete frames are not repaired.
The optional final-zero-pad assertion defaults off. Set it only when odd-length PCM has one actual final zero pad. Without that assertion, a final zero remains an audio byte; the tool does not guess whether it is a sample or padding.
Only uint32LE at RIFF offset 4 and the real data-length field are patched. WAV length, prefix chunks, PCM and existing padding stay byte-identical. Complete JSON includes all offsets, original and output SHA256, PCM SHA256, format, frames, duration, every prefix chunk and both patch spans.
WAV plus complete JSON must fit 102 MiB. This output guard is implied by the 100 MiB source and bounded report; an independent exact 102 MiB supported output cannot be reached. Preview shows the first 200 prefix chunks and at most 2,000 UTF-16 units per cell; complete records are in JSON.
RIFX/RF64/BW64, extensible, float or compressed audio and malformed chunk chains are refused. No decoding, reconstruction, playback, network access or universal player/Windows compatibility guarantee. Existing names and metadata remain; this is not anonymization.

Open Repair WAV length fields →

Extract embedded ICC profilesRecover exact ICC bytes from local JPEG, static PNG or ICC files and read every declared localized description without recoloring images.

Select local JPEG, static PNG and ICC/ICM originals. Recover their exact embedded or supplied color profiles, complete header/tag inventory and every declared text record. Download a ZIP containing reusable profile bytes, full JSON and formula-protected CSV.

Steps

Select original JPEG, static PNG or ICC/ICM files; retain their originals.
Review profile/no-profile status, declared descriptions, raw version and color-space fields.
Download the complete ZIP and compare each exported profile SHA256 with the report.
Use a suitable color management system separately when you need rendering or transform validation.

Capabilities and limits

1–100 original files; each at most 20 MiB and combined at most 80 MiB. Original names at most 512 UTF-16 units. The entire batch either completes or refuses; every original SHA256 is retained.
Each profile at most 8 MiB and combined profile bytes at most 32 MiB. At most 4,096 tags per profile, 65,536 total tags, 1,024 records per MLUC tag, 10,000 text records and 4,194,304 text UTF-16/ASCII units. Container marker/chunk visits at most 100,000. These work budgets apply together.
Static PNG checks the full chunk chain and every CRC, required ordering, supported IHDR, iCCP keyword and bounded zlib profile. APNG and unknown critical chunks refuse. JPEG checks marker and scan framing through EOI and reconstructs every complete numbered ICC_PROFILE APP2 piece in declared order, even when physical order differs. No pixel or entropy decoding is claimed.
ICC major versions 2 and 4: exact word-aligned declared size, all header fields, tag spans, zero reserved bytes and full raw export. Exact shared tag spans and shared MLUC string spans are accepted; partial tag overlap is outside this profile. MLUC UTF-16BE, legacy desc and classic text are read strictly. A leading U+FEFF in declared text remains literal.
All unknown or nontext tag contents remain recoverable via the exported complete profile and exact offset/size/SHA256 references. Legacy ScriptCode bytes remain opaque. No guessed sRGB, EXIF ColorSpace fallback or missing-name invention. A valid image with no profile is reported explicitly.
Full JSON plus every safe CSV row at most 32 MiB. ZIP at most 65 MiB; that allocation guard is implied by the 32 MiB profile and report bounds, not an independently reachable output ceiling. Profile sizes are word-aligned: byte guards reject +1 before structure, while the first otherwise valid aligned excess is +4.
Table shows all selected sources with cells capped at 2,000 UTF-16 units; complete localized strings and raw unknown tags are in the ZIP. No color rendering, calibration, transform usability or ICC conformance certification. PNG cICP may override ICC during rendering. LittleCMS 2.19 refuses directories above its 100-tag internal limit; this inventory can still preserve them, without claiming CMM compatibility.
TIFF/PDF/WebP/HEIF/JXL, network/installed-profile lookup, code/CSS execution and automatic navigation are outside this release. Original metadata is preserved; this is not anonymization.

Open Extract embedded ICC profiles →

Tools used in this article

Repair WAV length fields →Patch only the RIFF and data lengths of a confirmed final PCM recording, preserving every existing sample and prefix byte.Extract embedded ICC profiles →Recover exact ICC bytes from local JPEG, static PNG or ICC files and read every declared localized description without recoloring images.