Avidemux ignores WAV data chunk length, reads to end of file

[catsmeow]

I'm getting my audio from an external WAV file, as chosen from the Audio > Select Track dialog. The resulting audio written to my output file (regardless of container & format) is slightly longer than it should be because there is extra noiseââ,¬â€a loud, split-second glitchââ,¬â€at the end.

I found that the added noise is due to the fact that my WAV file has what you might call "junk" (actually, metadata from my audio editor) on the end. The problem appears to be that Avidemux ignores the data chunk length defined in the header, and just reads the entire file to the end, treating it all as audio data.

IMHO, this is a bug which should be fixed; other players rightly ignore anything after the defined end of the data chunk, as does FFmpeg command-line.

Here are examples of WAVs to demonstrate the problem:

• without-metadata.wav
• with-metadata.wav

(I am using the 2016-05-28 nightly build on Win7 64-bit. Let me know if I need to provide more info.)

[Jan Gruuthuse]

You seem to miss the point: avidemux is not a player

Avidemux is a simple tool for simple video processing tasks. The keyword here is simple: it does not offer tools like a timeline, multitrack editing, you cannot freely move or splice audio and video clips from various sources. However, Avidemux allows you to do elementary things in a very straightforward way.

Source: Avidemux wiki Quickstart
- has your audio editor the option to write without metadata?
- if you load the wav file into audacity and export again as wav, does the same problem exists?


ps:audacity would require additional audacity FFmpeg import/export library

[mean]

Not a trivial fix, it might take some time

[catsmeow]

Hello Jan, and thank you very much for your reply.

Yes, my audio editor can export WAVs without metadata, though sometimes I'd rather keep the metadata (markers) for future use. Omitting the metadata upon export is just a workaround for this bug, though.

I'm sorry I said "other players". I meant other WAV-reading software. This does include audio players and editors, and also video utilities like FFmpeg and VirtualDub. When you tell VirtualDub or FFmpeg (command-line, at least) to get audio from an external WAV, they will read that file correctly, not getting any of the WAV's "data" chunk beyond the length of that chunk as specified in the WAV file's header.

Are you familiar with the format of a WAV? There's a 44-byte header followed by the audio data. The last thing in the header before the audio is the ASCII characters "data" followed by a 4-byte word indicating how many bytes of audio data to expect. When files are longer than expected, WAV-reading apps must decide whether to honor that value as a limit on the amount of data to be read, or ignore it and just keep reading to the end of the file.

It boils down to whether the app developer thinks that longer-than-expected WAVs are a result of bad headers or appended tags. Tags are more common nowadays, so I think it's reasonable to stop reading at wherever the header says, but if I were going for robustness I'd just let it be something the user can choose, because in the event of a bad header, they're going to have a hard time fixing it.

[Jan Gruuthuse]

I'm a basic user, so not into code and tags. See dev comment above your last post.

[mean]

The code was designed with AC3/MP3 in mind, with no explicit size, just the file size
It is doable to change the way wav is managed, but it is not a 5mn fix
It wil happen