Skip to main content ↑ ↓

Notice

Please note that most of the software linked on this forum is likely to be safe to use. If you are unsure, feel free to ask in the relevant topics, or send a private message to an administrator or moderator. To help curb the problems of false positives, or in the event that you do find actual malware, you can contribute through the article linked here.
Topic: Malformed or truncated chunk found at 2459694 bytes, claimed length (Read 4560 times) previous topic - next topic
0 Members and 1 Guest are viewing this topic.

Malformed or truncated chunk found at 2459694 bytes, claimed length

Hello there..

I have been having problem when converting .wav to .flac every now and then. While most files can convert without any error/warning, some would give me something like this: "  Malformed or truncated chunk found at 2459694 bytes, claimed length 2268452411 bytes, truncated to 71954 bytes".

I have searched around but failed to find a good answer. The only thing that's close to shedding a light to this myth is one person mentioned his .wav was saved using some editing tool to put/link photo. In my case I suspect the .wav producer may have added in some sort of notation in the .wav while recording (some recorders do provide functionality to add note in so that later on when you go through your recordings you know what is which).. However this is my wild guess.

Also, even the .flac files sound exactly as the .wav, I am not sure if I should keep the .wav and discard those .flac ..

Any explanation/suggestion to this problem?

I have attached one example (.wav) here.

Thx for your time on this.


Re: Malformed or truncated chunk found at 2459694 bytes, claimed length

Reply #1 –
Code: [Select]
sndfile-info "Underwater Explosion 01.wav"
========================================
File : Underwater Explosion 01.wav
Length : 2531656
RIFF : 2531648
WAVE
fmt  : 16
  Format        : 0x1 => WAVE_FORMAT_PCM
  Channels      : 2
  Sample Rate   : 96000
  Block Align   : 6
  Bit Width     : 24
  Bytes/sec     : 576000
data : 2434200
*** ID3  : 24576 (unknown marker)
bext : 858
  Unknown chunk marker at position 2459694. Resynching.
*** Chunk size 2268452411 > file length 2531656. Exiting parser.

----------------------------------------
Sample Rate : 96000
Frames      : 405700
Channels    : 2
Format      : 0x00010003
Sections    : 1
Seekable    : TRUE
Duration    : 00:00:04.226
Signal Max  : 5.90136e+006 (-3.05 dB)

So, the structure of this .wav file is incorrect (it has some data incorrectly appended to it).

Re: Malformed or truncated chunk found at 2459694 bytes, claimed length

Reply #2 –
Quote from: lvqcl on
Code: [Select]
sndfile-info "Underwater Explosion 01.wav"
========================================
File : Underwater Explosion 01.wav
Length : 2531656
RIFF : 2531648
WAVE
fmt  : 16
  Format        : 0x1 => WAVE_FORMAT_PCM
  Channels      : 2
  Sample Rate   : 96000
  Block Align   : 6
  Bit Width     : 24
  Bytes/sec     : 576000
data : 2434200
*** ID3  : 24576 (unknown marker)
bext : 858
  Unknown chunk marker at position 2459694. Resynching.
*** Chunk size 2268452411 > file length 2531656. Exiting parser.

----------------------------------------
Sample Rate : 96000
Frames      : 405700
Channels    : 2
Format      : 0x00010003
Sections    : 1
Seekable    : TRUE
Duration    : 00:00:04.226
Signal Max  : 5.90136e+006 (-3.05 dB)

So, the structure of this .wav file is incorrect (it has some data incorrectly appended to it).

That's great news. I can safely keep all the .flac now! thx a lot!

Re: Malformed or truncated chunk found at 2459694 bytes, claimed length

Reply #3 –
Where did you get this WAV? For example, game rips in the Wwise format contain RIFF WAV looking files, but the format is somewhat different from WAV in various ways, which is why they should be named .wem, and handled by VGMStream.

Also, Wwise rips should be ripped and packaged using the wwiser scripts by bnnm, since those help do things like find the original track names, and also arrange segmented tracks together by the events that use them.

Re: Malformed or truncated chunk found at 2459694 bytes, claimed length

Reply #4 –
After changing "bext" chunk size from 0x35a (858) to 0x2c0 (704) it seems somewhat fixed:
Code: [Select]
danadam@pcuj]$ sndfile-info Underwater\ Explosion\ 01.wav
========================================
File : Underwater Explosion 01.wav
Length : 2531656
RIFF : 2531648
WAVE
fmt  : 16
  Format        : 0x1 => WAVE_FORMAT_PCM
  Channels      : 2
  Sample Rate   : 96000
  Block Align   : 6
  Bit Width     : 24
  Bytes/sec     : 576000
data : 2434200
*** ID3  : 24576 (unknown marker)
bext : 704
*** SMED : 67628 (unknown marker)
Request for header allocation of 135256 denied.
LIST : 196
  INFO
    IPRD : Submarine
    IGNR : Vehicles
    IART : Philippe Charron
    ICMT : Submarine - Underwater Explosion 01
    ICOP : 2017 SilverPlatterAudio (Submarine)
    ISFT : Soundminer
    ICRD : 2017-12-07
minf : 16
iXML : 855
elm1 : 214
umid : 24
_PMX : 3126
End

----------------------------------------
Sample Rate : 96000
Frames      : 405700
Channels    : 2
Format      : 0x00010003
Sections    : 1
Seekable    : TRUE
Duration    : 00:00:04.226
Signal Max  : 5.90136e+06 (-3.05 dB)

Re: Malformed or truncated chunk found at 2459694 bytes, claimed length

Reply #5 –
Quote from: kode54 on
Where did you get this WAV? For example, game rips in the Wwise format contain RIFF WAV looking files, but the format is somewhat different from WAV in various ways, which is why they should be named .wem, and handled by VGMStream.

Also, Wwise rips should be ripped and packaged using the wwiser scripts by bnnm, since those help do things like find the original track names, and also arrange segmented tracks together by the events that use them.

These files came as they are packaged into their sound product. No idea how they made these files. But if the converted .flac are good to use ie. not discarding sound data then that's good enough for me.

Also may I mention it here without opening another post: nowadays there are .wav files created with 32 floating point bits-per-sample, and flac.exe doesn't like it, it says it does not support floating point and conversion will be lossy. Wondering if one day flac.exe will be able to handle those files?

Re: Malformed or truncated chunk found at 2459694 bytes, claimed length

Reply #6 –
So out of curiosity, I poked around at this.  It seems the original wav in it's current form can be encoded to flac with no problem, but it doesn't decode properly.  (I couldn't hear a difference, but I only have my phone to listen to it atm)

You need to use sndfile-convert to convert the wav to wavex.
I'm not sure if this step is lossy though.
Code: [Select]
$ sndfile-convert 'Underwater Explosion 01.wav' 'Underwater Explosion 01.wavex'

Then use flac with the --keep-foreign-metadata option when encoding the new wav file.
Code: [Select]
$ flac -sV8 --keep-foreign-metadata 'Underwater Explosion 01.wavex'
NOTE: --keep-foreign-metadata is a new feature; make sure to test the output file before deleting the original.

Then check it out with sndfile-info
Code: [Select]
$ sndfile-info 'Underwater Explosion 01.flac'
========================================
File : ue.flac
Length : 672669
FLAC Stream Metadata
  Channels    : 2
  Sample rate : 96000
  Frames      : 405700
  Bit width   : 24
Seektable Metadata
Vorbis Comment Metadata
Application Metadata
Application Metadata
Application Metadata
Application Metadata
Application Metadata
Padding Metadata
End

----------------------------------------
Sample Rate : 96000
Frames      : 405700
Channels    : 2
Format      : 0x00170003
Sections    : 1
Seekable    : TRUE
Duration    : 00:00:04.226
Signal Max  : 5.90136e+06 (-3.05 dB)

You must also use the --keep-foreign-metadata option when decoding the file.
Code: [Select]
$ flac -d --keep-foreign-metadata 'Underwater Explosion 01.flac'

The md5sums from the wavex and decoded flac match
Code: [Select]
$ md5sum *
6516d76e103f9357554c3620bbd9dcec  Underwater Explosion 01.flac
39f1126a623a06f5d97b9ebbf6ad6a83  Underwater Explosion 01.wav
39f1126a623a06f5d97b9ebbf6ad6a83  Underwater Explosion 01.wavex.orig
9719cdf32d927ec4006f83dae165a030  Underwater Explosion 01.wav.orig

Re: Malformed or truncated chunk found at 2459694 bytes, claimed length

Reply #7 –
Two of the metadata blocks have incorrect length written to them by the program that created the file.

bext 2584D0 5A 03 -> 5C 02
iXML 2690B0 57 03 -> 58 03

If you care about reading the metadata that follows the bext block, then the file must be repaired. Otherwise transcode and discard the metadata to avoid programs complaining.
 

Re: Malformed or truncated chunk found at 2459694 bytes, claimed length

Reply #8 –
Are flac.exe's warnings/errors really well-suited here? I used 1.3.2.

* without --keep-foreign-metadata gives a warning, i.e. creates a file in the absence of --warnings-as-errors:
Code: [Select]
Underwater Explosion 01.wav: WARNING: legacy WAVE file has format type 1 but bits-per-sample=24

* with --keep-foreign-metadata it gives instead (not in addition) the following error:
Code: [Select]
Underwater Explosion 01.wav: ERROR reading foreign metadata: invalid WAVE file: unexpected EOF (010)



Quote from: daodaodai on
Wondering if one day flac.exe will be able to handle those [32-bit float] files?
That would be a surprise. WavPack is your friend.
 
Also, WavPack recreates your original .wav file (in the original posting) bit-identically, as long as you don't alter tags or anything. That is, identical file and not only identical audio.

Re: Malformed or truncated chunk found at 2459694 bytes, claimed length

Reply #9 –
For me, the --keep-foreign-metadata only worked after converting the wav file with sndfile-convert first.  Im not sure if it's doing anything to the audio, but seems to fix the metadata so flac can encode/decode without errors.

Re: Malformed or truncated chunk found at 2459694 bytes, claimed length

Reply #10 –
Quote from: Porcus on
Are flac.exe's warnings/errors really well-suited here? I used 1.3.2.

* without --keep-foreign-metadata gives a warning, i.e. creates a file in the absence of --warnings-as-errors:
Code: [Select]
Underwater Explosion 01.wav: WARNING: legacy WAVE file has format type 1 but bits-per-sample=24

* with --keep-foreign-metadata it gives instead (not in addition) the following error:
Code: [Select]
Underwater Explosion 01.wav: ERROR reading foreign metadata: invalid WAVE file: unexpected EOF (010)
Why not?

For the first one, Microsoft claims, that format type 1 should be used only for 8 and 16 bits: https://docs.microsoft.com/en-us/windows/win32/api/mmeapi/ns-mmeapi-waveformatex
Quote
wBitsPerSample

Bits per sample for the wFormatTag format type. If wFormatTag is WAVE_FORMAT_PCM, then wBitsPerSample should be equal to 8 or 16. [...] If wFormatTag is WAVE_FORMAT_EXTENSIBLE, this value can be any integer multiple of 8 and represents the container size, not necessarily the sample size; for example, a 20-bit sample size is in a 24-bit container
Admittedly, the reasons are not very convincing (at least to me), unless you are doing some weird stuff, like the mentioned 20-bit sample in 24-bit container.

For the second one, "get_sample_info_wave()", which would trigger the "legacy" warning, is called after the check of "flac__foreign_metadata_read_from_wave()" result, which triggers the "EOF" error. The error stops the processing, so "get_sample_info_wave()" is never called.

Re: Malformed or truncated chunk found at 2459694 bytes, claimed length

Reply #11 –
Quote from: j7n on
iXML 2690B0 57 03 -> 58 03
I believe the last 0x00 byte in the iXML chunk is a pad byte and as such should not be included in the chunk size: http://www-mmsp.ece.mcgill.ca/Documents/AudioFormats/WAVE/Docs/riffmci.pdf
Quote
ckSize
A 32-bit unsigned value identifying the size of ckData. This size value does not include the size of the ckID or ckSize fields or the pad byte at the end of ckData.
ckData
Binary data of fixed or variable size. The start of ckData is word-aligned with respect to the start of the RIFF file. If the chunk size is an odd number of bytes, a pad byte with value zero is written after ckData. Word aligning improves access speed (for chunks resident in memory) and maintains compatibility with EA IFF. The ckSize value does not include the pad byte.

Re: Malformed or truncated chunk found at 2459694 bytes, claimed length

Reply #12 –
Quote from: danadam on
Why not?
[...]
For the second one, "get_sample_info_wave()", which would trigger the "legacy" warning,
Not just a "warning", but an error - i.e., enough to abort the encoding process. Had it been "warning" on both or "error" on both ...

Re: Malformed or truncated chunk found at 2459694 bytes, claimed length

Reply #13 –
Quote from: Porcus on
Quote from: danadam on
For the second one, "get_sample_info_wave()", which would trigger the "legacy" warning,
Not just a "warning", but an error - i.e., enough to abort the encoding process.
But it is an error only with "--warnings-as-errors", as you said yourself.
Quote from: Porcus on
Had it been "warning" on both or "error" on both ...
That wouldn't make sense to me. The "legacy" thing is mostly harmless, so it definitely should not be an error. The "EOF" thing is a serious issue. User requested to store the metadata and it can't be done because the input file is malformed. IMO it should stop the process, so it should be an error.

Re: Malformed or truncated chunk found at 2459694 bytes, claimed length

Reply #14 –
Quote from: danadam on
But it is an error only with "--warnings-as-errors", as you said yourself.
No, that is not what I said. The first thing is a warning. The second - which is the same audio, and apparently only malformed metadata - aborts conversion.